George,
Did anyone suggest the tech doc?
ARC0744E RC36 RSN0 During CDS Backup to DASD
Technote (FAQ)
This problem can occur if there was a problem with the creation of a CDSBU
version, or if CDSBU is going to DASD and the earliest backup version
couldn't be located because the MHCR record is deleted or out of sync.
Answer
CDS BACKUP to DASD relies on locating the oldest CDS backup copy and using
this copy to write the newly created CDS BACKUP copy into it. The ARC0744E
RC36 RSN0 scenario usually involves HSM not being able to locate or use the
oldest CDS BACKUP copy data set.
Users will need to verify the LAST FINAL QUALIFIER and BACKUP VERSIONS KEPT
via HSEND QUERY CDSV. As an example, a user keeps 4 versions and the last
final qualifier is 10, there should be CDS backup versions 0000007, 0000008,
0000009, and 0000010 cataloged. This can be verified in ISPF 3.4 by doing a
list for the CDSBACKUP dataset names.
If any of the above required versions are not present, users will need to
allocate those datasets with the same DCB attributes of an existing version
and then run CDS backup again. This condition sometimes
occurs when a customer increases the number of CDS backup copies but fails
to pre-allocate the additional CDS backup copy datasets. EXAMPLE: Customer
is currently saving 4 CDS backup copies and currently has versions 0000007
through 0000010. Customer increases CDS backup copies to 5 but fails to
allocate the additional CDS backup copy dataset. The next time CDS backup
runs, HSM will attempt to find version
0000006 to write the newly created backup copy into, but will fail to find
it and will generate the ARC0744E.
The customer needs to preallocate the additional CDS backup copy dataset
with the version number of
0000006.
Still using the above example, if the user currently has backup versions
00000007 - 00000010 but the LAST FINAL QUALIFIER from the QUERY CDSV command
is shows 0000000, then the MHCR needs to be patched to correctly refelect
the latest CDSV backup version. To do this, issue the following patch:
HSEND FIXCDS S MHCR PATCH(X'B1' nnnnnnn)
where nnnnnnn is the correct last final qualifier of the cataloged CDSBACKUP
datasets. Don't include the preceding alpha character ('V', 'D', or 'X').
If the user's condition is not listed above, keep in mind the objective is
to get the correct sequential number of cataloged backup versions allocated
and listed based on what the current final qualifier is and the number of
version of kept. If there is an Xnnnnnnn version listed then this is simply
an indication that CDS BACKUP failed for that version. HSM will still
recognize this version and write over it once the problem is corrected and
CDS BACKUP is run again.
Lizette
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
