09/22/2003

All DB2 for z/OS V6 or V7 data sharing users.

Potential data corruption when using the GBPCACHE NO option for group buffer pools (GBPs)

Data corruption may occur when all of the following conditions are true:

• a GBP is defined with GBPCACHE NO, and
• that GBP is dynamically rebuilt into a coupling facility at CFLEVEL 7 or above, and
• a DB2 member makes a new connection to that GBP after the rebuild has completed (e.g. by stopping/restarting one of the members, or introducing a new member into the group).

The problem is fixed by APAR PQ78457. No PTFs are available at this time. The problem can be circumvented by discontinuing the use of GBPCACHE NO. Alternatively, contact IBM support for an aparfix for PQ78457. Note that this problem is not related to the use of the GBPCACHE NONE attribute for table spaces and indexes. The problem only pertains to use of the GBPCACHE NO attribute at the GBP level.

07/29/2003

All JES2 Users on z/OS 1.2 through z/OS 1.4

APAR OA03779 corrects the following problem at z/OS 1.2 through z/OS 1.4:

If a JES2 $ACTIVATE command (any form) is issued, and if a $T command is issued on any other member of the JES2 MAS where JES2 has not yet been restarted since the $ACTIVATE, then critical areas of the JES2 checkpoint will be corrupted. The $T command must be one that changes the size of the JES2 checkpoint, such as $T JOBDEF JOBNUM=, $T SPOOLDEF SPOOLNUM=, etc. for the problem to occur, but there are several forms of the command that apply (see OA03779). Various JES2 abends will occur on all members, and JES2 will not be able to start on any member. Only a JES2 cold start will allow JES2 to restart, all data on spool will be lost. A JES2 cold start requires that all members be IPL'd ( a rolling IPL can be done). The PTF must be installed on all members for the problem to be completely corrected, but the PTF can be installed on one member at a time. Until the PTFs can be installed, ensure that JES2 is restarted (at least a hotstart) on all members immediately after any $ACTIVATE command is issued. JES2 restart will force that member to pick up the changes made by $ACTIVATE, and prevent any subsequent $T commands from causing corruption. If it is unknown when $ACTIVATE was last issued, restart JES2 on all members immediately to eliminate the risk of the problem, or avoid the $Tcommands listed in OA03779 until the fix is available.

07/11/2003

All DB2 for z/OS V6 & V7 users

Full or incremental imagecopy of DB2 LOB tablespaces using the IBM DB2 COPY utility may result in data corruption, storage overlays or loss of recoverability. The full imagecopy problem is corrected by APAR PQ75396 - PTFs UQ77969 for V6 and UQ77970 for V7. The incremental imagecopy problem is corrected by APAR PQ75532. No PTFs are available for PQ75532 at this time. Contact IBM support for an aparfix if you cannot avoid taking incremental imagecopies of LOB data prior to applying the eventual PTF for PQ75532.

05/27/2003

All DB2 for z/OS V6 & V7 users

Loss of recoverability due to truncated image copy datasets.

Full image copies may not contain all pages from the pageset. The high used RBA of the pageset being copied may be incorrect causing the copy utility to end prematurely. Recover of the pageset using that copy will result in lost data and possible message DSNU501I with RC4.

This problem is corrected by apar PQ72920. PTFs UQ76531 for V6 and UQ76532 for V7 are available.

03/21/2003

All DB2 for z/OS V6 & V7 users

This alert addresses two problems:

1. Data corruption may occur if LPL recovery is performed in a data sharing environment when one member of the group is down and that member's BSDS is unavailable, eg. due to a BSDS timestamp mismatch. Message DSNJ700I is issued but LPL recovery completes successfully even though no log records are applied. Prevent this by ensuring all members are up before performing LPL recovery or apply the APAR listed below.
2. Data corruption may occur using the DB2 RECOVER utility if pages are stopped during the recovery process. If the RECOVER utility issues message DSNU501I and completes RC4 then not all log records may be applied.

Both problems are fixed by APAR PQ71956. PTFs UQ75112 and UQ75113 are available for V6 and V7, respectively.

03/13/2003

Please note the following migration consideration in a Shared HFS environment.

