FDRPAS special software considerations

This section documents special software considerations for the use of FDRPAS. It is as complete as possible and contains all the considerations that are known to BMC at the time of publication. However, there may be other considerations that have not been identified or that were discovered after publication.

This section should be reviewed carefully before performing any FDRPAS operations.

For the latest updates to software considerations, see BMC Support.

Required IBM and ISV Maintenance

Depending on the level of your operating system, you may need to apply certain IBM PTFs to successfully swap volumes and to avoid problems after the swap. Some of the PTFs are critical; if they apply to your system, they must be applied to avoid problems. Others are recommended; you must decide if the problems that the PTFs fix impact your system.

It may also be necessary to apply maintenance to certain ISV (third-party) software products so that they successfully support FDRPAS swaps. Details are below.

The Compatibility section of the BMC Support for FDRPAS should be reviewed as well as the latest Technical Alert that lists IBM and other 3rd party vendor fixes that BMC is aware of. This document is frequently updated, so be sure and get the latest copy before you begin any swaps. This document shows which IBM APARs apply to each level of the operating system, which ones are critical or recommended, and gives a brief description of each.

You must review this list to determine which APARs you must apply. Even some of the critical ones may not apply to your installation. Complete descriptions of the APARs and copies of the fixing PTFs can be obtained from IBM.

PAGE and SWAP Data Sets

Volumes with page data sets can be swapped with FDRPAS.

There are no special considerations for volumes with inactive page data sets.

Volumes containing active PLPA and common page data sets can be swapped with FDRPAS without special operands. If the common page data set is updated by a page-out during the swap, it is recopied during the next pass.

To swap volumes containing active local page data sets, you must specify the PAGE=DRAIN operand on the SWAP/SWAPDUMP and MONITOR statements. PAGE=DRAIN causes FDRPAS to internally issue a z/OS PAGEDEL DRAIN command before starting to copy the volume, and a PAGEADD command after the SWAP or SWAPDUMP is complete. PAGEDEL DRAIN puts the page data set into read-only status; no new pages are written to this data set, but pages that are already there continue to be available. The Operating System does not waste any resources copying the pages to other page data sets. PAGEADD returns the page data set to normal read-write status. PAGE=DRAIN only needs to be specified for the SWAP/SWAPDUMP or MONITOR job on the LPAR that is using the page data set, but it is usually more convenient to specify it for all of the jobs that process that volume.

The userid under which FDRPAS is running may need authorization under the security system in order to issue the PAGEDEL and PAGEADD commands. The STGADMIN operand can be used to provide this authorization. Check your security system documentation and the rules of your installation.

We recommend not having more than half of your paging capacity in DRAIN status at any one time. You can control this by putting all of the page volumes that you want to migrate, into one SWAP/SWAPDUMP job, and specifying an appropriate MAXTASKS value. In addition, z/OS may not allow PAGEDEL DRAIN to reduce the paging capacity below a system-determined number of data sets, or below a system-determined percentage of the previous paging capacity. In the extreme case, if a system has only one local page data set, it cannot be drained, and therefore it cannot be swapped. The PAGEDEL DRAIN command may fail because of these rules, or because different FDRPAS tasks on the same LPAR issue the command within too short a time period (z/OS can only execute one PAGEDEL command at a time).

If an LPAR does not have enough paging capacity to support PAGE=DRAIN, you can define new page data sets on the target DASD, with IDCAMS DEFINE PAGESPACE and the PAGEADD command, and then use PAGE=DRAIN. Or, if for some reason you do not want to use PAGE=DRAIN, you can migrate page data sets outside of FDRPAS. You can define new page data sets on new volumes on the desired DASD hardware, and migrate the paging activity to them with the console PAGEDEL REPLACE command, or the console PAGEADD and PAGEDEL DELETE commands.

JES SPOOL and CHECKPOINT Volumes

JES2 and JES3 spool volumes can be swapped with FDRPAS.

