FDRPAS special hardware considerations

This chapter documents special hardware considerations for the use of FDRPAS. It is as complete as possible and contains all considerations 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 hardware considerations, go to the BMC Support.

Relocating a data center

FDRPAS can be used to relocate a data center by duplicating all of the online volumes in new DASD subsystems at the new site. Details on the procedures and considerations are in FDRPAS for Large Scale Synchronized Migration (Using CONFIRM). Contact BMC Support for planning assistance for a large synchronized migration (1000 volumes or more).

Preparing the target devices

The target devices should be varied offline to all system images. If the target device is not offline on an LPAR where a MONITOR task is running, special checking is done by the MONITOR task to ensure that this device is the same target device as specified by the main FDRPAS process and that the device is inactive on the LPAR this MONITOR task is running on. If so, then this volume is varied offline by this MONITOR task.

However, you must not mark the target devices as offline in your I/O configuration. If this is done, the device would be offline at the next IPL and the operating system would not find the volume at its new location.

You do not need to initialize the target devices in any way. FDRPAS is not sensitive to the contents of the target devices. However, you can initialize them if you like; this prevents annoying messages at IPL time. If you specify the CHECKTARGET=YES operand, the target must be uninitialized (no valid volume label), or initialized but empty.

Query Host Access Support

Query Host Access (QHA) is supported and utilized for the storage subsystems that support this function. This function gives FDRPAS a list of all the LPARs that have the volume online, allowing FDRPAS to ensure that monitor tasks are running on all these LPARs. Most, if not all, of the storage subsystems now support QHA; if the storage subsystem at your site does not support QHA, contact BMC Support for additional information on this subject.

Multi-System Determination

In some environments, FDRPAS may identify some systems that have a given DASD volume online but are not able to participate in an FDRPAS swap. Since FDRPAS does not know they are unable to participate, they can result in an FDR234 REASON=M message and an FDRW68 message indicating non-responding systems. Possible causes include:

  • LPARs that are currently idle. This means that the operating system has been shutdown or a Stop has been issued from the Hardware Management Console (HMC), but Deactivate or Reset has not been issued from the HMC. In this case, the recommended response is to issue the Deactivate or Reset from the HMC.
  • LPARs that are running z/VM but that are not running a z/OS-type guest operating system under z/VM, and are not running an FDRPASVM monitor. In this case, the recommended response is to VARY the device offline on the z/VM LPAR, or run an FDRPASVM monitor; otherwise, you must shut down the z/VM LPAR (including issuing Deactivate or Reset form the HMC).

The z/VM VARY command specifies the device number, not the volume serial.

  • LPARs that are running natively a non-z/OS-type operating system, such as Linux or VSE. In this case, the recommended response is to VARY the device offline on that LPAR; otherwise, you must shutdown that LPAR (including issuing Deactivate or Reset from the HMC).

  •   LPARs where the FDRPAS MONITOR task has a low priority, or LPARs that have a low priority, may prevent the MONITOR task from responding in time. We recommend that you reply “RETRY” to the FDRW68 message at least once to allow such systems time to respond. You should always contact BMC Support

     before responding “YES” to this message.

  • The SDM (System Data Mover) system for XRC (Extended Remote Copy, also called zGM (z/OS Global Mirror)). In this case contact BMC Support and ask for document PAS0004.

Starting and Stopping Systems During Swaps

If possible, you should avoid shutting down or IPLing systems or LPARs while FDRPAS swaps are running. At the very least, you should make arrangements so that the person running FDRPAS is notified of any scheduled or unscheduled shutdowns or IPLs.

If a system has an unscheduled shutdown, such as a system crash or hardware failure, any FDRPAS swaps that were running at the time usually fail with no harm done, if the failed system was participating. When the SWAP task does not get the required responses from the MONITOR task on the failed system, it prints a diagnostic message and fails the swap. If the failure occurs just at the last step of a swap, the swap may be successful and the failed system sees the volume on the new device when it is re-IPL’d.

If a system has a scheduled shutdown, then they need to CANCEL(C) or STOP(P) the FDRPAS job on that system; this normally lets any active swaps complete before terminating. If a MONITOR task is forced to terminate, then active swaps fail cleanly as described above.

