The definitions are correct (FSVO correct). However, I think RMM is "ignoring"
what HSM is telling it due to the cycle count specified.
Try changing the "count" in the VRS to a "more reasonable (FSVO reasonable)
value.
e.g. 10 and see if the tapes release.
Reasonable should be somewhat in excess of the requirements for the number of
CDS backup versions, but not excessive.
<SNIP>
So, having found that these tapes are a VITAL RECORD, I found the following
VRS: -
HSM.%CDS.BACKUP.V¬¬¬¬¬¬¬ and HSM.JRNL.BACKUP.V¬¬¬¬¬¬¬
HSM.%CDS.BACKUP.V¬¬¬¬¬¬¬ has the following: -
Data set mask . : 'HSM.%CDS.BACKUP.V¬¬¬¬¬¬¬' GDG . : NO
Job name mask . :
Count . . . : 99999 Retention type . . . . . : CYCLES
While cataloged . . . . . : NO
Delay . . . : 0 Days Until expired . . . . . . : NO
Location . . . . . : HOME
Number in location : 99999
Priority . . . . . : 0
Release options:
Next VRS in chain . : Expiry date ignore . . . : NO
Chain using . . : Scratch immediate . . . . : NO
HSM.JRNL.BACKUP.V¬¬¬¬¬¬¬ has the same configuration.
The RMM implementation and customisation guide says: - <snip> To keep all
cycles of DFSMShsm control data set and journal backup tapes until DFSMShsm
releases them, issue RMM ADDVRS subcommands as shown: -
RMM ADDVRS DSNAME('authid.%CDS.BACKUP.V¬¬¬¬¬¬¬') -
COUNT(99999) CYCLES
RMM ADDVRS DSNAME('authid.JRNL.BACKUP.V¬¬¬¬¬¬¬') -
COUNT(99999) CYCLES
</snip>
So these definitions seem to be correct?
</SNIP>
This email � including attachments � may contain confidential information. If
you are not the intended recipient, do not copy, distribute or act on it.
Instead, notify the sender immediately and delete the message.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