FDRPAS can identify JES SPOOL and CHECKPOINT volumes and ensure that they are processed with no other volumes. The operand PRINT=ALL should not be specified when swapping JES volumes, to avoid potential interlocks.

If a volume to be swapped contains a JES2 checkpoint data set, there is one consideration: if this is a single-system JES2 checkpoint (not MAS - multi-access spool), the default for the HOLD operand on the MASDEF statement in the JES2 startup parameters is HOLD=9999999, which causes JES2 to hold a permanent RESERVE on the checkpoint volume. FDRPAS cannot swap a volume while a RESERVE is held, so the swap fails (no harm is done, but the swap is not successful). To circumvent this permanent RESERVE, issue this console command on the system that owns the checkpoint volume to set the RESERVE time to 1 second: $T MASDEF,HOLD=100

After the swap you can reissue the command with HOLD=9999999 if you like.

Sysplex Coupling Data Sets

Sysplex Coupling Data Sets (CDS) are used in a Parallel Sysplex, in conjunction with a coupling facility. A volume containing an active Sysplex Coupling Data Set can be swapped with FDRPAS.

FDRPAS can identify active sysplex Coupling Data Set volumes and ensures that they are processed with no other volumes.

There is a consideration when swapping the volume that contains the active sysplex CDS. Other types of CDSs are not affected. The console command:

can be used to display the primary and alternate sysplex CDS names, and their volsers. Note that after a swap, the device address displayed by this command may still reflect the source volume; this is not a problem. Cross-system Communication Facility (XCF) is sensitive to I/O delays on the sysplex CDS, such as the delays caused when FDRPAS suspends I/O to the volume during a swap.

However, CDS errors are very unlikely to occur. No error is detected unless the XCF “failure detection interval” (default 25 seconds) is exceeded. It is very unlikely that FDRPAS would suspend I/O for that long. Even if the failure detection interval should be exceeded, it results in console message IXC426D. The operator must simply reply “R” to retry and continue.

To be certain that no problems occur when swapping a volume that contains the active sysplex CDS, there are two options:

1. 1. Increase the failure detection interval on every system with the console command:
   SETXCF COUPLE,INTERVAL=nnn
2. Switch to the alternate sysplex CDS with the console command:
   SETXCF COUPLE,PSWITCH

Then you can swap the volume that contains the now-inactive primary sysplex CDS. Afterwards, you can switch back to the primary and swap the volume that contains the alternate.

JES3 Managed Volumes

FDRPAS supports swapping DASD volumes managed by JES3. JES3-managed DASD volumes are those that are referenced by a DEVICE statement in the JES3 initialization statements (the “INISH deck”). DASD that are not referenced by a JES3 DEVICE statement are managed only by z/OS. Both kinds of DASD can be swapped with FDRPAS on a JES3 system.

If the target device for a SWAP is JES3-managed, then before the SWAP starts, the target device should be offline to JES3 as well as to z/OS. If the device is online, you can use the *VARY or *V command of JES3 to VARY the device offline to both JES3 and z/OS.

JES3 is aware of the swap of JES3-managed DASD volumes and handles them properly. However, you may need to update the DEVICE statements in the INISH deck before the next IPL so that it properly recognizes the new devices.

Note that if you use varying values for the XTYPE= parameter on the JES3 DEVICE statement, the first sub-parameter of XTYPE must match in the source and target devices. For example, a source volume defined as:

Can only be swapped to a target DASD volume that also specifies an XTYPE with DSYSTEM.

Oracle StorageTek Products

If you have tape software from Oracle StorageTek prior to HSC 6.2, shutdown HSC (Host Software Component) before swapping the volumes containing the HSC CDS (control data set) and restart it after the swap.

If you have HSC 6.2 or above, you must NOT shut down HSC on z/OS while swapping the volumes containing the HSC CDS. If HSC is running when a CDS volume is swapped, HSC recognizes that a SWAP has taken place and dynamically updates the CDS with the new device address. If HSC is not running when a CDS volume is swapped, then when you try to bring HSC back up, it detects that the device address of the CDS has changed and refuses to initialize.