If a system was not active when a swap started, but is re-IPL’d during the swap and puts the volume involved online, there is an issue. There is no FDRPAS MONITOR task running on that system, so it does not participate in active swaps. If swaps complete before a MONITOR task can be started on the new system, the system does not know about the swap and still tries to use the volume on the old device; if this occurs, contact BMC Support for assistance. If a MONITOR task is started before the swap terminates, FDRPAS recognizes that a system came in late and terminates the SWAP cleanly.

If you have used EXCLUDE statements, you should probably terminate any active swaps, update the parameters to account for the stopped or started system, and resubmit the SWAP.

Switching Cables and Configuring CHPIDs During Swaps

Switching, plugging and unplugging cables, and configuring CHPIDs (CONFIG CHP command), on devices that FDRPAS is currently swapping is not recommended because in extremely rare circumstances this may cause a volume to swap successfully in some systems, but to fail in other systems (the swap failure is accompanied by error messages FDR243 and FDR244). IBM issued APAR OA27065 for z/OS 1.10 to fix the swap failure caused by the CONFIG CHP command.

IBM 2105 / 2107 and DS6000 / DS8000 Hardware Considerations

  • If a source volume is in an IBM 2105 ESS with FICON channels, you should be at microcode level 1.5.2.114 or above so that FDRPAS can properly identify the attached systems. This does not affect target volumes but this microcode level is recommended even for target systems.
  • If you are swapping from a 2105, 2107, DS6000, or DS8000 DASD volume to a another DASD volume, FDRPAS turns off feature bits in the Device Characteristics Extension (DCE) of the UCB of the source volume for all features that are not supported by the target device. Any IBM software that was using any of these features should stop using them so that they do not cause errors when the swap to the new device is completed. These features currently include: FlashCopy, Prefix CCW, Read Track Data CCW, Write Full Track CCW, Write Track Data CCW, Locate Record Erase CCW, and Prestage Trackset CCW.
  • IBM FlashCopy: During a swap, the source volume cannot be used as the target of a FlashCopy since FDRPAS has no way of knowing that the source tracks are being updated. FDRPAS disables FlashCopy V2 (data set flash) in the hardware for the source volume during the swap so that any attempt to use it fails. Most products that implement FlashCopy (including FDRCOPY) automatically use normal read/write I/O when FlashCopy is not available.
  • PAV: Parallel Access Volume (PAV) is supported by FDRPAS. FDRPAS dynamically disables Parallel Access Volume (PAV) on the source and target devices during the swap. By default, FDRPAS performs the PAV disable at the beginning of the swap operation. (The default can be changed to by specifying the ALLOWPAV=YES operand on the MONITOR and SWAP/SWAPDUMP statements.) If you are swapping from one DASD device with PAV to another, PAV is re-enabled after the swap. However, if you are swapping from a DASD volume that does not have PAV to a DASD volume with PAV or vice-versa, PAV is disabled on the PAV device until the next time you IPL; this is an IBM limitation because of fields that exist only in the UCB of a PAV device. There is a circumvention: if you update your I/O configuration so that the non-PAV source volumes are defined as type 3390B (PAV base), then FDRPAS can enable PAV when you swap the volume to a PAV-capable device; if the target device has WLMPAV=YES (dynamic PAV) then the source volume should also be defined with WLMPAV=YES. IBM says that it is permissible to use device type 3390B for non-PAV DASD volumes, it causes no harm. However, it requires an IPL or dynamic ACTIVATE to activate the new configuration before you do any swaps.

EMC Symmetrix Hardware Considerations

  • EMC Symmetrix TimeFinder commands and EMC SnapShot-compatible commands should not be issued to volumes involved in an FDRPAS swap. These commands may fail or they may update the source volume in a way that FDRPAS cannot detect.
  • IBM-compatible PAV: If you are using IBM-compatible Parallel Access Volume (PAV)s in 2105-emulation mode, see the notes on IBM PAV above.
  • If you have job streams that execute EMC utilities or other software that depends on special functions of the EMC Symmetrix system (such as TimeFinder) against volumes in a Symmetrix, and you use FDRPAS to swap those volumes to other hardware that does not support those functions (such as a subsystem from another vendor), you need to update those job streams to eliminate or replace that software.
  • See Duplex Copy for SRDF considerations.

EMC Consistency Groups

FDRPAS supports EMC Consistency Groups. When the source volume is an EMC DASD volume, FDRPAS issues a hardware query to see if it is part of a consistency group. If so, it issues the same query against the target device. Unless both devices are EMC DASD volumes in a consistency group, the SWAP fails with message FDR234 REASON=O.

