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.
DB2 for Z/OS
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.G0003V00 <--------------------- the sample JCL will obtain the dataset 2 generations old
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.
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:
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),
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.
As part of the recovery, a new inline image copy can be taken when the recovery is complete by calling CA Quick Copy :
The above parm refers to DD card SYSCP101 which is the target new image copy location.
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),
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,
//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
//SYSCP101 DD DSN=.CPY2(+1), <-------New image copy
//SYSIN DD *
RECOVER TABLESPACE database.tblspace DSNUM ALL
REBUILD INDEX(ALL) TABLESPACE database.tblspace
The source GDG image copy dataset could also be referenced by its absolute name:
//FULLDS2 DD DSN=hlq.CPY.G0003V00,
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'
Any indexes are rebuilt after the recovery.
PFR0110I - REBUILD OF INDEX 'authid.indexname'
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.