IT Management

My team of solution architects frequently design and implement z/OS disk migrations as part of storage upgrades or new implementations. After performing many migrations at small to very large installations, we’ve learned the many trials and tribulations of disk migrations along with ways to deal with the different challenges that always seem to occur.

While some of the challenges highlighted here are new, others have been around for years. A tip or two has been inserted after each of the challenges to help you in case you experience them.

Maintaining Disaster Recovery (DR) position. One of the more recent challenges for accounts when performing storage subsystem migrations to new subsystems is maintaining their current Disaster Recovery Point Objective (RPO). Often during the migration, the customer had to suspend their DR replication and/or tolerate disparate recovery procedures. If suspended, the remote data is aging, only becoming current after the migration is complete and the replication resumed to the remote DR site. Disparate recovery procedures must be considered to account for either the aged data or the recovery of multiple arrays. Typically, during the volume migration a subset of the volumes are migrated—migrating in groups of 32 volumes at a time isn’t uncommon—at a typical rate of 2 to 3TB per hour. A customer with 90TB of data to migrate has the potential aging exposure of more than 20 hours. For many accounts, this is now unacceptable.

Tip: One way to alleviate this dilemma is to maintain a mirroring relationship to the source during the migration process. This set of synchronized mirrors can be split and re-established as desired for testing. This allows the original DR process to remain in place until the split for the final cutover.  This results in the benefit of migration and the ability to test the DR while being non-disruptive to production.

Migrating non-disruptively. Downtime on a mainframe is a rarity; the expectation is usually set for a non-disruptive (or at least a minimally invasive) migration. Limited migration windows, reluctance to IPL, application downtime, and impact to DR windows all require considerable planning. 

Logical (data set) migrations are more complex, and as such, these are the general steps used:

  1. Planning and setup can be 80 percent of the project.
  2. Use DFDSS to move anything not in use (TSO, batch, system).
  3. Let HSM handle ML1 volumes (ADDVOL/FREEVOL) if going to larger ML1 volumes.
  4. Data sets that are redefined on a regular schedule will move by attrition by changing SMS volume status (GDGs, database reorg, etc.).
  5. Analyze and clean the user catalogs as needed.
  6. SMS considerations: DISNEW all volumes you’re moving from and change ACS to allow interim data sets to fall on the target volumes if needed.
  7. Work with small groups of no more than 500 data sets or 15,000 extents (probably less).

Tip: As a comparison, straight volume migration requires less planning. Start with the donor-target list and create smaller “migration” groups of volumes with similar characteristics (such as application or LPAR assignment). Use standard IBM tools to process any migration exception/exclusion volumes as identified by the third-party software solution.  

UCB constraints—everyone has them! Today’s reality is that customers face UCB constraints in their data centers. Host-based migration solutions exacerbate this issue with the requirement of another set of device addresses to provide access to the target volumes.

Many customers continue to hold on to the idea of using 3390-3s due to reluctance to change.  Consolidation to larger sizes such as -9s, -27s, or -54s are all viable solutions, especially with the use of dynamic Parallel Access Volumes (PAVs). 

Tip: Device consolidation during the migration process should be considered. Three items to always consider: ensure the catalog is healthy, the VTOC is properly sized, and the appropriate type and number of PAVs are included. Further exploitation of HyperPAVs will allow better PAV use and potentially reduce the number of PAV aliases defined.