Then FDRPAS invokes an EMC API to determine if both the source and target are in the SAME consistency group. If not, the swap fails with message FDR234 REASON=O.

Therefore, FDRPAS allows a volume in a consistency group to be swapped only to another volume in the same consistency group. This check is made by the FDRPAS SWAP task, so if you are not running the consistency group software on every system, you must run the SWAP task on a system where it is running.

Before the swap, you need to update the group definition to add the FDRPAS offline target device by device address and refresh the group to include it. After the swap, since DASD volumes are usually added to consistency groups by volume serial number or SMS storage group, you may be able to remove the device address since the volume is now on the target device. You should also set the Consistency Group option AUTO_REFRESH=YES so that the group is automatically refreshed after FDRPAS swaps a volume in the group.

If you are swapping an EMC volume to a DASD volume in a non-EMC subsystem or to an EMC subsystem that cannot participate in an appropriate SRDF session, you should disable the consistency group before doing the swap, since consistency is not maintained after the swap.

Because the EMC consistency group software and FDRPAS use some of the same interfaces for monitoring I/O, We do not recommend starting or stopping the EMC software, or disabling or enabling consistency groups, while FDRPAS swaps are running, unless you are certain they do not affect the same devices. Otherwise, FDRPAS swaps may fail and the EMC software may generate error messages; however, no harm is done to your system.

If the EMC consistency group software library is not in the system linklist, you may need to specify that library as a STEPLIB in the FDRPAS SWAP task so that FDRPAS can invoke the proper EMC API module.

Hitachi (HDS) Hardware Considerations

Customers swapping from Hitachi subsystems that emulate IBM 3990-6 control units should note: FDRPAS may not be able to determine all of the systems with access to the source volume. Hitachi supports more connections than a 3990, so in 3990 emulation the subsystem may not be able to report to FDRPAS all of the logical paths to the source volume, and FDRPAS may be unaware of some attached systems. To check execute the FDRPAS SIMSWAP function and verify that all expected attached systems are reported. If not, contact BMC Support for a circumvention. This is not an issue if the Hitachi subsystem is in IBM 2105 emulation.

If FDRPAS source DASD volumes are in a Hitachi subsystem that emulates an IBM 3990-3 control unit, FDRPAS is unable to identify the attached systems, so you must use the #SYSTEMS= operand on the SWAP statement for such volumes. Note that this refers to the 3990-3 control unit, not the 3390-3 DASD volume model; FDRPAS is not sensitive to the model of DASD volume emulated.

Customers using Hitachi ShadowImage (that uses PPRC) should read the notes Duplex Copy.

MIDAW Support

On an IBM Z processor (and any successor processors), the I/O subsystem supports a channel programming construct called a Modified Indirect Addressing Word (MIDAW). MIDAWs allow for more efficient data transfer in some circumstances. To support MIDAWs, the operating system must be z/OS 1.7 (or beyond) or z/OS 1.6 with enabling PTFs.

All IBM DASD subsystems support MIDAWs but some non-IBM subsystems do not. IBM does not allow a swap between a DASD volume that supports MIDAWs and one that does not, or vice versa, so FDRPAS checks that the MIDAW capabilities of the source and target DASD volumes in a swap match. Both must support MIDAWs, or both must not, or the swap fails with an FDR234 REASON=5 error message.

If you are running FDRPAS (SWAP or MONITOR task) on a processor and z/OS that supports MIDAWs, you can query the overall status of MIDAWs with the console command:

D IOS,MIDAW

If MIDAW support is enabled, you can query your FDRPAS source and target DASD volumes to verify that they both support MIDAWs (or not) with the console command:

D M=DEV(uuuu)

If there is a mismatch in the MIDAW support between your source and target DASD volumes, you must disable MIDAW support globally in order to do the swaps. Use the console command:

SETIOS MIDAW=NO

Duplex Copy

If an FDRPAS source volume is the primary volume in a PPRC, z/OS Global Mirror (XRC), SRDF, or Dual Copy session, you may leave the session active during the swap. However, you must be aware that after the swap completes the secondary volume is no longer updated. FDRPAS warns you if the source volume in a swap is also the primary volume of a duplex copy (currently this works only if the source volume is in a PPRC session). If you need the duplex copy after the swap, and the new device is capable, you must re-establish the session.

