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

Fast Load (PFL) and 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 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 (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 DBM Solutions for DB2 for z/OS Utilities Common:

Release 20.0

 

Component:

DBM Solutions for DB2 for z/OS Utilities Common

Cause

The cause of the problem is an error in the code of 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 bytes RBAs.

 

Resolution

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

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 PFR or PRR identified using the query above, we recommend that a Full Image Copy is taken immediately using IBM Copy Utility or Quick Copy(Make sure that HIPER PTF S009595(R20) is 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