Previous Topic: Retain Days Extra Backup Versions (MC)Next Topic: Expiration Dates Inspected


Determining How Long To Keep DSNINDEX Records

By default, an archive copy of an SMS-managed DSNINDEX record will be kept until the Expire Days Non-Usage (MC) is met, and/or the Expire After Date/Days (MC) has occurred.

In theory, this works quite well. But in the real world, this data set can be archived and restored only to be modified, backed up, and eventually archived again. The result is two archive DSNINDEX copies waiting for the expiration date to occur. To complicate matters, the first archive copy would have its expiration date extended because of the restore. (that is, the restore date would take precedence over the format-1 DSCB USEDT). This means that both copies would be kept for several years, or worse yet, indefinitely if the Management Class expiration date attributes were defined as NOLIMIT.

Therefore, it is suggested that sysparm RESIXRPD (described in RESIXRPDnn in the Systems Guide) be used to determine how long to keep DSNINDEX records which have previously restored. However, to ensure that there is at least one copy of a DSNINDEX record at all times, RESIXRPD should be used in conjunction with the Guaranteed Backup (SG) value.

Alternatively, the sysparm IXSMSDEL (described in IXSMSDELn in the Systems Guide) can be used to delete obsolete SMS archive DSNINDEX records from the DSNINDEX subfile during processing. When IXSMSDEL is set to Y (and IXMAINT is processing under SMS rules), the most current Archive SMS DSNINDEX is checked to see if it was re-catalogued at archive time and to validate that the current catalog volume is the recatalog volume (see RECATVOL sysparm). The archive DXNINDEX record is deleted if the current volume is not the recatalog volume, if the data set is uncatalogued, or if the archive DSNINDEX is not the most current.