Evaluating remote copy with DFSMShsm

If any remote copy-eligible volumes are also eligible for either primary space migration or interval migration, you must make backup copies of these migration-eligible data sets available to the disaster recovery site. The need for these backup copies can be better understood when we compare the DFSMShsm migration process to the remote copy process.

Note: Although backups are always useful, remote copy (especially XRC) reduces the need for them by keeping the offsite copy far enough away from the original to avoid the loss of both copies. The only need for backups, therefore, is to allow retrieval of older versions of existing data sets.

DFSMShsm migration from a primary volume consists of the following steps:

A move or delete from the primary volume
A change in catalog pointers to a DFSMShsm-managed control data set
The reallocation of the data on another DASD device or tape volume

If you are also copying the primary volume with remote copy, the DFSMShsm migration actions appear as a delete of the primary as far as remote copy is concerned. Since the secondary volume is a track-for-track image of the primary volume, the delete performed against the primary volume during the migration process is then reflected to the remote copy secondary volume, which is then deleted. You must take steps to ensure that you are not left without current copies of these data sets.

The best solution is to have policies in place that control how volumes can be removed from or added to remote copy control. One way is to take advantage of DFSMShsm management-class and storage-group SMS constructs, both of which have options to prevent automatic migration of these data sets.

Sometimes data is written to DASD for a very short length of time, as with a temporary work file or when the NOBACKUP keyword is specified. This might also be the case if the volume using remote copy services is being managed under Tape Mount Management (TMM). With TMM migrating the data every hour without backup, you must ensure that a valid backup is available to the remote recovery site.

Recommendation: An excellent way to achieve this backup is to use a fast replication copy function (such as concurrent copy, FlashCopy®, or SnapShot copy) to copy the secondary volumes before migration.

Ensure that you have adequate cache capacity to accommodate both functions, as the cache resources must now serve both remote copy and concurrent copy. Without adequate policies in place, data sets available for migration or deletion by DFSMShsm cannot be guaranteed to be covered by remote copy.