CENTERA_MIGRATOR_PPT_NOTES

Centera Mainframe HSM Migrator - 1
Copyright © 2010 EMC Corporation. Do not Copy - All Rights Reserved.
Welcome to EMC Centera Mainframe HSM Migrator.
Copyright © 2010 EMC Corporation. All rights reserved.
These materials may not be copied without EMC's written consent.
EMC believes the information in this publication is accurate as of its publication date. The information is
subject to change without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION
MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE
INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Use, copying, and distribution of any EMC software described in this publication requires an applicable
software license.
EMC² , EMC, EMC ControlCenter, AdvantEdge, AlphaStor, ApplicationXtender, Avamar, Captiva,
Catalog Solution, Celerra, Centera, CentraStar, ClaimPack, ClaimsEditor, ClaimsEditor, Professional,
CLARalert, CLARiiON, ClientPak, CodeLink, Connectrix, Co-StandbyServer, Dantz, Direct Matrix
Architecture, DiskXtender, DiskXtender 2000, Document Sciences, Documentum, EmailXaminer,
EmailXtender, EmailXtract, enVision, eRoom, Event Explorer, FLARE, FormWare, HighRoad,
InputAccel,InputAccel Express, Invista, ISIS, Max Retriever, Navisphere, NetWorker, nLayers,
OpenScale, PixTools, Powerlink, PowerPath, Rainfinity, RepliStor, ResourcePak, Retrospect, RSA, RSA
Secured, RSA Security, SecurID, SecurWorld, Smarts, SnapShotServer, SnapView/IP, SRDF,
Symmetrix, TimeFinder, VisualSAN, VSAM-Assist, WebXtender, where information lives, xPression,
xPresso, Xtender, Xtender Solutions; and EMC OnCourse, EMC Proven, EMC Snap, EMC Storage
Administrator, Acartus, Access Logix, ArchiveXtender, Authentic Problems, Automated Resource
Manager, AutoStart, AutoSwap, AVALONidm, C-Clip, Celerra Replicator, CLARevent, Codebook
Correlation Technology, Common Information Model, CopyCross, CopyPoint, DatabaseXtender, Digital
Mailroom, Direct Matrix, EDM, E-Lab, eInput, Enginuity, FarPoint, FirstPass, Fortress, Global File
Virtualization, Graphic Visualization, InfoMover, Infoscape, MediaStor, MirrorView, Mozy,
MozyEnterprise, MozyHome, MozyPro, NetWin, OnAlert, PowerSnap, QuickScan, RepliCare, SafeLine,
SAN Advisor, SAN Copy, SAN Manager, SDMS, SnapImage, SnapSure, SnapView, StorageScope,
SupportMate, SymmAPI, SymmEnabler, Symmetrix DMX, UltraFlex, UltraPoint, UltraScale, Viewlets,
VisualSRM are trademarks of EMC Corporation.
All other trademarks used herein are the property of their respective owners.

The objectives for this course are shown here. Please take a moment to read them.

First we will provide a review of DFSMS, which is a separate program product from the z/OS
operating system—although IBM ties DFSMS to z/OS level.
There are five components:
• DFSMSdfp does the data management; that is, I/O to disk and tape devices, etc. It is an
essential component that must be installed.
• DFDSSrmm (Removable Media Manager) deals with tape libraries and removable media.
• DFSMShsm (Hierarchical Storage Management) handles data backup and the policy-based
tiering of storage.
• DFSMSdss allows files (known as datasets in z/OS parlance) to be stored in a hardware
independent format similar to the way PAX works in the UNIX environment so that datasets
can be copied to different media.
• DFSMStvs (transactional VSAM) is related to extended features of VSAM dataset
processing.
The focus of this presentation is on DFSMShsm with some attention to DFSMSdss.

z/OS system managed storage provides the capability to assign (or tag) each dataset with three
attributes or classes so that system wide policies can be implemented with the objective of
automating data management to save time and labor.
• The management class of a dataset specifies the backup and migration attributes of a dataset.
• The storage class specifies placement and performance characteristics of a dataset.
• The data class specifies space allocation characteristics since in z/OS, a dataset has to be
allocated before use whereas UNIX and WINDOWS files are created on first write.
The storage administrator can then apply rules for user-defined classes. In this course, the
management class is relevant since it deals directly with the DFSMShsm component.

