CA Quick Copy for DB2 for z/OS : About the different behaviour of the Quick Copy between R15.0 and R19.0.
Article ID: 192220
Updated On:
Products
Fast Recover for DB2 for z/OS
Quick Copy for DB2 for z/OS
Database Management for DB2 for z/OS - Recovery Suite
MM Backup and Recovery for DB2
Issue/Introduction
After upgrading the Quick Copy from R15.0 to R19.0, the R19.0 Quick Copy job was run with FULL NO parameter to a table space, but full image copy was copied in the Quick Copy job with the following message.
PQC0031I CONVERTING TO FULL IMAGE COPY -
DB:PTDBTEST TS:PTTSTEST PART: 000
Why?
On the other hand, if the same job was run with FULL NO with the Quick Copy R15.0, a incremental copy was copied in the Quick Copy R15.0 job.
Why was the full image copy copied in the R19.0 Quick Copy job though the FULL NO parameter was specified in the job?
Environment
Release : 19.0, 18.0, 17.0, 16.0
Component : CA Quick Copy for DB2 for z/OS
Resolution
The message PUT4309I was not present in Fast Load in R15, it was added later. The Qucik Copy checking of such event was not changed. So in R19 the COPY reacts correctly on that message (SYSCOPY row with ICTYPE=Y) and forces the FULL COPY conversion.
The PUT 648 which was a PTF in 16.0 Fast Load changes the UPDATE-SYSCOPY default to YES for LOAD and REORG when SYSCOPY USER is specified in the UTIL parmlib member (that is the case in the customer's jobs).
http://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-mainframe-software/database-management/ca-fast-load-for-db2-for-z-os/20-0/reference/product-syntax/keyword-descriptions/update-syscopy-update-sysibm-syscopy-with-log-no-indicators.html
So, it may be happening is that in R15 the default is UPDATE-SYSCOPY NO. Fast Load does not insert the LOG(NO) row into SYSCOPY, so Quick Copy does not know about the LOAD LOAD(NO) and continues with the incremental copy - it can see how that could be dangerous in terms of recoverability.
In R19 the default is YES, hence the PUT4309I messages and Quick Copy switching to full copy.
So if you want the R15 behavior back (we would not recommend it), they can code UPDATE-SYSCOPY NO in the PFL steps, then PQC should go with incremental.
The PUT 648 which was a PTF in 16.0 Fast Load changes the UPDATE-SYSCOPY default to YES for LOAD and REORG when SYSCOPY USER is specified in the UTIL parmlib member (that is the case in the customer's jobs).
http://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-mainframe-software/database-management/ca-fast-load-for-db2-for-z-os/20-0/reference/product-syntax/keyword-descriptions/update-syscopy-update-sysibm-syscopy-with-log-no-indicators.html
So, it may be happening is that in R15 the default is UPDATE-SYSCOPY NO. Fast Load does not insert the LOG(NO) row into SYSCOPY, so Quick Copy does not know about the LOAD LOAD(NO) and continues with the incremental copy - it can see how that could be dangerous in terms of recoverability.
In R19 the default is YES, hence the PUT4309I messages and Quick Copy switching to full copy.
So if you want the R15 behavior back (we would not recommend it), they can code UPDATE-SYSCOPY NO in the PFL steps, then PQC should go with incremental.
Feedback
Yes
No
Powered by