If you establish a duplex copy of the target device before the swap, then as FDRPAS copies all of the data from the source volume to the target device, all of those writes need to be mirrored to the duplex device. This slows down the FDRPAS copy. The extent of the slowdown depends on a number of factors in the environment and is difficult to forecast. The FDRPAS copy would run faster if you wait to establish the duplex copy of the target device until after the swap is complete; however, there would then be a period of time when a duplex copy was not available. Most installations consider it critical (such as for disaster/recovery) to have a valid duplex copy of the data at all times, and do establish the duplex copy before the swap.

There are no considerations for FDRPAS if the secondary device for any type of duplex copy has a 5-digit device number (unit address), since FDRPAS does not directly interact with the secondary device.

If the source volume is defined to IBM HyperSwap or EMC AutoSWAP, there are special considerations that need to be reviewed. See FDRPAS and IBM GDPS/PPRC HyperSwap, FDRPAS and IBM Basic HyperSwap, and FDRPAS and EMC AutoSWAP for details. For additional information on z/OS Global Mirror (XRC) and FDRPAS, contact BMC Support.

Concurrent Copy (CC)

If FDRPAS detects that a Concurrent Copy (CC) session is active and doing I/O on a source volume at the end of a swap, it delays completing the swap until no Concurrent Copy (CC) I/O has been detected for two minutes. However, this cannot guarantee that the Concurrent Copy (CC) session completes successfully. Because a CC session may involve multiple volumes, it is possible that no CC I/O is done to one of the volumes in the session for many minutes while other volumes are being processed. FDRPAS does not detect the usage of Concurrent Copy (CC) on a source volume unless Concurrent Copy (CC) I/O is detected on that volume.

If a “dormant” Concurrent Copy (CC) session is still active on a source volume when the swap completes, the Concurrent Copy (CC) job fails since the session cannot be transferred to the new device.

Cache Fast Write (CFW)

Cache Fast Write (CFW) is a feature of all cached DASD subsystems that allows data to be held only in cache instead of being written to DASD unless necessary. It is commonly used for sort work areas and may also be used for CICS temporary storage. Although FDRPAS successfully copies the data tracks that were written using Cache Fast Write (CFW), CFW uses a subsystem-wide ID to protect against the lost of CFW data due to the re-initialization of the subsystem. After an FDRPAS swap, the CFW ID of the new subsystem may be different and any application using CFW across the swap may fail. However, new CFW data sets opened after the swap work correctly. CFW is a consideration only for an FDRPAS SWAP, not a SWAPDUMP.

If FDRPAS detects that Cache Fast Write (CFW) is in use on a source volume, it waits until no CFW commands have been issued for two minutes before allowing the swap to complete. In most cases, this avoids CFW problems.

If you prefer, the IDCAMS command SETCACHE can be used to enable and disable CFW for all DASD volumes in a source subsystem before a swap. You may also be able to update global options in your SORT product to disable the use of CFW while you are doing FDRPAS swaps.

In some cases, your SORT product may be able to recover from a Cache Fast Write (CFW) error and complete the sort successfully. Consult your SORT documentation.

MODEL204 from CCA can optionally use Cache Fast Write (CFW) for files on the CCATEMP, CCASERV, and CCASERxx DD statements. MODEL204 can fail if it is using CFW on a volume swapped by FDRPAS. This is controlled by the MODEL204 startup parameter CACHE; the default is X'00' (no CFW) and CCA does not recommend using CFW. However, if you have a value other than X'00' for CACHE and want to swap volumes containing those MODEL204 data sets, consult the MODEL204 documentation for information on disabling the use of CFW.

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

P/390, R/390, FLEX-ES, and IS/390 Internal DASD

You cannot use FDRPAS to swap volumes on a IBM P/390, R/390, or Flex-ES system. These systems run OS/390 in conjunction with an Intel (P/390 and Flex-ES) or RS/6000 (R/390) system and emulate internal S/390 DASD volumes on files of the host operating system. They do not emulate a control unit that can be used by FDRPAS.

An IBM Integrated Server/390 (IS/390) also runs OS/390 in conjunction with an Intel system, but it supports both emulated internal DASD volumes and external ESCON-attached DASD. FDRPAS cannot be used to swap to or from the internal IS/390 DASD volumes, but it can be used to swap between external DASD volumes.

System z High Performance FICON (zHPF)