This course focuses on the hierarchical component of DFSMShsm even though that product also
does dataset and volume backup. The Centera Mainframe HSM Migrator does not do any
backup activities.
The DFSMShsm hierarchical function tries to ensure that there is space available any time for
new datasets and/or expansion of existing datasets. This is maintained as the DFSMShsm studies
a given volume and attempts to ensure that a user-defined percentage of free space exists on that
volume.
DFSMShsm attempts to move data to a cheaper device based on least recently referenced data,
size of the dataset, and how critical the data is for the business.

The DFHSMhsm storage hierarchy attempts to tier data usage into the 3 levels shown here.
Datasets run in an application when they reside on ML0, i.e., on DASD.
When policy dictates that a dataset does not need to be immediately available on ML0 DASD,
DFSMShsm moves (migrates) it to ML1 DASD. It is reformatted in a hardware independent
format known as “DFSMSdss DUMP format” that is conceptually similar to the device
independent format in UNIX known as PAX.
Datasets residing on ML1 may be migrated to ML2 via automated policy decisions or user
command.

We can “stub” a dataset that is not readily available on disk by allowing the z/OS user catalog to
specify that the dataset exists but has been relocated to either ML1 or ML2 storage. Datasets are
moved down to ML1 and ML2 storage based on system administrator specifications. For
example, a dataset of a certain management class that has not been updated in 7 days is migrated
(moved) to ML1.
When a dataset is migrated, IBM’s Catalog Management Services updates the dataset’s entry in
the z/OS user catalog to have reserved volser MIGRAT and the DFSMShsm Migration Control
Data Set (MCDS) points to where the dataset resides on ML1.
A dataset that was migrated but requested for access and moved back to ML0 is said to be
RECALLED.

DFSMShsm is a combination of a Started Task (long running process), TSO and Operator
commands, configuration files (PARMLIB), and ISPF Dialog application. The configuration
files and control datasets are pointed from the Started Task.
The MCDS (Migration Control Dataset) is used by DFSMShsm to track where migrated datasets
are as the z/OS user catalog only notes that a migrated dataset is migrated to either ML1 or ML2
but does not provide any specific details about the device.
The ISPF Dialogs allow a data administrator to control the management policies for backup and
migration. TSO and Operator commands control migration, recall, backup, and restore
operations on datasets and volumes.

A dataset X.Y.Z appears here residing on volume VOL123 which is ML0, meaning that the
dataset is immediately accessible and cataloged before it is migrated.

Dataset X.Y.Z has been migrated to an ML1 volume known as ABCML1. The z/OS user catalog
is updated noting that the dataset has been migrated by specifying a reserved Volser named
MIGRAT.
The DFSMShsm MCDS dataset creates an entry for the dataset named X.Y.Z, specifying that the
migrated dataset is in a dataset on a DFSMShsm owned ML1 volume.

Dataset X.Y.Z is moved to ML0 Volser VOL123. The z/OS user catalog is updated noting that
the dataset is on VOL123. The DFSMShsm MCDS dataset removes the entry for the dataset
named X.Y.Z, specifying that the migrated dataset is no longer on a DFSMShsm owned dataset
on the ML1 dataset.

The physical mainframe hardware from IBM is known as Central Electronics Complex (CEC).
Such hardware can be divided into separate Logical Partitions (LPARs) with each partition
hosting its own IPLable operating system. When DFSMShsm runs on the LPARs, it may be
desirable to share the workload of RECALLs among the member LPARs to prevent any single
LPAR from being overloaded with RECALL work.
This implementation uses IBM’s proprietary coupling facility which provides communication
between the LPARs. As an example, if a user on LPAR A requests a recall of a dataset X.Y.Z,
then the CRQ may choose to have LPAR C do the recall and move the dataset from ML1 storage
to ML0 transparent to the user.

While DFSMShsm provides important benefits for data management, for an environment using
reel tape there can be a few issues. When a dataset is migrated to ML2 tape, at recall time a tape
mount is required and the relatively slow process of copying a dataset to 3390 disk from tape
can manifest as a potentially long delay for the user.
Over time, recalls from tape often result in portions of tape that contain outdated user data. The
process of cleaning tapes that contain outdated user data is a slow process that uses tape drives
and CPU and is called RECYCLING of tapes. The overhead is referred to as RECYCLE time.
Finally, though ML1 disk could be configured on “slower and older” 3390 DASD, it is still
DASD and is significantly more expensive than tape.

