FDRPAS best practices

Congratulations on your choice of BMC Compuware FDRPAS for fast and safe non-disruptive DASD migration. This quick start guide describes some of the practices that have enabled our customers to maximize their success over hundreds of migrations.

The following are some practices that have enabled successful migrations:  

• Include the DD statement //FDRSUMM DD SYSOUT=* in the JCL for all SIMSWAP / SIMSWAPMON / SWAPDUMP / SWAP jobs. This provides a one-line summary for each volume.
• For each LPAR on which a SWAP or MONITOR job will run, install the PASPROC cataloged procedure in a system procedure library and update the DSN of the appropriate FDRPAS LOADLIB.
• The more LPARs that are running MONITOR jobs, the more important it is that those jobs respond in a timely manner. Ensure that the LPARs are not capped, and that the MONITOR jobs run with a high dispatching priority.
• For large scale swaps (greater than 100 jobs), each SWAP job should be paired with a matching MONITOR job. Use the SWAPID= keyword on the SWAP and MONITOR jobs to create the matching pairs. For example, SWAPID=001 on the SWAP TYPE=FULL control statement should be paired with a MONITOR TYPE=SWAP that also has SWAPID=001.

• A single MONITOR job must not be used to monitor a large number of volumes–this could result in numerous PASPROC started tasks being initiated. For example, MAXTASKS of 85 requires 10 meg of private for each swap job. Any more than that risks storage allocation abends.

  Important

  These jobs are affected by environmental variables which are unique to each customer site.

• When using CONFIRMSWAP=YES or CONFIRMSPLIT=YES, the number of MOUNT control statements in each SWAP job should not exceed the MAXTASKS= value. If there are more MOUNT control statements than the MAXTASKS= value, then those extra volumes will not be swapped and the CONFIRM step will not complete. For example, if MAXTASKS=85 is coded, then there should be a maximum of 85 MOUNT control statements in that SWAP job.
• Do not code MAXTASKS= on the MONITOR TYPE=SWAP control statement; let the MONITOR jobs use the default value.

• If you are performing a large SWAPDUMP or are using IBM GDPS/PPRC HyperSwap, the following example will help you understand the use of MAXTASKS= and SWAPID=:

  If there are 600 volumes to be migrated, then using MAXTASKS=75 would require 8 SWAP jobs, each with 75 MOUNT control statements. There would also be matching MONITOR jobs (for each of the involved LPARs) by using SWAPID=001 till SWAPID=008. 
  

  Important

  A high number of MAXTASKS is only needed in cases when you want the SWAP or SWAPDUMP to complete at the same time for all volumes, in which case you will need multiple SWAP jobs and multiple MONITOR jobs and a connection by SWAPID.

• (Optional) Assign the FDRPAS catalog alias to a user catalog so that FDRPAS can record history records.
• Ensure that the FDRPAS ISPF panels are installed and program FDRPASA is added to both the AUTHPGM and AUTHTSF lists in SYS1.PARMLIB(IKJTSOxx).
  
  • The FDRPAS ISPF interface enables you to SUSPEND and RESUME active swaps if it is necessary.
  • From the TSO / ISPF command line enter TSO PARMLIB UPDATE(xx) to activate the updated IKJTSOxx member.
  • From the TSO / ISPF command line enter TSO PARMLIB to display the current IKJTSOxx parameters.
• Unless you experience a degradation in overall system performance as a result of FDRPAS copy I/O, do not use static or dynamic I/O pacing to insert a time delay between write I/O operations to the target volumes. The ISPF panels allow you to specify a PACEDELAY for any individual pair of source/target volumes. Note that PACEDELAY=5 will result in a significant write delay, while PACEDELAY=10 or 20 will result in an extremely long write delay.
• Once the SWAP has completed, the HMC LOAD values and IODF LOADPARM must be updated to IPL from the new DASD subsystem.

For information about the access to referenced documentation and the most recent supplemental documents, see FDRPAS-User-Guide.

Security considerations

Ensure that the user ID under which FDRPAS runs, has RACF authority for batch jobs and started tasks. FDRPAS checks the following RACF Facility classes for READ authority:

• FDRPAS.SWAP
• FDRPAS.SWAPDUMP
• FDRPAS.SWAPBUILDIX