On z/VM, HSC in any release needs to be shut down during a SWAP of the volumes containing the CDS.

CICS Journal Data Sets

There is a consideration for sequential CICS journal data sets. Sequential CICS journal data sets are the old-format journal files that are used in older levels of CICS. This does not apply to system logger files (including DASDONLY), which is the only supported format for CICS journals in CICS/TS 1.1 and above.

CICS journal files have a DSORG of PS or PSU and usually have a data set name containing an index level starting with DFHJ. CICS preformats these files so that it can recognize a journal file that was not properly closed. However, when swapping a journal file that is currently inactive (CICS not running), FDRPAS may not copy all of the preformatted tracks, resulting in CICS startup errors.

This problem only occurs for inactive journal files with DSORG=PS, not PSU. DSORG=PSU journal files and all journal files that are currently allocated by a CICS system are copied correctly; only DSORG=PS journal files for inactive CICS systems may have a problem when the CICS system is next restarted.

If you think you might be subject to this consideration, contact BMC Support for a circumvention.

System Residence Volumes

There are two volumes that are used during a system IPL, referenced by device address. These volumes can be moved with FDRPAS, but it is your responsibility to update your IPL parameters and system documentation with the new device addresses before the next IPL. Failure to do so may result in the IPL process using the old devices, with unpredictable results.

One of these is the system residence (IPL) volume, or SYSRES volume. The address of the SYSRES volume is specified on your hardware console and is usually called the LOAD ADDRESS.

The other is the IODF volume. The IODF volume contains the I/O configuration data sets and may contain system parameter libraries used during IPL. The address of the IODF volume is also specified on your hardware console as part of a string usually called the LOAD PARAMETER.

Depending on the type of hardware you are using, the LOAD ADDRESS and LOAD PARAMETER may be stored as part of an activation profile. Be sure to update all appropriate activation profiles with the new device addresses.

FDRPAS identifies all swapped volumes with IPL text on the label track or an IODF data set in the VTOC and generates message FDR252 on the console to warn that such parameter updates may be required.

System Data Mover (SDM)

An XRC “utility volume” is a device address that the System Data Mover (SDM) uses for reading changed data from a control unit. Since the utility volume is physically associated with the control unit, it must not be swapped. Instead, you would set up a new utility volume in the new control unit when the new control unit is added to the XRC configuration.

There are several options for utility volumes:

• Floating utility devices - Any device in the storage control can be dynamically selected as the utility device. In this case, the question of swapping the utility device would not arise; devices within the physical control unit would continue to be selected as long as the session remains active.
• Fixed utility devices - A specific device in the primary control unit is given a secondary volume of “XRCUTL”.
  • The “utility volume” does not have to be an actual volume that contains user data; it can be a single cylinder volume that is only used by XRC. In this case, it clearly should not be swapped.
  • The utility volume could be an actual volume containing user data. IBM recommends against this option because it can result in contention that slows down I/O for SDM and/or the application. using the volume for user data. If you try to SWAP a user volume that is being used as a fixed utility device, results would be unpredictable. Do not to this.

SADMP

If volumes that contain dump data sets used by the IBM IPLable stand-alone system dump program (SADMP) are swapped, you may need to re-generate the SADMP program and/or reinitialize the dump data sets, because the SADMP program contains the unit address of the first volume of the dump data set, and the first volume of the dump data set contains the unit addresses of the later volumes, if any. Check the IBM manual z/OS MVS Diagnosis: Tools and Service Aids manual for instructions.

Broadcom Products

There are considerations if certain products from Broadcom are in use in your installation.

CAACF2

If the DASD volumes containing the ACF2 database is being swapped, ensure that the ACF2 logonid that runs the FDRPAS jobs have the NO-SMC (Step Must Complete) attribute to prevent a lockout between FDRPAS and ACF2.

For SYNCFILE Performance Enhancer: (This is only a consideration with FDRPAS Version 54L80 and lower. FDRPAS Version 54L83 and higher supports this function.)