Before we delve into the function of the EMC Centera MF HSM Migrator, here is a review of
the features and benefits of EMC Centera, that were covered in the Centera eLearning module.
The Centera is IP accessible and therefore does not require the customer’s system programming
staff system to be involved in adding a so-called mainframe “channel attached” device. Via a
hash algorithm, end to end authenticity of data is maintained. The same blob content is only
stored once even if the same client or a different client stores the same blob. Centera has
redundant storage arrays that can resolve a “single point of failure”.
Storage management is greatly simplified as storage can be logically divided into virtual pools
(vs. physically dividing storage boxes). Storage capacity can be increased without interruption.
Centeras can be configured to do remote networked replication to implement a disaster recovery
site. For the amount of data stored on Centera, the cost of ownership is lower than tape, optical,
or other “transactional” disks.

As a review of Centera, this slide summarizes what happens when we write a BLOB to Centera
independent of what type of host the client is running on. The user data (or BLOB) is addressed
via a Centera maintained XML data structure known as the Content Descriptor File (CDF).
The Content Descriptor File is addressed via an alphanumeric value known as a ClipID that a
Centera C/C++ Client application uses to access user data.
Hence, BLOB data access is a 2-step process:
• ClipID to point to the Content Descriptor File
• Within the CDF, there is an internal address known as the Content Address (CA) that points
to the BLOB or user data
ClipIDs are typically maintained in a separate database or, in the case of z/OS, it could be a
VSAM keyed dataset. The interaction between client and Centera is developed via a proprietary
but published API whose underlying communication method is TCP/IP socket calls.

The Centera Mainframe HSM Migrator is an EMC product that is a collection of components, including a set of
DFSMShsm user exits. IBM provides users and vendors the opportunity to customize their operation of the
DFSMShsm component. Information on these exits is found in the DFSMS User Exit manual published with every
version of DFSMS. The very existence of these exits has allowed EMC to develop this product. We will discuss the
function of these exits in the next slide.
.
The Centera Control Dataset serves the same purpose as DFSMShsm’s MCDS (Migration Control Dataset) as it is a
VSAM dataset allocated by Centera Migrator to correlate a Centera Migrated Dataset with its location on Centera.
Also included are ISPF dialogs that provide monitoring of Centera migrations and recalls. These dialogs provide a
useful interface to the Centera Control Dataset. They can provide information on the Config File as well as report
statistics about Centera-related migrations and recalls.
Two TSO commands will be presented in slides later in this course.
Batch jobs provide important regular maintenance of the Centera MF HSM Migrator as well as print reports. Part of
the motivation for using batch jobs is the ability to run some batch jobs at off-peak times to minimize impact on
overall system performance. Some Centera Mainframe HSM Migrator batch jobs are discussed later in the course.

The heart of the Centera Mainframe HSM Migrator is the activity of the exits and how they interact with
other components. The exits interface with the Centera client API to communicate with the Centera
hardware. Note that the interface with Centera is via IP and that the Centera Migrator is NOT doing
device emulation. The Centera API interacts with the DFSMSdss component to create device-
independent copies of z/OS datasets written to Centera or to read these copies from Centera and recreate
the datasets on ML0 disk.
The ARCINEXT (Initialization Exit) is issued once upon DFSMShsm startup. EMC uses this exit to
establish its working environment. This is when the configuration file is read. These parameters are
described in the EMC publication, The Centera Mainframe HSM Migrator Administrator Guide.
The ARCMDEXT (Dataset Migration Exit) allows an installation to examine every potential dataset
migration and make installation decisions on whether a dataset is to be HSM migrated. The Centera
Migrator uses this installation exit to migrate datasets to Centera.
The ARCRPEXT (Recall Priority Exit) is documented as allowing the installation to set a user-defined
priority for HSM recalls but the exit is engineered to recall datasets from Centera.
Finally, the ARCSDEXT (Termination Exit) does cleanup of the Centera Migrator upon HSM shutdown.
Also, the Centera Migrator is not modifying DFSMShsm control datasets, so DFSMShsm operates
independently from the Centera Migrator. The Centera Migrator only potentially handles those datasets
specified in the configuration file filtering parameters via a dataset mask (i.e., USER.TEST.*) and/or
DFSMS Management class mask.

