Need help understanding why some archive datasets seem to be missing
Article ID: 107812
Updated On:
Products
Disk Backup and Restore - MVS
DISK BACKUP AND RESTORE- ADD-ON OPTIO
DISK BACKUP AND RESTORE
Issue/Introduction
I'm guessing there is a parm somewhere for how long we keep archives
and these have expired, but I'm not sure how to find that information.
and these have expired, but I'm not sure how to find that information.
Environment
Release:
Component: DISKOS
Component: DISKOS
Resolution
When the DMS proc is used to ARCHIVE data sets, the archive image is set to be retained based on...
- The RETPD or EXPDT parm on the ARCHIVE command, or...
- The Sysparm RETRETPD [default of 30 days]
This would take effect if neither the RETPD or EXPDT parms are not specified.
The RETPD parm can be a value of the number of days to keep the image.
Or, it can be a value of 99365 [never expire] or 99000 [keep until it is uncataloged].
The value of the parms or Sysparms listed above sets the EXPDT in the DSNINDEX records.
If the data sets are SMS managed, then the MC controls when the archive image is
archived and when it is expired.
For SMS managed data sets, the DSNINDEX record is set to EXPDT=99365,
along with a flag indicating that it is SMS managed.
You can search your system JCLLIB for jobs that execute the DMS proc.
But, it is not uncommon that sites will rename our procs to suit their naming standards.
So, if you don't find "DMS" procs, then search for: "PARM=ADSST001"
Then, the DSCL control statements would be in the: //SYSIN DD *
or possibly: //SYSIN DD DSN=a.user.parmlib
The actual deletion of the DSNINDEX records from the archives is done by the IXMAINT proc
(or "PARM=ADSDM485") which usually runs nightly.
The typical parm that is executed on the //SYSIN DD * is just: DSNDELETE
It is a good idea to keep a list of your CA Disk jobs so you can easily review
for consistency of your Backup/Archive methodology.
Confusion can occur when most jobs retain the Archive images by catalog control
(EXPDT=99000) and other jobs do a permanent retention (EXPDT=99365).
A list of your Backup/Archive jobs can help you (and CA) to see what is happening.
- The RETPD or EXPDT parm on the ARCHIVE command, or...
- The Sysparm RETRETPD [default of 30 days]
This would take effect if neither the RETPD or EXPDT parms are not specified.
The RETPD parm can be a value of the number of days to keep the image.
Or, it can be a value of 99365 [never expire] or 99000 [keep until it is uncataloged].
The value of the parms or Sysparms listed above sets the EXPDT in the DSNINDEX records.
If the data sets are SMS managed, then the MC controls when the archive image is
archived and when it is expired.
For SMS managed data sets, the DSNINDEX record is set to EXPDT=99365,
along with a flag indicating that it is SMS managed.
You can search your system JCLLIB for jobs that execute the DMS proc.
But, it is not uncommon that sites will rename our procs to suit their naming standards.
So, if you don't find "DMS" procs, then search for: "PARM=ADSST001"
Then, the DSCL control statements would be in the: //SYSIN DD *
or possibly: //SYSIN DD DSN=a.user.parmlib
The actual deletion of the DSNINDEX records from the archives is done by the IXMAINT proc
(or "PARM=ADSDM485") which usually runs nightly.
The typical parm that is executed on the //SYSIN DD * is just: DSNDELETE
It is a good idea to keep a list of your CA Disk jobs so you can easily review
for consistency of your Backup/Archive methodology.
Confusion can occur when most jobs retain the Archive images by catalog control
(EXPDT=99000) and other jobs do a permanent retention (EXPDT=99365).
A list of your Backup/Archive jobs can help you (and CA) to see what is happening.
Feedback
Yes
No
Powered by
