CA Recover for DB2 for Z/OS: Recover Data from a non current image copy stored on a GDG that is a few generations old produced on another subsystem.

book

Article ID: 196506

calendar_today

Updated On:

Products

CA Fast Recover for DB2 for z/OS

Issue/Introduction

Image copies are internal DB2 format backup datasets produced by a utility like CA Quick Copy or IBM Copy. This Image Copy Dataset can only be used by another Utility like a Recovery or Unload Utility.
A z/os GDG is a Generation Data Group which is a dataset storage structure which is often used for the storage of image copies. Generation data groups automate the allocation of data set names and the deletion of the oldest data set. Multiple prior versions or generations of the dataset can be stored without any name change in the JCL. The Data stored in an Image Copy Dataset can be used to populate another target database and this is often done to obtain production data for testing purposes without hindering the operations of the online production database.

Environment

DB2 for Z/OS 

Resolution

CA Fast Recover(PFR) is able to recover data from an Image Copy stored on a GDG made on another environment as long as some particular settings are used and the original tablespace being recovered is exactly the same.

First, start with the standard JCL used by CA Fast Recover to recover a tablespace. 

Identify the input Dataset

Consider this GDG structure of the source image copy:

hlq.CPY   <------------------this is the GDG base. 
hlq.CPY.G0001V00
hlq.CPY.G0002V00
hlq.CPY.G0003V00  <--------------------- the sample JCL will obtain the dataset 2 generations old
hlq.CPY.G0004V00
hlq.CPY.G0005V00

This is the GDG structure of the GDG that will be used for the INLINE image copy to be taken during the recovery:

hlq.CPY2   <------------------this is the GDG base for the Inline image copy.
hlq.CPY2.G0001V00
hlq.CPY2.G0002V00
hlq.CPY2.G0003V00 


In the CA Fast Recover JCL make a specific reference to the full image copy dataset available like this with the FULLDD DD parm in the SYSIN cards:

FULLDD FULLDS2

https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-mainframe-software/database-management/ca-fast-recover-for-db2-for-z-os/20-0/reference/keyword-descriptions/fulldd-define-the-full-image-copy-data-set.html

Refers to the DD card that points to the GDG. This one is referring to a GDG two generations old so the job would obtain hlq.CPY.G0003V00. 

//FULLDS2  DD   DSN=hlq.CPY(-2),
// DISP=(OLD,KEEP)

The image copy being used must be of a tablespace of the same format and structure of the target right down to the RBA format or errors will be reported by PFR.

Also, include the OBIDXLAT parm so that if the object OBID's on the source image copy is not the same as the target imagecopy so that a OBID matching process can happen between the two different OBID's.

https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-mainframe-software/database-management/ca-fast-recover-for-db2-for-z-os/20-0/reference/keyword-descriptions/obidxlat-define-obids-for-recreated-tables.html

As part of the recovery, a new inline image copy can be taken when the recovery is complete by calling CA Quick Copy :

QUICKCOPY COPY01(Y,SYSCP101,,LP)

The above parm refers to DD card SYSCP101 which is the target new image copy location.

https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-mainframe-software/database-management/ca-fast-recover-for-db2-for-z-os/20-0/reference/keyword-descriptions/quickcopy-invoke-ca-quick-copy.html

In the sample below the target image copy is being created on yet another different GDG. This will leave the recovered tablespace in RW status ready to be used. 

//SYSCP101  DD   DSN=.CPY2(+1),
//            DCB=(BLKSIZE=32760),
// DISP=(NEW,CATLG,),SPACE=(CYL,(254,5)),UNIT=SYSDA,STORCLAS=TSO

Sample JCL that will obtain the data from the GDG 2 generations old using a relative reference, relative to the most current copy it obtains a copy that is 2 generations old(-2). An inline image copy is also produced after the recovery and stored on a different GDG. 