This slide describes the steps involved in migrating a dataset to Centera. First, a request to
migrate a dataset is made either via DFSMShsm monitoring of SMS volumes looking for
migration eligible datasets or a user explicitly wishes to migrate a dataset.
DFSMShsm passes the request for migration to the ARCMDEXT exit. The code looks at the
request and, based on our configuration parameters, determines if the dataset should be migrated
to Centera. If yes, run the DFSMSdss application code to read the dataset and create a device
independent format for the dataset.
The Centera Migrator streams this device-independent format via IP to Centera and it becomes a
BLOB. The Centera Migrator stores the associated ClipID as a record in the Centera Control
Dataset. The z/OS Catalog is updated to reflect that the dataset has been migrated.
Finally, the exit returns to DFSMShsm processing indicating that the dataset should NOT be
migrated by DFSMShsm.
The Centera is considered a very large ML1 device even though it has no Volsers.
If the prospective dataset has been determined by the exit to not be eligible to be migrated to
Centera because, for example, the dataset inclusion mask in the configuration parameters does
not match the dataset, DFSMShsm is simply instructed to handle the migration. Therefore, a
migration request will be handled one way or another, landing either on Centera storage or
DFSMShsm’s ML1 or ML2.

Installation of this product is as follows: the customer receives an XMIT file and unpacks it to a
partitioned dataset. A single batch job extracts the components: executables, ISPF panel, REXX
exec, and related installation material (RIM).
A REXX exec/ISPF dialog is run to customize batch jobs so that the formal installation can be
done using IBM’s SMP/E. The SMP/E batch jobs are run to complete the installation.
The rest involves the basic customization which is: allocation of the Centera Control Dataset,
the customization of the Config file (the ECACGCNTL DD statement in DFSMShsm proc), and
the updating of the DFSMShsm started task.
Software updates for this product are also XMIT files containing SMP/E PTFs. These updates
are sometimes known as hotfixes—the term used for other Centera-related updates.

Similar to the DFSMShsm HLIST TSO command, the Centera Migrator provides the TSO
CMLIST command that lists Centera migrated datasets. The command has the level parameter
that provides a dataset mask to list out a range of migrated datasets.

Similar to the DFSMShsm HMIGRATE TSO command, the CMIGRATE command directly
migrates an ML0 non-VSAM dataset to Centera storage. This command skips the overhead of
DFSMShsm exit processing to use less CPU.

DFSMShsm dynamically deletes datasets based on policies specified in the Management class.
For example, a dataset can be allocated with a Management class which requires that if the
dataset is not referenced in a week, it should be deleted. The EMC Centera Mainframe HSM
Migrator specifically provides this same functionality on datasets that have been Centera
migrated. The implementation of this is via an administrative batch job periodically run by the
storage administrator known as “BATCH DELETE”. The batch delete job does the following:
1. Studies the current Management Class policies.
2. Checks every Centera migrated dataset contained in the Centera Control Dataset and
applies the policies in Step 1 on each dataset to determine if the dataset should be deleted.
3. If it is determined that a deletion should be performed, then it:
a) A deletion of the dataset from the z/OS user catalog
b) A deletion of the entry in the Centera Control Dataset, and
c) A deletion of the Centera Description File that points to the user (BLOB) data.

One of the batch utilities provided does an audit of the Centera Control Dataset. It checks each
entry in the Centera Control Dataset for a Centera migrated dataset, and verifies that the
associated CDF exists and that the dataset is still cataloged as a migrated dataset.
If there are inconsistencies, audit can attempt corrections. Datasets that are no longer migrated
according to the z/OS user catalog will be deleted from the Centera Control Dataset. Or, datasets
that are not cataloged in z/OS catalog, but have an entry in the Centera Control Dataset, can be
re-cataloged as MIGRAT.

After a successful recall of a Centera migrated dataset, a “recall bit” is set in the Centera Control
Dataset to indicate that the entry is no longer valid. The Centera recall process does not delete
the record on the Centera Control Dataset, nor does any data on Centera get deleted at recall
time. We defer the cleanup so that an installation can perform the actual cleanup at “off-peak
times”.
This cleanup is deferred until the customer runs the “cleanup of recalled migration batch job”
which will:
1.Update the Centera Control Dataset and delete the migration record.
2.Delete the associated CDF and BLOB data on the Centera.