If you use CAACF2 with the SYNCFILE performance enhancer (caches recent database accesses) option enabled and swap a volume that contains the ACF2 SYNCFILE, the SYNCFILE process on every system where it is active must be disabled before performing the swap. There is no function loss while the SYNCFILE process is disabled. To disable the ACF2 SYNCFILE, modify the ACF2 options file to SYNCOPTS NOACTIVATE and refresh the options with the console command: F ACF2,REFRESH(OPTS),SYSID(cpuid).

After the swap of the volume completes, change the option back to SYNCOPTS ACTIVATE and refresh the options again.

For additional information, refer to Broadcom document TEC477001.

CAASTEX

If you use CAASTEX, you must contact Broadcom to get any maintenance that affects FDRPAS (or search for FDRPAS on their support site) and apply it. If all such maintenance is not applied, stop CAASTEX before swapping any DASD volumes and restart it after the swaps are complete.

CAMIM

If you use CAMIM with a DASDONLY control file, the volume containing the currently active control file cannot be swapped. One solution is to issue a CAMIM command to switch to the alternate control file while the volume containing the primary control file is swapped. Other CAMIM control file options, such as CTCONLY and CTCDASD, should not be a problem.

CASCHEDULER

If you use CASCHEDULER at a level less than V9.0 and you swap any volume containing data sets used by CASCHEDULER, CASCHEDULER must be stopped before the swap and restarted after the swap. In V9.0 and above, CASCHEDULER does not have problems with swap.

Software AG ADABAS

Cache Fast Write (CFW)

There is no exposure to Cache Fast Write (CFW) IO errors in ADABAS V814 and later versions. An exposure exists in ADABAS V813 and earlier to report Cache Fast Write (CFW) IO errors after an FDRPAS swap. Contact SoftwareAG technical support referencing SAGSIS incident number 308599 for details for any available maintenance or problem circumvention.

FDR234** SWAP ERROR REASON=C and REASON=E

ADABAS builds a channel program containing a Prefix command, but did not set the flag telling IOS not to add its own Prefix. The symptoms in FDRPAS are swap failures with messages FDR234** SWAP ERROR REASON=C and REASON=E. Refer to Software AG incident number 1051648 for the recommended fixes for this problem for ADABAS V822 through V825.

ADAI40 zHPF unavailable - Retrying I/O in ECKD mode

We recommend coding ALLOWZHPF=YES on all the SWAP, SWAPDUMP, and MONITOR control statements to prevent ADABAS from issuing message ADAI40 repeatedly, possibly flooding the console, and, in a GDPS environment, possibly causing PPRC to be suspended.

ENF Signals

Immediately after an FDRPAS swap completes, an ENF (Event Notification Facility) signal is issued on each system to indicate that the swap was done. Event code 10 (SWAP) is issued, but an ENF exit translates this to event code 28 (SWAP DYNAMIC) on most systems. Software systems that are sensitive to DASD volumes being swapped to new devices listen for those ENF signals, and can take appropriate action to access the volume on its new device address.

Users of the Allocation Control Center (ACC) or Space Recovery System (SRS) products from DTS Software should ensure that fix DTS22560, to monitor ENF swap signals, is installed.

If you have other software products that may be sensitive to the device address of a given volume, ask the vendor if they honor ENF SWAP signals.

Some system monitoring products (such as TMON) may not properly report on swapped volumes if they have not implemented the ENF support. It is usually sufficient to stop and restart those products after the swaps to recognize the new device addresses.

Programs that access offline DASD

Avoid executing programs that access offline DASD devices, since they may access or modify an FDRPAS target device during the swap, with unknown results.

ICKDSF can be used to initialize or modify offline DASD volumes. You should not run ICKDSF against an FDRPAS target device. FDRPAS does check to see if the target volume has been re-initialized and terminates the swap.

FDRPAS program library

You can successfully swap the DASD volume that contains the FDRPAS program library. However, we recommend that you swap this volume by itself, with no other swaps running.

Active data sets