//UTIL0001 EXEC PGM=PTLDRIVM,
//             PARM='EP=UTLGLCTL/ssid,RESTART(BYPASS)',
//             REGION=0M
//*
//STEPLIB   DD   DISP=SHR,DSN=hlq.CDBALOAD
//          DD   DISP=SHR,DSN=DB2.SDSNLOAD
//PTIPARM   DD   DISP=SHR,DSN=hlq.CDBAPARM
//*
//PTIMSG    DD   SYSOUT=*
//PTIIMSG   DD   SYSOUT=*
//*
//SYSOUT    DD   SYSOUT=*
//SYSUDUMP  DD   SYSOUT=*
//ABNLIGNR  DD   DUMMY                 SUPPRESS ABENDAID DUMPS
//ST01MSG   DD   SYSOUT=*
//FULLDS2  DD   DSN=hlq.CPY(-2),             < -----Source image copy
// DISP=(OLD,KEEP)
//SYSCP101  DD   DSN=.CPY2(+1),             <-------New image copy
//            DCB=(BLKSIZE=32760),
// DISP=(NEW,CATLG,),SPACE=(CYL,(254,5)),UNIT=SYSDA,STORCLAS=TSO
//SYSIN   DD  *
RECOVER TABLESPACE database.tblspace DSNUM ALL
         OBIDXLAT
         FULLDD FULLDS2
         QUICKCOPY COPY01(Y,SYSCP101,,LP)
         SORT-LOG
         SORTSIZE 16M
         REBUILD INDEX(ALL) TABLESPACE database.tblspace
         RBALRSN_CONVERSION EXTENDED

The source GDG image copy dataset could also be referenced by its absolute name:

//FULLDS2  DD   DSN=hlq.CPY.G0003V00,
// DISP=(OLD,KEEP)

When using the relative name messages like this in the sysout would be seen after the run that show the absolute name that was used:

IGD104I hlq.CPY.G0003V00          RETAINED,  DDNAME=FULLDS2

The actual image copy dataset is allocated to the FULLDS2 DD. 

The inline image copy being taken during the recovery will be newly allocated also so a message like this would be seen:

IGD101I SMS ALLOCATED TO DDNAME (SYSCP101)
        DSN (hlq.CPY2.G0004V00          )
        STORCLAS (TSO) MGMTCLAS (TSO) DATACLAS (DEFAULT)
        VOL SER NOS= TSU028

In the above message, a new dataset is created on GDG hlq.CPY2 which is the fourth generation dataset on that GDG. 

Later in the job messages will be seen showing the actual source image copy being used.

PFR0068I - IMAGE COPY 'hlq.CPY.G0003V00'
           WILL BE MERGED FOR TABLESPACE ' database.tblspace'

Regarding the inline image copy, messages like this would be reported showing the actual new imagecopy dataset being used by CA Quick Copy.

PQC0101I COPY001    - FULL IMAGECOPY    FOR database.tblspace
PQC0102I    DATASET: hlq.CPY2.G0004V00
PQC0103I    VOLUMES: SMS
PQC0010I SYSCOPY UPDATE: ICTYPE=F STYPE=  DSNUM=000 ICBACKUP=

PQC0100I COPY DATA PROCESS ENDING

When the recovery is complete , messages like this would be seen:

PFR0108I - RECOVER OF TABLESPACE 'database.tblspace'
           COMPLETED SUCCESSFULLY

Any indexes are rebuilt after the recovery.

PFR0110I - REBUILD OF INDEX 'authid.indexname'
           COMPLETED SUCCESSFULLY

So now, the target tablespace contains the data from the old image copy and is now in RW status ready to be used having taken a new image copy of the target tablespace. Notice that in the JCL, because GDG's are being used, there is no need to make name changes to the datasets. If this same JCL was submitted again, the same source image copy would be used, assuming no additional copies had been stored on the source GDG. A new generation dataset would be created for the inline image copy. In this example it would be the fifth generation next time.

 

Additional Information

FULLDD parm

 

OBIDXLAT parm 

 

QUICKCOPY parm