Ask the Expert: Best Practices for the z/OS Migrator Tool

Welcome to this Ask the Expert discussion. We are opening it a little early to allow you to post your questions for our expert, Marta.

Marta will then respond starting on October 28th, but if you have questions in advance of that, please post them now. We look forward a lively and interesting discussion.

Best regards,

Mark

Thanks Mark

Marta Woods

Technical Support Engineer - Mainframe

EST 9-6

Support Center: 800 782-4362

Phone: 800 782-4362 x 329-1960

Email: marta.woods@emc.com

Online Support: http://support.emc.com

z/OS Migrator is a migration tool which permits movement of data while the data is in use. To accomplish the migration without stopping applications, z/OS Migrator re-routes the I/O to the target location as part of the swapping process. 

The pre-installation tasks include reserve handling requirements. Some are for logical migration only, and some are for all migrations.  These are requirements, not recommendations.  Should these not be in place and a migration done, an enqueue lockout will eventually occur.

After any lengthy period without migrations, I would recommend checking the reserve requirements to be sure the GRSRNL includes and excludes adhear to requirements at the time you plan to do migrations.

Hi Marta,

  Can you please explain what a migration group is?  Why is one systems labeled the owner and why is there that distinction?

Thanks,

Jeff

Can you please explain what a migration group is?

A migration group is the statements and parameters that define what will be migrated and where it is to be moved to.

Why is one system labeled the owner and why is there that distinction?

The owner of a migration group, is the z/OS Migrator STC to which the activate command was issued. The owner will control the migration and coordinate it with the other z/OS Migrator STCs using the z/OS Migrator database. Also, some commands may only be issued to owner. An example, diversion of a logical migration group must be done from the LPAR where activation was done.

Let’s talk about the types of migration groups.  The first two types of migration groups are:

Migrate with Swap, identified by MODE(MIGRATE(SWAP

This group is not consistent. When a Migrate with swap group is activated, it will proceed to sync each volume pair in the group.  Once a volume pair reaches 100% sync, the pair swaps (the source volume is varied offline and the target volume varied online) and active I/O is re-routed to the target.  The only command given to z/OS Migrator for this group is ACTIVATE, the group will complete on its own.  Once the swap for a volume completes, the only way to go back to the source is to swap back.  --- do you trust that there was no active i/o to the volume during the swap?

Consistent Migrate, identified by MODE(FMIR(SWAP

This group is consistent. When a consistent migrate is activated, each volume pair will sync until all volumes are in mirror (A target volume is in mirror with the source volume when it is an identical copy of the source; and z/OS Migrator is applying updates to the target volume concurrently with those updates to the source volume).  The group will remain in MIROR until z/OS Migrator receives a command to either swap or suspend.   Regardless of which command it receives the termination will be consistent.  If swap (divert) is issued, then the volumes will be swapped as a unit and any active I/O will be re-routed.  Once the swap for a volume completes, the only way to go back to the source is to swap back.

The next two groups are:

Fastmirror, identified by MODE(FASTMIRROR or MODE(FMIR

This group is always consistent. This group creates a point in time copy of the source.

When a fastmirror is activated, each volume pair will sync until all volumes are in mirror (A target volume is in mirror with the source volume when it is an identical copy of the source; and z/OS Migrator is applying updates to the target volume concurrently with those updates to the source volume).  The group will remain in MIROR until z/OS Migrator receives a command to suspend the group. 

Constant Copy, identified by MODE(MIGRATE(CONSTANT

This group is not consistent; it is an periodic update of the target volume.  When a constant copy group is activated it will sync each volume pair to 100% then periodically copy changes after the initial sync.  How often changes are copied to the target is controlled by the parameter constant_copy_int. How this group will terminate is determined at termination time.  It may be swapped or split.  If the group is swapped then I/O is re-routed to the target.  If the group is split I/O is not re-routed to the target.

The last two groups are:

Migrate with split, identified by MODE(MIGRATE(SPLIT(ON|OFF)

This group is not consistent. This group creates a point in time copy of the source.   For SPLIT(ON) to bring the volume online the parameter, newvolser, must be coded. The volume pairs, in this group, split when sync reaches 100%.  Note: the datasets on the volume will be uncataloged.  When a split group is activated the volumes sync to 100% and then split.

Logical migration, identified by MODE(LMIG())

This group is consistent.  It is the only group which moves individual or groups of datasets.  It is the only group where the target volume is online and in use by one or more LPARs. This group requires that both the source and target datasets be found via catalog lookup; therefore a temporary HLQ must be specified to allow the target datasets to be found via catalog lookup. The target datasets will be allocated using this temporary HLQ.  It is important to note that in SMS shops, SMS will control where the datasets are placed.  When this group activates it proceeds to mirror and remains in mirror until z/OS Migrator receives a command to either divert or suspend the group.  When this group is diverted the target and source datasets swap names and catalogs are updated to point to the correct volume.  The datasets on the target volume are updated first, then the catalogs are altered and lastly the source datasets are updated. It is therefore important to know what stage the migration is in when discussing the datasets. I/O is re-routed for the datasets in this group so the only way to go back to the original location is to swap back.   Note: the target HLQ is not deleted by migrator after the migration.