The Makers of FDR®

February 14, 2006

FDRPAS Announcements

Recommended maintenance to be applied before running FDRPAS
Last updated: February 14, 2006


Critical Omegamon APAR OA11384 added
Critical IBM APAR OA14248 added
Recommended IBM APAR OA14861 added
IBM APAR OA13330 deleted, replaced with FDRPAS warning


Mandatory FDRPAS zap for MIDAW added – all z9 customers must read!
2107 (DS8000) problem updated
Critical SRM APAR OA13330 and Omegamon APAR OA13206 added
Recommended O/C/E APAR OA13458 added


Version 5.4 level 40 of FDRPAS and higher are supported. You should not run earlier releases of FDRPAS. The current release, as of February 14, 2006, is V5.4 level 51.


(this replaces an earlier entry about APAR OA13330)

If you use the console ACTIVATE command to activate a new I/O configuration which deletes disks which were FDRPAS source disks, you may experience S0C4 or S073 abends in IBM module IOSVCNT. The change to avoid this problem is in FDRPAS V5.4 level 55. Zap P-54.5033 is also available for V5.4 level 50 and 51 (the zap is included in level 51 distributions after February 14, 2006)
If you can’t install a current level of FDRPAS or apply the zap, then you must not delete FDRPAS source disks with ACTIVATE. You can activate the new I/O configuration with an IPL.


Because of a change in the IBM 2107 (DS8000) compared to the 2105 which IBM did not document, FDRPAS V5.4 level 43 and below may not properly identify the systems attached to a 2107 source disk.

If you are swapping to or from an IBM 2107, you should install FDRPAS V5.4 level 50 or above. This level contains the change to properly identify attached systems on a 2107.

If you wish to use a 2107 with a level of FDRPAS below V5.4/50, you should use the SWAP operand USE#SYSTEMS=nn to specify the number attached systems for a 2107 source disk (be sure you specify it properly). USE#SYSTEMS= should be used only to circumvent this problem; do not use it for other disk subsystems.


The new IBM z9-109 system supports MIDAWs (Modified Indirect Data Address Words) in I/O channel programs. MIDAWs are used only on the z9-109 and only if you have installed z/OS 1.6 with enabling PTFs or z/OS 1.7.

Because MIDAWs may not be properly supported on non-IBM disk equipment, IBM requested that we add a check to FDRPAS so that we will not attempt to swap between a disk which supports MIDAWs and one that does not.

FDRPAS V5.4 level 50 contains this change, and is recommended for z9-109 systems. You may also use V5.4 level 42 or 43, but ONLY if you apply zap P-54.4386; this zap is MANDATORY on those levels on a z9-109 system. You must not use FDRPAS levels less than 42 on z9-109 systems.

If you must swap between disks which support MIDAWs (which includes all IBM disks) and those that do not (which includes most non-IBM disks), then you must disable MIDAW usage globally with the command:

SETIOS MIDAW=NO (or YES to re-enable)

You must not issue this command while FDRPAS swaps are running, and you must wait a few minutes for MIDAW usage to quiesce.


ECS (Enhanced Catalog Sharing) is a catalog sharing protocol for parallel sysplexes which uses the Coupling Facility to communicate catalog changes to all systems. You can determine which of your open catalogs are using ECS with the console command:


if any catalog displayed has a status of "active", ECS is in use. This display also shows if the ECS AUTOADD option is enabled; AUTOADD is required to make the commands below function correctly. If not enabled, issue


The ECS CF structure is sensitive to the device address of each ECS shared catalog, so the Catalog Address Space (CAS) is supposed to automatically disable ECS sharing for all catalogs on a volume which is swapped with FDRPAS. However, despite several earlier APARs on this issue, IBM has discovered a problem where this is not occurring, which can result in back-level catalog contents or catalog corruption. IBM APAR OA10139 resolves this problem but fixes are only available for z/OS 1.3 and above.

If you cannot apply the appropriate PTF or no PTF is available for your operating system level, you MUST disable ECS for all catalogs on volumes being swapped, before the swap, using the console command:


After the swap, you can re-enable ECS for those catalogs with