Normally, FDRPAS identifies active data sets by testing to see if another task holds a SYSDSN enqueue on the data set. Active data sets are handled with complete integrity during the swap.

For inactive (non-enqueued) Physical Sequential (PS), Partitioned Organization (PO), and VSAM data sets, FDRPAS improves performance by copying only the used tracks within those data sets.

In rare cases, a task may use a data set without holding a SYSDSN enqueue on it. One such case is a started task whose program is in the Program Properties Table (PPT) with the NODSI option (very few programs use this option). If such a task is updating a data set without holding the enqueue, FDRPAS may not be able to ensure integrity on the data set. Additional validation is done on PS and VSAM data sets to avoid this problem, but updated Partitioned Organization (PO) data sets may not be detected. If you think you may have this exposure, contact BMC Support for assistance.

Although JES2 has the NODSI option in its PPT entry, JES2 does not update any of the PDSs that are allocated to it, so this is not an exposure. TSO users or batch jobs that update JES2 PROCLIBs and other PDSs enqueue the data set during the update.

It is not necessary to close any open data sets on volumes being swapped. This includes data sets such as catalogs and databases. The FDRPAS swap is transparent to all applications that use the DASD volume.

SYSRES volume allocation by FDRPAS

You may notice that FDRPAS may do a dynamic allocation to your system residence volume during its operation. This dynamic allocation is normal. This dynamic allocation does not mean that FDRPAS is swapping your SYSRES volume (unless you have requested FDRPAS to swap your SYSRES volume).

In addition, if an FDRPAS step has an error, the FDR998 or FDR997 message issued by FDRPAS at the end of the step may specify “VOL=sysres” with the serial number of your system residence volume. This does not indicate that any error occurred on that volume and can be ignored unless other error messages indicate a true problem with that volume.

Catalogs that use Enhanced Catalog Sharing (ECS)

If a volume that contains an ICF catalog that is enabled for Enhanced Catalog Sharing (ECS) is swapped, ECS sharing is disabled on that catalog. You receive message:

on each system. ECS uses a coupling facility to transmit catalog information between systems, so it is only available in a parallel sysplex.

IBM implemented this behavior in APAR OW48166 and fixed it to operate correctly in APAR OA10139, because Enhanced Catalog Sharing (ECS) uses the device address of the catalog in its sharing logic. The text of APAR OW48166 says, in part:

“The code has been changed to recognize when the volume has been moved to a new hardware device. Any catalogs currently in ECS that are on the affected device are removed from ECS and marked temporarily ineligible. In order for the catalogs to be re-enabled for ECS usage, the installation must issue either the:

MODIFY CATALOG,ECSHR(ENABLE,catn)

or

MODIFY CATALOG,ECSHR(ENABLEALL)

command. The command to re-enable the catalogs may be issued from any system, but should NOT be issued until all systems that share the catalog have removed it from the CF. This may be verified by issuing the command MODIFY CATALOG,ECSHR(STATUS) on all sharing systems. All systems that display the catalogs named in the IEC378I messages shown above should indicate a status of 'Inact(NonECSAcc)'. Once all sharing systems indicate this, the catalog may be re-enabled for ECS use as described above.”

However, it may be safer to remove catalogs from Enhanced Catalog Sharing (ECS) before swapping them, and re-enable Enhanced Catalog Sharing (ECS) after the swap.

Esoteric names

Esoteric names are symbolic unit names that are defined in your I/O configuration and relate to specific device addresses. Esoteric names are used in UNIT= parameters in JCL and dynamic allocation. For example, UNIT=SYSDA is an esoteric name.

If you are swapping a volume that is included in an esoteric name, and the target device is not included in that esoteric name, then any job or dynamic allocation that uses the esoteric name to allocate the volume fails after the swap is complete. You must either update the esoteric name to include both the source and target devices before the swap, or update the esoteric name immediately after the swap. Consult IBM documentation for information on defining and changing esoteric names.

Allocation by specific device address

It is possible to use specific unit addresses in UNIT= JCL parameters and dynamic allocations to allocate specific DASD volumes, for example, UNIT=3A2 or UNIT=/125A.

