Incorrect START_RBA and PIT_RBA in SYSIBM.SYSCOPY after Running Fast Load and Rapid Reorg on Db2 12 at Function Level V12R1M100

Products

• Fast Load for DB2 for z/OS
• Rapid Reorg for DB2 for z/OS

Issue/Introduction

CA Fast Load (PFL) and CA Rapid Reorg (PRR) insert a row into SYSIBM.SYSCOPY with ICTYPE S or Y (PFL) and W (PRR) at the end of their processing. These rows are used by a recovery utility to identify data that is not recoverable.

In case of Db2 12 subsystems running at V12R1M100 (Function Level 100), PFL and PRR inserts incorrect START_RBA and PIT_RBA values into the row. This does not happen when running under any other Function Level.

Incorrect START_RBA and PIT_RBA values mean that a recover utility is not aware of the activity that made the object not recoverable. When IBM Recover is run over the activity, it should end with RC=8 and the following message (for partition image copy):

DSNU516I  !ssid nnn time DSNUCASA -NO BACKUP WAS TAKEN AFTER LOAD, REORG OR CHECK DATA LOG(NO) OF TABLESPACE dbname.tsname DSNUM n

But with the missing row in SYSIBM.SYSCOPY, the recover utility will complete without any error.

This can only happen if no image copy was taken after PFL or PRR. Please note that CA Quick Copy (PQC) problem 867 which describes a similar problem in that product means that a copy generated within PFL or PRR using the QUICKCOPY keyword will suffer from similar issues and will not resolve the recoverability issues. PQC HIPER PTFs have been released to address this issue (SO09507 for R19, SO09595 for R20).

The following query will identify erroneous RBA values in Db2 catalog table SYSIBM.SYSCOPY

------------------------------------------------------------

SELECT * FROM SYSIBM.SYSCOPY

WHERE

(ICTYPE='S' OR ICTYPE='Y' OR ICTYPE='W')

AND

(

HEX(START_RBA) LIKE '%40404040'

OR HEX(PIT_RBA)=X'00000000000040404040'

);

------------------------------------------------------------

Environment

Db2 for z/OS V12R1M100 only with any of the following releases of CA DBM Solutions for DB2 for z/OS Utilities Common:

Release 19.0

Release 20.0

Component:

CA DBM Solutions for DB2 for z/OS Utilities Common

Cause

The cause of the problem is an error in the code of a common module used by PFL and PRR that writes rows into SYSIBM.SYSCOPY. This code incorrectly identifies Db2 12 Function Level 100 as a subsystem using 6 byte RBAs.

Resolution

The following HIPER PTFs have been created to resolve the issue.

CA DBM Solutions for DB2 for z/OS Utilities Common in Release 19 – SO09570

CA DBM Solutions for DB2 for z/OS Utilities Common in Release 20 – SO09569

The HIPER PTFs will ensure that PFL and PRR creates correctly formed START_RBA and PIT_RBA values for all future rows inserted into SYSIBM.SYSCOPY.

If any objects are found which contain invalid entries for SYSIBM.SYSCOPY inserted by PFL or PRR identified using the query above, we recommend that a Full Image Copy is taken immediately using either IBM Copy Utility or CA Quick Copy (making sure that HIPER PTFs SO09507 (R19) or SO09595 (R20) are applied). After ensuring correct object recoverability and to mitigate the effect from any entries in SYSIBM.SYSCOPY which contain the erroneous START_RBA and PIT_RBA settings, please contact Broadcom Support.

Additional Information

Before the PFL/PRR and PQC PTFs are applied, please follow this procedure when running PFL or PRR on a Db2 subsystem running on Function Level 100:

• Omit the QUICKCOPY keyword to avoid wrong SYSCOPY records inserted by PQC.
• Do not use STARTUP-ACCESS FORCE which would override setting the COPY PENDING state.
• Specify SET-COPYPENDING YES to set the COPY PENDING flag on the loaded or reorganized object to prevent any updates before an image copy is taken.
• Specify UPDATE-SYSCOPY NO to prevent PFL or PRR to insert the SYSCOPY rows with the wrong values.
• Use IBM COPY after PFL to create a full image copy of the loaded object.

A KB Article id of the PQC related issue: 135876