Any UNIX System Services users migrating to z/OS R4 and running in a mixed-level shared HFS sysplex should pay careful attention to HIPER APARs OW55411 and OW57120. The problems described in these APARs can potentially lead to a sysplex-wide IPL in order to recover. In order to avoid any of these problems, customers can do one or both of the following:

1. Ensure that at least one pre-z/OS R4 system in the shared HFS sysplex has the PTF for APAR OW55411 applied before issuing the "SETXCF COUPLE,TYPE=BPXMCDS,PSWITCH" system command to change the OMVS CDS (Couple Data Set) to a Version 2 CDS. This should be done before any z/OS R4 system enters the shared HFS sysplex.
2. Ensure that any z/OS R4 systems have PTF UW95859 for APAR OW57120 applied before entering a shared HFS sysplex.

10/23/2002

Records or pages may be missing in output printed by an FSS application, including PSF and IP Printway. The problem only applies to z/OS 1.4 JES2 HJE7707 and occurs when the application issues a GETREC for specific records, which can occur after an event that requires repositioning, such as a paper jam, operator command, or data error. Please see APAR OW56732 for details. The recommendation is to install the ++APAR YW56732 until the PTF is available. YW56732 can be ordered from IBMLINK.

05/02/2002 Updated 12/13/2002

There are several Unix System Services APARs related to shared HFS ability to recover from a system being removed from the sysplex. The USS Shared HFS F BPXOINIT, SHUTDOWN=FILESYS command may result in incorrect recovery actions that may lead to the need to IPL one or more systems in the SYSPLEX to recover USS functionality across the sysplex. Please ensure that the fixes for the following APARs are applied: OW51619, OW52361, OW53169, OW53171, OW52794. Until fixes for APARs OW52923 OW53957 and OW54494 are available and can be applied, the recommended circumvention is to manually move AUTOMOVE=YES filesystems owned by the system to be brought down prior to issuing F BPXOINIT, SHUTDOWN=FILESYS. This can be done using the SETOMVS command as follows: SETOMVS FILESYS,FROMSYS=sysa,SYSNAME=sysb (where sysa and sysb are actual system names) Once the SETOMVS command completes then F BPXOINIT,SHUTDOWN=FILESYS should be used to unmount the remaining AUTOMOVE=NO filesystems prior to removing the system from the SYSPLEX.

05/02/2002

Sysplex-wide abends and eventual IPLs due to corruption of an ATS control block when an unexpected XCF Message is sent out by one ATS system in a sysplex to share tape information with all other ATS systems in the sysplex. This problem can only occur if APAR OW50900 is installed on z/OS 1.2 or z/OS 1.3 systems and a tape device is defined as Autoswitchable. Please see APAR OW54192 for details. The recommendation is to install the ++APAR listed in the APAR.

03/14/2002

02/05/2002 GRS Enqueue processing hung due to a latch deadlock caused by ISGAUDIT (GRSMON). This applies to customers using ISGAUDIT on OS/390 2.8 through z/OS 1.3. Please see APAR OW51872 for details.

[Updated 03/14/2002] The recommendation is to install PTFs UW86149 for OS/390 2.8, UW86150 for 2.10, UW86151 for z/OS 1.2 , and UW86152 for z/OS 1.3.

03/11/2002

Sysplex-wide hang due to unprocessed ENQ/DEQ/RESERVE requests following a Coupling Facility structure rebuild of ISGLOCK, the GRS Star structure. Please see APAR OW51115 for details. The recommendation is to install PTFs UW82677, UW82678, and UW82679 on OS/390 R2.8, OS/390 R2.10 and z/OS R1.2, respectively.

02/05/2002

GRS Enqueue processing hung due to a latch deadlock caused by ISGAUDIT (GRSMON). This applies to customers using ISGAUDIT on OS/390 2.8 through z/OS 1.3. Please see APAR OW51872 for details. The recommendation is to turn off ISGAUDIT (GRSMON) until the PTFs are available, which will be available shortly. Please see Red Alert Update dated 03/14/2002.

02/05/2002

All users of OS/390 2.10 and z/OS 1.1 should ensure that the fix for OW48782 is installed. This problem may result in SRM not swapping address spaces correctly after the system has been IPLed for 51 days or more. Please see the APAR for details. PTFs UW79766 for OS/390 2.10 and UW79767 for z/OS 1.1 are available.

10/24/2001 [Updated 11/07/2001]