It is rare that JCL uses specific unit addresses, but it is more likely that programs that dynamically allocate DASD volumes might use z/OS services to get the unit address of a DASD volume and use that address in a dynamic allocation. If a job or dynamic allocation uses a specific unit address obtained before an FDRPAS swap completes, but does the allocation after the swap, it fails.

JCL using specific unit addresses should be changed (to use generic or esoteric names, preferably) and programs using dynamic allocation may need to be rerun.

Enqueue propagation

This section might not apply if you are licensed for FDRPASVM. See the FDRPASVM documentation for further details.

FDRPAS does enqueues with major names of FDRPAS, FDRPASQ, and FDRPASU* with SCOPE=SYSTEMS to indicate that swaps are in progress. The enqueues are used to detect duplicate swap requests and inhibit certain operations. It is required that these enqueues be propagated to all systems involved in the swap. If these enqueues are not propagated to some systems, FDRPAS is not be able to detect duplicate swap requests and the ISPF panels on systems running MONITOR tasks do not detect the swap in progress until synchronization has completed on all systems. However, FDRPAS still operates correctly even if all the systems involved are not part of the same GRS complex or MIM complex. You should not convert the FDRPAS, FDRPASQ, and FDRPASU* enqueues to SCOPE=SYSTEM. CAMIM users may need to add these major names to a MIM QNAME list in order to propagate them.

FDRPAS uses a RESERVE on the target device to communicate between the PAS SWAP job on the local system and PAS monitor jobs on remote systems. This RESERVE uses a QNAME of FDRRESV. This QNAME must not be converted to a global ENQ. For GRS users, FDRPAS will query the GRS RNL list and if it is found that the RESERVE would be converted, FDRPAS issues an error message and terminates with user abend code 614.

FDRPAS Use of ICKDSF

If you are using FDRPAS to swap a volume to a larger device, such as a 3390-9 to a 3390-27, you must specify LARGERSIZE=OK. At the end of the swap, if the volume has an active indexed VTOC (VTOCIX), FDRPAS invokes ICKDSF to rebuild the VTOCIX (BUILDIX) to reflect the new size of the volume. FDRPAS coordinates the VTOCIX update on multiple systems.

The VTOC or VTOCIX size on the volume may not be adequate after you swap it to a larger DASD volume and start adding new data sets to the volume. If you are licensed for FDRMOVE, you can use the EXPANDVTOC operand to expand the VTOC on these volumes. See SWAPBUILDIX-and-EXPANDVTOC-statement for further information on EXPANDVTOC.

• A 3390-27 requires a minimum of (2) tracks for the Indexed VTOC.
• A 3390-54 and a 3390-A EAV require a minimum of (4) tracks for the Indexed VTOC.
• If the Indexed VTOC is not allocated with the minimum specification, then a U0888 ABEND and the following FDR254 error message results when FDRPAS invokes ICKDSF BUILDIX IXVTOC:

IBM has determined that an enqueue interlock can occur when doing this type of BUILDIX if the SYSVTOC and SYSZVVDS resources are being treated differently by your cross-system enqueue facility (GRS or CAMIM). For GRS, IBM added a requirement to the GRS Planning Guide stating that SYSZVVDS and SYSVTOC must either both be in the RESERVE CONVERSION RNL or both be in the SYSTEMS EXCLUSION RNL. For CAMIM, the equivalent rules must be in effect. Failure to do this may cause the BUILDIX to hang.

Static and dynamic UCBs

In the I/O configuration, defined with HCD, the UCB for each DASD device can be defined as “installation static” or “dynamic”. Consult the IBM HCD documentation for details.

FDRPAS can swap a volume from a static UCB to a dynamic UCB and vice versa. If you have never before had dynamic UCBs in your installation, you should verify that locally-written and vendor (ISV) programs include support for dynamic UCBs. Programs using the IBM UCBSCAN and UCBLOOK services must include the operand DYNAMIC=YES to find dynamic UCBs.

