A table was loaded with CA Fast Load for DB2 for z/OS (PFL) specifying syntax SET-COPY PENDING NO. Several CA Quick Copy for DB2 for z/OS (PQC) jobs were then run with SHRLEVEL CHANGE syntax and the following message was returned: PQC0809E SHRLEVEL CHANGE CANNOT BE RUN IMMEDIATELY AFTER LOAD UTILITY
The PQC0809E message was expected and consistent but suddenly the PQC SHRLEVEL CHANGE execution finished with a RC=00.
What would cause the PQC0809E message to suddenly no longer occur?
The PFL utility does not support LOG YES processing thus was run as LOG NO by default. Additionally the COPY PENDING status flag was reset by SET-COPYPENDING NO syntax within the PFL execution.
For PQC SHRLEVEL CHANGE processing to copy with recover consistency the utility must have valid RBA or CHECKPOINT value.
The following four options can provide recover consistency and avoid the PQC SHRLEVEL CHANGE PQC0809E failure after a LOAD with LOG NO.
- Specify QUICKCOPY or COPIES syntax within the PFL FASTLOAD statement.
In this case PQC performs an image copy while PFL is rebuilding indexes, it is not necessary to run later the PQC utility to create an Image Copy of the table space.
- After the PFL utility run the PQC utility with SHRLEVEL REFERENCE instead of SHRLEVEL CHANGE, the table space was set to COPY PENDING status after the LOAD LOG NO, PQC with SHRLEVEL REFERENCE quiesces those objects to obtain an RBA for SYSCOPY registration, performs the copy, and removes the copy pending status at the end of the copy.
- Create a usable quiesce point available to PQC. The following processes provide a quiesce point:
A. Execute a manual QUIESCE job prior to the PQC SHRLEVEL CHANGE execution.
B. Execute PQC SHRLEVEL CHANGE with QUIESCE BEFORE syntax.
- A DB2 subsystem checkpoint needs to occur.
A PQC SHRLEVEL CHANGE copy after a LOAD LOG NO (No COPY PENDING status) will fail if no CHECKPOINT has occurred.
In this particular case there was a DB2 subsystem CHECKPOINT taken just before the PQC job that finished with RC=00.