These commands need to be issued only on one system; they will automatically be propagated to all other sharing systems. Even if you have APAR OA10139 applied so that CAS automatically removes a swapped catalog, you will need to use the ENABLE command to re-enable ECS for those catalogs after the swap.

Alternately, you can disable ECS globally for all catalogs, before the swaps, using the console command:


And re-enable ECS after the swaps with:


The DISCONNECT and CONNECT commands need to be issued only on one system.


You may need to apply IBM maintenance in order to successfully swap disks with FDRPAS. Please check this matrix against your operating system level to see which IBM APARs may need to be applied to all of your systems before you attempt to use FDRPAS.

Brief descriptions of the APARs follow the matrix. Please review the descriptions of the applicable APARs to see if they must be applied to your system. IBM can provide detailed APAR descriptions and assist you in determining if a given APAR must be applied. Please note that failure to apply some of these APARs may result in system failures, application failures, or data corruption.

APARs that apply to OS/390 2.4-2.9 can be found in the May 2003 FDRPAS newsletter at

APARs that apply to OS/390 2.10 and z/OS 1.1-1.3 can be found in the October 2005 FDRPAS newsletter at

IBM |------------------------z/OS------------------------|
APAR | 1.4 1.5 1.6 1.7 |
PQ92344 | R R R R |
OA14861* | R R R R |
OA14248* | C C C C |
OA13458 |   R R R |
OA13206* | C C C C |
OA11384* | C C C C |
OA10139* | C C C   |
OA09675* | C C C C |
OA07355* | R R R   |
OA07006* | R R     |
OA06935 | R R     |
OA05722* | R R     |
OA05403* | R R     |
OW57711* | R       |
OW57552* | C       |
OW56156* | R       |
OW55469* | C       |
OW54976* | C       |
OW54200* | C       |
OW53761* | R       |

Note:   OA06935 is for JES3 systems only

C = Critical - will apply to most installations and may result in system outages or data loss if not applied. All FDRPAS users should apply.

R = Recommended - does not result in outage or data loss OR applies only to a limited number of installations with special circumstances. All FDRPAS users should review the descriptions and apply if they are critical for your environment.

* = an IPL is required to implement this fix.

Brief IBM APAR descriptions follow:

PQ92344: this recommended APAR adds function to ICKDSF 1.7 to optionally bypass some ENQs when doing a BUILDIX. FDRPAS invokes BUILDIX when swapping to a larger disk. When zap P-54.4373 is applied to FDRPAS V5.4/43, these ENQs will be bypassed, which improves performance and may avoid some ENQ interlocks (the zap is included in FDRPAS V5.4/50).

OA14861: this recommended APAR fixes incorrect RMF device statistics after swapping a volume from ESCON to FICON channels.

OA14248: this critical APAR should be applied if you are swapping volumes contain PLPA or COMMON paging data sets and you have PAV aliases assigned to the source disks. It fixes a problem where the paging I/O may get “lost” if it was active on an alias when FDRPAS starts to swap the volume. This will result in various types of hangs and usually requires a reIPL to resolve. You can circumvent the problem if you can disable PAV on the PLPA/COMMON volume before the swap.

OA13458: this recommended APAR fixes a S130 ABEND in a DEQ from CLOSE after swapping a volume from a device marked as SHARED to one marked as non-SHARED. This occurs only if you have EDI (Enhanced Dataset Integrity) enabled to prevent multiple updates to sequential (PS) data sets. FDRPAS will not allow you to swap to a non-shared target disk unless only one system is involved in the swap, so most customers will not be exposed to this error.

OA13206: this critical APAR is for Omegamon V5.2 and fixes a S0C1 abend when FDRPAS swaps are run. Omegamon was originally from Candle but is now from Tivoli (IBM). V5.2 is an older release; newer releases of Omegamon have the fix integrated.

OA11384: this critical APAR is for Omegamon V5.4 and fixes a possible SPIN LOOP when FDRPAS swaps are run. The Spin Loop may require an IPL to resolve. Omegamon was originally from Candle but is now from Tivoli (IBM).