4-Digit device addresses and UCBs above the line

FDRPAS can swap between DASD devices with 3- and 4-digit device addresses and between UCBs that are located below the 16MB line and above the 16MB line (LOCANY=YES in the HCD configuration).

However, before you swap a volume to a 4-digit device or a device with its UCBs above the line, you should be sure that all software using the volume has been upgraded to support such devices. It is possible that the volume was on a 3-digit device or a UCB below the line precisely because the software using it has not yet been upgraded.

When FDRPAS swaps between a UCB below the line and one above the line, the target device UCB is below the line. However, after the next IPL, it reverts to an above the line UCB.

Full-Volume restore and copy

If FDR, DFSMSdss, or another DASD backup/restore product is used to do a full-volume restore or copy to a volume that FDRPAS is currently swapping to another device, you should examine the volume after the swap is complete to ensure that the device characteristics in the VTOC and VTOC index (VTOCIX) are correct.

A full-volume restore or copy operation may make changes to the volume size in the VTOC and VTOCIX when the target device is larger than the volume on the backup (for a restore) or the source volume (for a copy).

Unfortunately, the full-volume restore/copy program may make decisions about the VTOC changes to make based on the characteristics of the volume at the time the restore/copy begins. When FDRPAS is swapping the device, this would be the original source volume. However, the restore/copy may not complete until after FDRPAS has swapped the volume to its new device. The new device may be a larger device than the original. The decisions made by the restore program before the swap may not be valid after the swap, so the changes it makes to the VTOC and VTOCIX may not be valid.

In addition, FDRPAS itself may make changes to the VTOC and VTOCIX when the alternate tracks and device size of the target device are different from the source volume. FDRPAS and the restore program may make conflicting changes to the VTOC. Even worse, if the restore/copy program changes the location of the VTOC or VTOCIX during the restore, FDRPAS may update the wrong copy of the VTOC or VTOCIX.

If you know that a full-volume restore or copy was done during an FDRPAS swap, you should use tools such as FDREPORT, COMPAKTOR, IEHLIST, or other DASD mapping software to validate that the number of data cylinders in the VTOC and VTOCIX is correct.

In any case, it makes little sense to use FDRPAS to swap a volume if you are going to completely replace it with a restore or copy. If you know that a restore/copy is done, it is simpler to restore or copy the volume to its new device directly instead of using FDRPAS at all.

This consideration does not apply to data set restores and copies.

System names

Many FDRPAS messages, and other parts of this document, refer to “systems” or “system names”. Some FDRPAS messages refer to them as CPUs.

These system names come from the field CVTSNAME in the Communication Vector Table (CVT) of each system (sometimes referred to as a “system image”, an “image” of the operating system). The system name is assigned by the IEASYSxx member of PARMLIB. Each system involved in an FDRPAS swap must have a unique system name. To display the name of a system, type this console command on a console connected to the system:

and you receive a display similar to:

Figure 320.1: Display the Name of a System (D GRS)

The first system listed (CPUB in this example) is the system name of this system.

CPU serial numbers

Some FDRPAS messages include CPU serial numbers.

The CPUID= value is the 10-character CPU serial number of a system image. When you run a SIMSWAP job, the CPUID values display on the FDR233 message as shown in this example:

You can also get the CPUID value is the on a specific z/OS system by executing this console command from a console attached to that system:

You get a response similar to:

Figure 320.2: Display the CPUID Value (D M=CPU)

Note that the first digit may be non-zero if you have a multi-processor system, as shown in this example. The first digit is always zero in FDRPAS message and parameters. The second digit is an LPAR number, if you have a system with multiple LPARs defined.

However, on a z990 system (last four digits are 2064) or any successor system, the first two digits may be the LPAR number, since those systems support more than 15 LPARs.

Dynamic monitoring (DYNMON)

In a GRS or MIM complex environment, FDRPAS MONITOR tasks can run without specifying any devices or MOUNT statements, letting the MONITOR tasks dynamically allocate all the volumes.