In order to analyze and fix the dataset control blocks reported by CPK516E and/or CPK522E messages you must first understand what are the Format-1 and Format-3 DSCBs and how to extract information from them using IEHLIST or DSF PRINT VTOC function. You can learn how to interpret IEHLIST or DSF PRINT VTOC outputs in the following KA: How to read IEHLIST / DSF PRINT DSN=VTOC outputs
Now that you are familiar with IEHLIST or DSF PRINT VTOC outputs, you can start analyzing your output to identify the issue reported by Compaktor.
Imagine that you received the following error messages:
CPK522E DSCB AT CCHHR(HEX) -- 0002000201 -- HAS AN INVALID CHAIN POINTER OR COUNT FIELD
-- DATA SET-P32.WPLE.VSAM
CPK516E DSCB AT CCHHR(HEX) -- 0002000203 -- IS PART OF A BROKEN F1-F2-F3 DSCB CHAIN
And your IEHLIST output shows:
P32.WPLE.VSAM
F1D7D7E3F3F8F400017C000300000001000AD7D7C3D7F7F740407C000300017C000580000000400080006D5E00000000C900C00000323E
48020000F400810000340000045A000E00000000000000000000000000000000000000000002000203 0002000201
FORMAT 3 DSCB 0303030381030B3C00000B6D000E81040B6E00000B9F000E81050BA000000D0A000E00000000000000000000
F3000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000 0002000203
The explanation for both messages are listed below:
|
|
DSCB AT CCHHR(HEX) -- cccchhhhrr -- IS PART OF A BROKEN F1-F2-F3 DSCB CHAIN
Explanation: Either a Format 1 or Format 2 DSCB does not point to a Format 3 when it should; or a Format 2 or Format 3 DSCB has no F1/F2 DSCB pointing to it. “cccchhhhrr” is the DASD address of the DSCB (cylinder, track, and record, in hex).
In that listing, the DASD address of each DSCB is printed on the right side of the third line for that DSCB. Locate the DSCB in error and attempt to fix the error condition.
User action: List the VTOC using the IBM IEHLIST utility.
If the DSCB identified by CPK516E is a Format 3, you can zap the DSCB to all binary zeros and then run a COMPAKTion to correct the VTOC. Sample JCL to do this zap is in member F3CLEAR in the FDR Installation FDRSAMP.
Warning
Message CPK516E may occur for conditions other than unchained F3 DSCBs, although that is the most common cause. DO NOT run the zap job until you have verified that all DSCBs identified in CPK516E messages are F3 DSCBs that are not themselves chained to another F3 DSCB (their last 5 bytes must be zero).
|
| CPK522E |
DSCB AT CCHHR(HEX) -- cccchhhhrr -- HAS AN INVALID CHAIN POINTER OR COUNT FIELD
Explanation: Either the count field (hardware record ID) of the chain pointer (pointer to the next DSCB for this data set) was invalid. “cccchhhhrr” is the DASD address of the DSCB (cylinder, track, and record, in hex). This can occur if:
- The count field of the specified DSCB does not match its physical location.
- The chain pointer in a Format 1 or 2 DSCB is invalid (does not point to a record in the VTOC).
- The chain pointer in a Format 3 DSCB is not zero for data sets that cannot exceed 16 extents.
User action: Use FDRDSF PRINT (see DSF PRINT Statement  ) to print the track where the DSCB resides and determine what field is in error. If the count field is in error, you have a serious problem and should contact IBM. If the chain pointer in a Format 1 or 2 DSCB is invalid, you can attempt to SUPERZAP the DSCB.
|
In that example, we can see that, based on the IEHLIST output, there is only 1 extent for that dataset in that volume. Which means there is no need to a Format-3 DSCB, since the Format-1 DSCB can hold information for up to the first three extents. Therefore, the Format-3 DSCB pointer found in the Format-1 DSCB is invalid, hence the CPK522E message. Furthermore, since the Format-3 pointer is invalid, the whole Format-3 DSCB located in 0002000203 is invalid, hence the CPK516E message.
In order to fix this situation, we must remove the Format-3 pointer in the Format-1 DSCB and remove the entire Format-3 DSCB located in 0002000203. We can do that by running AMASPZAP steps to replace the entries in the DSCB. However, BMC recommends NOT doing that without having a FULL VOLUME BACKUP for the volume being fixed. That way, if something goes wrong, you can restore the volume VTOC to it's original state.
The first example will take care of message CPK516E and replace the whole Format-3 DSCB located in 0002000203 by Hex zeros (this JCL cam be found in the F3CLEAR member of your FDRSAMP library on FDR 6.1):
//ZAPVTOC EXEC PGM=AMASPZAP
//SYSPRINT DD SYSOUT=*
//SYSLIB DD DSN=FORMAT4.DSCB,DISP=SHR,
// UNIT=SYSDA,VOL=SER=______ <--- FILL IN VOLUME SERIAL
//SYSIN DD *
CCHHR 0002000203 <--- FILL IN DSCB LOCATION FROM CPK516E MESSAGE
VER 00 03030303
REP 00 00000000000000000000000000000000
REP 10 00000000000000000000000000000000
REP 20 00000000000000000000000000000000
REP 30 00000000000000000000000000000000
REP 40 00000000000000000000000000000000
REP 50 00000000000000000000000000000000
REP 60 00000000000000000000000000000000
REP 70 00000000000000000000000000000000
REP 80 000000000000000000000000
The second JCL will address message CPK522E and remove reference to the Format-3 DSCB in the Format-1 DSCB for the particular dataset. Please note that the Format-1 dataset is located at 0002000201:
//ZAPVTOC EXEC PGM=AMASPZAP
//SYSPRINT DD SYSOUT=*
//SYSLIB DD DSN=FORMAT4.DSCB,DISP=SHR,
// UNIT=SYSDA,VOL=SER=______ <--- FILL IN VOLUME SERIAL
//SYSIN DD *
CCHHR 0002000201
VER 87 0002000203
REP 87 0000000000
The example presented resolves the situation above. Each situation is different and needs thorough analysis before the ZAPs are run. If you do not feel comfortable running those ZAPs, please contact BMC Support for assistance.