This slide displays the SESSION STATUS of recent Centera related migrations, recalls, and
deletes.

This slide provides a sample of an ISPF dialog that displays session statistics for the active
DFSMShsm run meaning while the current DFSMShsm started task is running. It gives the
system administrator an idea of how much Centera Mainframe HSM Migrator activity has
occurred in terms of the number of migration, recalls, and deletes.

This ISPF panel shows some of the contents of the Centera MF HSM Migrator’s Config file in
an easy to read format. Some of these configuration parameters can be dynamically altered in
the dialog.

The Centera Control Dataset manages the currently migrated datasets that reside on Centera
storage. This keyed VSAM dataset holds useful information about the migrated dataset
including some DSCB info and its related Centera info such as the Centera ClipID.
Note that this application will also access the associated CDF on Centera and obtain dataset
information captured in Centera. The exact byte size for the USER1.STRESS5.PLUGIN.A9633
dataset is returned in the Blob Size: field.

When implementing the Centera Mainframe HSM Migrator, there are a few limitations,
considerations, and annoyances. First, the product can run in a coupled LPAR environment with
DFSMShsm’s Common Recall Queue (CRQ). However, any request for the recall of a dataset
that has been migrated to Centera will be performed by the LPAR that receives the request and
the request is never sent to another LPAR. In other words, the recall is done “locally” as if CRQ
is not implemented. So we say that we “tolerate” CRQ. Any non-Centera migrated dataset is
unaffected by the installation of our product and CRQ operates normally.
Due to the way that z/OS works with the ARCMDEXT (Dataset Migration Exit), an
informational message is issued on dataset migration to Centera that states that the dataset was
NOT migrated to DFSMShsm ML1 storage:
• ARC1001I DMOSHI3.IRIS.CENT.A.LARGE.B MIGRATE FAILED, RC=0045,
REAS=0092
• ARC1245I DATA SET NOT ELIGIBLE FOR MIGRATION
Although no actual error has occurred, Centera Migrator is unable to suppress these messages.
The customer must therefore learn to ignore them under those circumstances.
The Centera Migrator only migrates datasets that are SMS Managed—that have a Management
class. The DB2 Tablespace (a type of VSAM dataset) cannot be migrated with Centera Migrator.
Datasets with a discrete RACF profile that also use the RACF indicator bit in the DSCB1 cannot
be Centera migrated
Once a dataset has been migrated to Centera, it cannot be migrated in the DFSMShsm hierarchy
to ML2 (tape). Of course, the primary purpose of this product is to completely eliminate tape

Centera Mainframe HSM Migrator - ‹#›
usage.

The primary benefit of Centera Mainframe HSM Migrator is that tape processing for DFSMShsm
migration recalls is eliminated. When this product is installed,we don’t need to deal with tape
management with its mounts and dismounts along with the associated time delay. The Centera Migrator
eliminates the time involved in the recycling of tapes.
Centera cleanup of unneeded BLOBs is an asynchronous task known as “Garbage Collection” and does
not affect mainframe system performance.
A customer interested in Centera Migrator can run their Daily Statistics Report Summary (a DFSMShsm
report) at their shop to quantify the amount of ML2 tape data being written and read, as well as the
amount of recycle work.
Centera Mainframe HSM Migrator’s use of Centera as ML1 storage is far less expensive than traditional
3390 DASD. Because the storage capacities on Centera can be easily expanded, capacity planning and
expansion for ML1 storage is easier.
For installations with channel usage constraints, the Centera Mainframe HSM Migrator does not use any
channel connections and for some mainframe shops, this makes the product easy to install.
Since Centera Mainframe HSM Migrator works with DFSMShsm, the installation can control, via the
configuration file with its DATASETNAME, and MANAGEMENT class masking, how many potential
ML0 datasets will be migrated to Centera. One customer could use the product just to migrate DB2 logs,
where another customer may choose to migrate every eligible SMS dataset.

The key points covered in this course include an overview of DFSMShsm migration and recall
activities, some of the limitations of DFSMShsm processing, how the Centera Mainframe HSM
Migrator works, and its benefits.
This concludes the training. Please proceed to the Course Completion slide to take the
assessment.

CENTERA_MIGRATOR_PPT_NOTES

More Related Content

What's hot

Similar to CENTERA_MIGRATOR_PPT_NOTES

CENTERA_MIGRATOR_PPT_NOTES