When swapping from smaller to larger devices, FDRPAS invokes ICKDSF BUILDIX to rebuild the Indexed VTOC. You must ensure that the user ID under which FDRPAS runs, has RACF authority to execute ICKDSF.

Getting started

After the z/OS operating system and the new DASD hardware are configured, issue the z/OS DEVSERV command (DS P,uuuu) against all the SWAP target offline devices on each LPAR to verify that every device is accessible and configured correctly. The CHPID should show a + after each path.

The following is a sample output from the DEVSERV command:

Ensure that there is sufficient below-the-line private area storage available before choosing the value to use for MAXTASKS= in your SWAP tasks. For example, MAXTASKS=85 will require a below-the-line private area of approximately 10 MB for each SWAP job. Run the FDRDEBUG program on each LPAR to display the available private storage area. To view a sample job step, see FDRPAS Operation in the FDRPAS-User-Guide. 

Before you begin

Before you begin migration by using SWAP or SWAPDUMP, we recommend that you perform the following related tasks:

1. Run SIMSWAP with all the volumes on each z/OS LPAR that will participate in the SWAP. The CHECKSOURCE=YES keyword only needs to be specified for just one of the LPARs on which the SIMSWAP runs.

   Important

   If SIMSWAP with CHECKSOURCE=YES finds VTOC or VVDS errors, these should be corrected before proceeding with the actual SWAP / SWAPDUMP.

2. Run SIMSWAPMON of all the volumes to ensure that all the LPARs and actual MONITOR jobs can successfully communicate with the actual SWAP jobs.
3. Run a SWAPDUMP test job with MAXTASKS=20 with 20 representative test volumes, each of which is at least 80 percent allocated, prior to attempting execution of the actual DASD migration. This enables you to generate benchmarks for elapsed time and performance.

Constraints on other software and processes

While your FDRPAS SWAP is running, you must ensure the following:

• Do not re-IPL any of the systems.
• Do not issue z/OS CONFIG commands for the CHPIDs.
• The source volumes are not VARYed Offline or VARYed Online.
• The targets volumes are Offline on all LPARs.
• No other software is issuing I/O against the SWAP target devices.
• Inbound FlashCopy is automatically disabled on the source volume.
• Cache Fast Write should not be active.
• Disable zHyperLink if it is active.
• While running FDRPAS jobs, avoid any hardware disk upgrades, including the microcode on the source or target DASD frames.

ECSA usage on SWAP or SWAPDUMP of large EAV volumes

FDRPAS must monitor updates on each volume to re-copy every updated track. To ensure this, it allocates a track table for each volume in ECSA. This track table needs one bit for each track (the calculation is 1K per volume plus two bytes per cylinder) so in general, these track tables are small and ECSA usage will not lead to any issues. 

The parameter – TRKTAB=NEW, helps avoid this problem. It will split the track tables into units of 4K and allocate only those units that are needed during the actual copy or update cycle. The effective size of the track tables will vary, depending on update activity on the respective volume. 

FDRPAS user documentation

• It is important to review the hardware and software considerations mentioned in FDRPAS Special Considerations in the FDRPAS-User-Guide. For environment-specific information, refer to the subsequent sections. 

• If you are using IBM GDPS/PPRC HyperSwap, be sure to run the Special 4-Step Job as covered in the FDRPAS-User-Guide, under the topic FDRPAS and IBM GDPS/PPRC HyperSwap. Place all the source volumes into one MONITOR TYPE=CONFIRMSWAP job. 

  Important

  This procedure allows HyperSwap to remain enabled while the data is being copied to the target volumes, then disables HyperSwap during the actual UCB SWAPs, and finally re-enables HyperSwap immediately afterwards.

• If z/VM systems need to be migrated, then review the section FDRPAS z/VM and Linux on IBM Z considerations in the FDRPAS-User-Guide.

Considerations related to FDRPAS product version and IBM APARs

• Ensure that you are running the most current release and maintenance level of FDRPAS.

• Release level 5.04.90P or higher will allow Local Page Data sets to be swapped using the keyword PAGE=DRAIN. 

  Important

  • Local Page Data sets cannot be swapped with older release levels.
  • This is designed to work if there are multiple Local Page Data sets on different volumes that are not swapped at the same time.
• Apply IBM APARs OA58265 and OA58588 to all systems before attempting to perform the actual SWAP.