FDRPAS supports the System z High Performance FICON (zHPF) feature. To determine if zHPF is enabled for your devices, issue the D M=DEV(uuuu) command to see if “ZHPF” is listed on the “FUNCTIONS ENABLED” line. To determine if zHPF is enabled for your channels, issue the “D M=CHP(xx)” command to see if “ZHPF” is listed on the “FACILITIES SUPPORTED” line.

With ALLOWZHPF=NO (the default), at the beginning of a SWAP, FDRPAS temporarily disables zHPF only on the source volume(s) being swapped; FDRPAS turns zHPF back on at the end of the SWAP. Depending on the size of the volume, this usually has little impact on performance during the time that it takes to do a SWAP.

With ALLOWZHPF=YES, FDRPAS allows zHPF Transport Control Word (TCW) commands and does not disable zHPF for the SWAP process.

When swapping from a device that does not support zHPF to a device that does support it, zHPF is enabled on the target device after the SWAP. When swapping from a device that supports zHPF to a device that does not support it, zHPF is disabled on the target device after the SWAP.

FDRPASVM supports zHPF. If zHPF is active on a z/VM system, it remains active at all times during a SWAP. zHPF for z/VM volumes has been in FDRPAS since Version 54L83.

IBM has announced a new hardware feature called zHyperLink for the new z14. zHyperLink provides faster speeds for certain types of DASD I/O. It is supported on z/OS 2.1 and above. FDRPAS cannot support zHyperLink until IBM supplies more information and INNOVATION is able to test with it.

Before you run a SWAP or SWAPDUMP on a source volume for which zHyperLink is enabled, you must disable zHyperLink, with the command:

SETIOS ZHYPERLINK,OPER=NONE

When all of the SWAPs or SWAPDUMPs have completed, you can re-enable zHyperLink with the command:

SETIOS ZHYPERLINK,OPER=READ

or

SETIOS ZHYPERLINK,OPER=ALL

Consult IBM documentation for details when available.

FDRPAS 05.04.87 and 05.04.89 check for zHyperLink being enabled on the source volume, and gives an error message and fails the SWAP(DUMP). You can then disable zHyperLink as above and resubmit the FDRPAS job. Earlier releases of FDRPAS will not make this check, and it is a customer responsibility not to have zHyperLink enabled on the source volume of a SWAP(DUMP). Otherwise, results are unpredictable.

There are no restrictions on SWAP or SWAPDUMP from a source volume that does not have zHyperLink enabled, to a target volume that does have zHyperLink enabled. FDRPAS itself does not use zHyperLink. After the SWAP, applications can start to use zHyperLink on the target volume.

FlashCopy, EMCSNAP, ShadowImage, PPRC

FDRPAS target volumes (SWAPUNIT=uuuu) cannot be used by any replication technique (for example, FlashCopy, EMCSNAP, HDS ShadowImage, PPRC). Additionally, you should not have a FlashCopy pool pointing to volumes that will be swapped into.

3390-54 to EAV Consideration

A volume with more than 65,520 cylinders is called an Extended Address Volume (EAV). On an EAV, cylinders below 65,520 are called track-managed space, and are allocated by tracks and cylinders in the traditional way, while cylinders 65,520 and above are called cylinder-managed space, and are allocated in multiples of 21 cylinders. Cylinder-managed space is intended for large data sets. A customer migrating from 3390-54, which has 65,520 cylinders, to EAV, might want to redistribute the data sets on a volume so that the data sets that are eligible for cylinder-managed space get placed there, leaving much of the track-managed space available for allocation of new data sets that are small or otherwise unsuitable for cylinder-managed space. FDRPAS will not do this. With FDRPAS, the target volume after a SWAP is an exact image of the source volume, except that if the target volume is larger, then all of the added space is available as unallocated space. If you SWAP a 3390-54 that is nearly full to an EAV, then the track-managed space on the EAV will be nearly full, and the cylinder-managed space starts off empty. If this is a concern, then consider using FDRMOVE instead of FDRPAS for the migration. FDRMOVE, with the EATTR=OPT option, allocates eligible data sets in cylinder-managed space, leaving the areas that they previously occupied available for allocation of new data sets. See Extended Address Volumes (EAVs) and EATTR=OPT Considerations for additional information.

Support for Alternate Subchannels (5-digit device numbers)

FDRPAS enables you to do a SWAP or SWAPDUMP to devices in an alternate subchannel set, that is, devices with 5-digit device numbers. For details, see section to an alternate subchannel set (5-digit device numbers).

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*