CA DISK 12.5 : Automatic Restore and DFSMS Management Class override
Article ID: 103788
Updated On:
Products
Disk Backup and Restore - MVS
DISK BACKUP AND RESTORE- ADD-ON OPTIO
DISK BACKUP AND RESTORE
Issue/Introduction
In CA Disk, when an SMS-managed data set is processed using management class or storage group attributes, the expiration date value in the DSNINDEX record is always set to 99365.
When a data set is processed using SMS management class, CA Disk only uses the management class attributes. By default, the expiration date for all SMS-managed backup and archive DSNINDEX records is set to 1999.365, but this does not mean they will never expire. Their actual expiration occurs as follows:
- For a backup DSNINDEX record - this type of record is deleted when other backups are made after the physical data set on DASD is modified, or after the data set is physically deleted from DASD and no archive copies exist. All of this is based upon the management class backup attributes.
- For an archive DSNINDEX record - this type of record is kept until the expiration attributes in the management class are met. Therefore, the 1999.365 is used as a place holder. Expiration of the most current cataloged Archived copy is based on two management class fields:
* Expire days/date
* Expire after days non-usage
Finally, the IXMAINT & EXPIRE functions honor Management Class attributes as described in the
DFSMS Storage Administration Guide.
A new SMS dataset is allocated under a Management Class established by the DFSMS ACS Routines. Then this MC is changed using for example an IDCAMS ALTER instruction looking like the following:
ALTER dsname MGMTCLAS(newmc)
The dataset is then ARCHIVED so that CA Disk DSNINDEX record for this dataset has the newmc stored as MC.
What about the Autorestore?
Is the Autorestore able to Restore the dataset again under the newmc MC or the dataset will be restored under the initial MC assigned by the DFSMS ACS Routines?
When a data set is processed using SMS management class, CA Disk only uses the management class attributes. By default, the expiration date for all SMS-managed backup and archive DSNINDEX records is set to 1999.365, but this does not mean they will never expire. Their actual expiration occurs as follows:
- For a backup DSNINDEX record - this type of record is deleted when other backups are made after the physical data set on DASD is modified, or after the data set is physically deleted from DASD and no archive copies exist. All of this is based upon the management class backup attributes.
- For an archive DSNINDEX record - this type of record is kept until the expiration attributes in the management class are met. Therefore, the 1999.365 is used as a place holder. Expiration of the most current cataloged Archived copy is based on two management class fields:
* Expire days/date
* Expire after days non-usage
Finally, the IXMAINT & EXPIRE functions honor Management Class attributes as described in the
DFSMS Storage Administration Guide.
A new SMS dataset is allocated under a Management Class established by the DFSMS ACS Routines. Then this MC is changed using for example an IDCAMS ALTER instruction looking like the following:
ALTER dsname MGMTCLAS(newmc)
The dataset is then ARCHIVED so that CA Disk DSNINDEX record for this dataset has the newmc stored as MC.
What about the Autorestore?
Is the Autorestore able to Restore the dataset again under the newmc MC or the dataset will be restored under the initial MC assigned by the DFSMS ACS Routines?
Environment
Z/OS - DFSMS - CA Disk
Resolution
According to the the product architecture:
- CA Disk has NO ability to override what the ACS routines select. SMSMCBYP is for bypassing the mgmt class rules set by SMS so that if the mgmt class does not allow a backup, the customer can choose to override it and take the backup. It does not override the ACS routines.
- Depending on the SMSALLOC sysparm, CA Disk either passes the SMS class names to Allocation (SVC 99) or not. Passing the class names in is like specifying the classes in JCL/ISPF. CA Disk doesn't override what the ACS routines select.
- The point of SMSALLOC is to allow customers to pass class names into allocation just as ISPF and JCL do. The ACS routines can see the class name variables and use them or not. If SMSALLOC is set to N, the class name variables are blank. When it’s set to Y, the class names are filled from either the DSNINDEX or the class names from the command. CA Disk doesn’t override what ACS selects.
- CA Disk has NO ability to override what the ACS routines select. SMSMCBYP is for bypassing the mgmt class rules set by SMS so that if the mgmt class does not allow a backup, the customer can choose to override it and take the backup. It does not override the ACS routines.
- Depending on the SMSALLOC sysparm, CA Disk either passes the SMS class names to Allocation (SVC 99) or not. Passing the class names in is like specifying the classes in JCL/ISPF. CA Disk doesn't override what the ACS routines select.
- The point of SMSALLOC is to allow customers to pass class names into allocation just as ISPF and JCL do. The ACS routines can see the class name variables and use them or not. If SMSALLOC is set to N, the class name variables are blank. When it’s set to Y, the class names are filled from either the DSNINDEX or the class names from the command. CA Disk doesn’t override what ACS selects.
Feedback
Yes
No
Powered by