OA10139: this critical APAR should be applied if you are swapping volumes containing catalogs shared with ECS (Enhanced Catalog Sharing via a coupling facility). This problem can result in lost catalog entries and other catalog corruption. If you cannot apply the fix, or there is no fix for your operating system level, see the notes above on disabling ECS during the swap.

OA09675: see OA14248. Note that PTFs may not be available for all z/OS levels.

OA07355: this recommended APAR must be applied if you are going to swap volumes to or from a StorageTek V2Xf disk subsystem. It fixes a problem in the Media Manager component which results in invalid CCW chains when the V2Xf is involved as a source or target disk in a FDRPAS swap.

OA07006: this recommended APAR fixes a S878 abend during IPL if a large number of IEA311 UNLABELED DASD messages are issued. This can occur if many FDRPAS source volumes are still connected and have not been relabeled.

OA06935: this recommended JES3 APAR addresses a problem where a swapped volume appears to return to its original device after a local system is started.

OA05722: this recommended APAR fixes an error in module IECDINIT which may cause a swap to terminate if a Flashcopy from a FDRPAS source device is initiated during a swap. It only affects customers who have the FlashCopy V2 (data set flash) support installed on their disk and on their operating system.
FlashCopy V1 customers do not need to install this fix.

OA05403: this recommended APAR suppresses a SVC dump which may occur when volumes with PAV aliases are swapped. The dump title will refer to IOS-DEVICE STATE TRANSITION FLUSHING and the symptoms in the dump will include abend SCOD reason 00000001. According to the APAR, this condition is automatically recovered and the dump is meaningless. Apply the PTF to suppress the dump, or just discard the dumps. The swap will be successful.

OW57711: this recommended APAR fixes a S0C4 in module IECDINIT during a swap. The abend causes no harm and the swap will complete successfully, but a SVC dump will be created. The problem seems to occur when the target device has never been online to the system since the last IPL.

OW57552: this critical APAR fixes a problem in DASD error recovery (ERP) which can result in I/O errors in some applications which are using a disk while FDRPAS is copying it. This may result in application or system failures depending on the component issuing the I/O. The error may be accompanied by a SVC dump with a title indicating S0C4 in DASD ERP (IECVDERP). This problem only occurs when running FDRPAS V5.4 level 4x; earlier levels of FDRPAS are not affected. If the PTF for this problem cannot be applied, contact Innovation for custom zap C-54.0925 to circumvent the problem.

OW56156: this recommended APAR fixes a problem in XCF where the device address of a couple dataset is incorrectly displayed after a swap of the disk.

OW55469: this critical APAR fixes Media Manager to avoid hangs and ABENDs in programs which use Media Manager. Without this fix, you may experience DB2 failures during a swap. It has also been implicated in a hang in CA-OPSMVS (from Computer Associates) during a swap.

OW54976: this critical APAR should be applied to avoid SQA overlays due to a problem in the IBM service IEEVARYD. You can avoid the problem without applying the fix by adding the undocumented operand "VARYON=NOAFTER" to all SWAP and MONITOR statements on every system; however, this leads to a rare case where concurrent copy and FlashCopy do not work after the swap; if this occurs, issue the console command


OW54200: this critical APAR has been implicated in data corruption during FDRPAS swaps. The APAR mentions IEBCOPY but we have seen data corruption in DB2 databases. Other data set types may be exposed as well.

OW53761: this recommended APAR addresses problems when swapping from a device with new features (such as Flashcopy on a 2105 Shark) to another subsystem without those features. FDRPAS disables those features at the beginning of the swap, but without this fix they may be dynamically re-enabled before the swap ends.


Customers swapping to a HDS 9xxx Lightning disk subsystem must insure that the microcode level is 01-13-19/00 or higher. Without this microcode, FDRPAS monitor tasks may not recognize that a swap is starting.


If you are swapping to or from a volume in a StorageTek V2Xf (FICON-attached) subsystem, you must be at microcode level G01.01.14.00 or above.


If a source volume is in an IBM 2105 ESS (Shark) with FICON channels, you should be at microcode level 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.