Potential for DB corruption and message queue damage after IMS emergency restart:
PTF UQ52990 (APAR PQ42127) causes IMS to ignore log data in the Write Ahead Data Set (WADS) when closing the log during emergency restart. Problem only affects version 7 IMS when not running in z/Architecture mode, does not affect normal restart, and will not occur if the following message is received during termination - DFS616I OLDS BUFFERS SUCCESSFULLY PURGED.
Otherwise, the effect is truncation of the end of the log data in an amount ranging from nothing up to the number of log buffers equal to the number of track groups in the WADS. In this situation, a dump of the IMS termination immediately preceeding the restart would be the only source of log data and should be saved.

Recommendation [Updated 11/07/2001]:
If IMS is running with UQ52990 or PQ42127 applied, it should be shut down with a checkpoint command and UQ59347 applied.

05/21/2001

ENQ Contention on SYSIEFSD Q10, Lockout of Consoles, Loop in IEEVWAIT in MASTER or CONSOLE address space :
These problems can occur after application of PTF UW78695 or UW77694. The problem causes a loop in the CSCB chain and will require an IPL to resolve. This can occur any time after issuing commands from TSO OPER mode. The recommendation is to apply PTF UW79319 to resolve this problem as soon as possible. Do not issue commands from TSO OPER mode until the PTF is applied. However, other command interfaces, such as, TSO CONSOLE mode, SDSF/LOG/ULOG, or other EMCS console, are OK to use.

04/06/2001

As indicated in the ++HOLD for ACTION provided on the PTFs UW70737 - UW70742 for OW36418, PTFs UW70731 - UW70736 for OW43304 MUST be installed and IPLed on EVERY system in the sysplex before installing and IPLing OW36418 on ANY system in the sysplex. Failure to follow this action can result in an outage to multiple systems in the sysplex. Both sets of PTFs are on RSU 0006.

11/01/2000

A REBUILD of a Coupling Facility structure can fail with a ILXCONN RCC RSN02010C08 after migration to OS/390 R8 with CF level 8 or CF level 9. IEFAUTOS structure may receive MSGIEF250I. Please see APAR OW43778 for details. The recommendation is to increase the CF list and lock structure sizes as follows:

10/06/2000

All users of DB2 for OS/390 v6.1 COPY utility:
Data corruption can occur during image copy of a table space or partition. The DB2 for OS/390 V6.1 COPY utility may overlay data held in a buffer owned by an unrelated table space or index. See APAR PQ41076 for further details. Please install PTF UQ47020.

07/12/2000

Severe performance problems on OS/390 Release 2.8 (and higher) due to the problem described by APAR OW44517. This can result in several symptoms including high LPAR Management time, high uncaptured time (MVS Overhead), high CPU utilization in Catalog, GRS and other system address spaces. SRM may lower MPLs resulting in unilateral swaps due to ASCBTCBs being incorrectly too high. This problem can also occur on OS/390 Release 5, 6, and 7 with PTFs UW68782, UW68783 and UW68785 installed, respectively.
Please see OW44517 for details.

07/11/2000

OS/390 Release 2.8 or 2.10 users -
Various JES2 ABENDs, apparent high SPOOL utilization, and other errors when the primary JES2 checkpoint is on a Coupling Facility. The problems occur when a page in the JES2 checkpoint is incorrectly zeroed. Please see APAR OW44166. Recommendation: Install UW70447 for OS/390 V2 R8 or UW70448 for OS/390 V2 R10

2/28/2000
For those planning on installing or migrating the coupling facility to CFLEVEL= 7 or 8, please see APAR PQ35919, if using DB2 6.1 with data sharing and APAR PQ23043/UQ35798 is installed. If you are using DB2 6.1 with data sharing and APAR PQ23043/UQ35798, then you must ensure that the correct CFCC service levels are applied for CFLEVEL=7 or 8. For CFLEVEL=7, you need to ensure that CFCC service level 1.06 or above is applied. For CFLEVEL=8, you need to ensure that CFCC service level 1.03 or above is applied. If DB2 6.1 data sharing and APAR PQ23043/UQ35798 runs with group buffer pools allocated in a CFLEVEL=7 coupling facility with a service level prior to 1.06, or CFLEVEL=8 with a service level prior to 1.03, then severe DB2 data integrity problems can be encountered. APAR PQ35919 contains ++HOLD data with further instructions.

++ASSIGNs for YR2000 (SOURCEID=YR2000 ) cannot be used by themselves to ensure that all YR2000 service has been applied.

++ASSIGN statements are not intended for identifying missing PTFs that fix Year 2000 APARs. ++ASSIGNs for YR2000 do make it easier to install as a group all the Year 2000 fixes you have already SMP/E RECEIVEd. You should use Enhanced HOLDDATA and SMP/E's REPORT ERRSYSMODS command, or the information available from the Year 2000 website or PSP bucket, to identify which Year 2000 PTFs are missing on your system.

All PTFs which contain new fixes for YR2000 related problems have an associated ++ASSIGN statement. PTFs that supersede these PTFs will only have an associated ++ASSIGN statement if they too contain new fixes for YR2000 related problems. The ASSIGN statements create an SMP/E SOURCEID (YR2000) for the PTFs which have been SMP/E RECEIVEd. The SOURCEID enables the PTFs to be processed as a group (such as on an APPLY command). If for any reason the PTF associated with a ++ASSIGN is not in RECEIVE status, the ++ASSIGN does nothing and no messages to that effect are issued. As an example, an ESO with supersede screenout will not deliver a YR2000 PTF if that PTF has been superseded.

++ASSIGNs for YR2000 can be used to install all SMP/E RECEIVEd YR2000 service as a group, but cannot be used to identify missing service for YR2000.

Users Affected: D/T2105 and FICON and OS/390 R1.3 and higher
ESQA storage exhausted by build up of IOS MGFQ elements due to excessive unsolicited interrupts from a broken device. Please see APAR OW40807 for details. The unsolicited interrupts and resultant ABEND878 RC4 or RC8 can occur on all systems connected to the device. The unsolicited interrupts have been occuring on a non-IBM tape device. The problem only occurs with APARs OW34071 (FICON support) and OW37980 (ESS d/t2105 Shark support) installed.

PTFs for OW40807 (UW64775 through UW64779) will be generally available shortly or contact the IBM Support Center for a copy of the fix.

MVS OS/390 Overlay of storage after applying PE PTFs UW56054 UW56053 UW56613 UW56612 UW56615 UW56052 UW56055 UW56614.
If these PTFs are on and a tape job is cancelled then an overlay will occur. The external symptoms could be repetitive ABEND0C4s, master console hang, problem with catalogs. Please see APAR OW38170 for details on other symptoms and APAR fix information.

For those planning on installing or migrating the Coupling Facility to CFLEVEL= 5 or 6, please see APAR PQ25114, if using DB2 5.1 or 6.1 with Group Buffer Pools in the CF and APAR PQ17797/UQ22951 is installed. (PQ17797 was included in the base of DB2 6.1). If you do not plan to shut down the DB2 group during the CF installation, it is recommended that you wait for the fix for PQ25114. PQ25114 fixes the following problems:

• DB2 member can hang shortly after rebuilding a GBP from CFLEVEL<5 to CFLEVEL>=5. The hang can also occur if running with the GBPs of a single DB2 group allocated in a mix of CFLEVEL<5 and CFLEVEL>=5.
• DB2 member can abend shortly after rebuilding a GBP in the opposite direction, from CFLEVEL>=5 to CFLEVEL<5. The abend could also occur if you are running with the GBPs of a single DB2 group allocated in a mix of CFLEVEL<5 and CFLEVEL>=5.

MVS OS/390 ENQ contention on resource SYSZMCS can occur after the applications of the PTFs for APAR OW32319. APAR OW34818 describes the problem. The external symptoms show that the *MASTER* address space holds the resource, and other address spaces across the SYSPLEX are waiting for it. The problem may lead to an IPL of the system holding the resource in order to resolve the ENQ contention. Install the PTFs for OW34818 as soon as possible.

DFSMShsm: DASD data sets with special expiration dates expired.
Installations which use special expiration dates (such as 99000) for tape management processing and use the TMM methodology to reroute tape data sets to DASD, but fail to clear these expiration dates will have the data sets expired by DFSMShsm if SETSYS EXPIREDDATASETS(SCRATCH) is specified. See HSM apar OW37011 and FLASH W98048 for more details.