Considering storage management subsystem requirements
Prior planning is necessary if you want to recover storage management subsystem (SMS) managed data sets in an environment comparable to that which existed at the backup site. SMS must be active to recover VSAM data sets specified in the ALLOCATE list.
SMS class names and attributes are displayed in an ARC6119I message
during the aggregate recovery verification. This may help you ensure
that the SMS-managed data sets are recovered as you intend.
Note:
- SMS status at the recovery site determines the status of the recovered data set. A data set that was SMS-managed at the backup site may not necessarily be recovered as SMS-managed and vice versa.
- You may want to create an aggregate that includes the SMS control data sets from the aggregate backup site. This aggregate could then be restored before restoring the aggregates for application data. This would be the most efficient way to create an SMS environment at the recovery site that matches the SMS environment at the backup site.
- When restoring an SMS-managed user catalog that was defined in
the ALLOCATE statement, ABARS passes the volume serial number where
the catalog resided at the backup site. If the target volume exists
at the recovery site, the user catalog is allocated on that volume.
If the original volume does not exist at the recovery site, the ACS
routines at the recovery site direct the allocation. In the event
that SMS determines the target volume to be invalid, ABARS requests
SMS to relax the guaranteed space rules so that user catalogs can
be directed to other volumes in a storage group associated with a
guaranteed space storage class.
Rule: If the original volume does not exist at the recovery site, you must modify your ACS routines to remove that volume from any storage group definitions associated with a guaranteed space storage class. If you do not, the recovery will fail.
- When restoring an SMS-managed NONVSAM data set which belonged,
at the time it was backed up, to a storage class with the guaranteed
space attribute, ABARS first attempts to allocate the data set to
the same volumes that it was backed up from. If the original volumes
are unavailable or no longer belong to a storage group that is associated
with a guaranteed space storage class, the data set is allocated to
different volumes existing in a storage group associated with a guaranteed
space storage class.
Note: If the original volumes do not exist at the recovery site, modify the ACS routines to remove the volumes from any storage group definitions associated with a guaranteed space storage class. Otherwise the recovery fails.
Nonmigrated, SMS-managed data sets in an INCLUDE list are directed
to the appropriate volumes during aggregate recovery by ACS routines.
The following information is passed to ACS routines when restoring
data sets backed up by DFSMSdss:
- Output volume serial numbers
- &ACSENVIR = RECOVER (environment in which ACS was invoked)
- Default data class name (if RACF® installed)
- Default management class name (if RACF installed)
- Default storage class name (if RACF installed)
- Data set name
- Data set organization
- RACF owner or group (if RACF installed)
- Data set type
- Expiration date
- High-level qualifier of the data set name
- Low-level qualifier of the data set name
- Maximum size of the data set in kilobytes
- Number of qualifiers in the data set name
- Number of volumes specified by the user
- Data set record organization
- Retention period
- Size of data set in kilobytes
- Unit name
If the data sets are not directed by an ACS routine or if SMS is not active, the data sets are recovered to level 0 volumes defined with the DEFINE ARPOOL command. If no level 0 volumes are defined to an ARPOOL, aggregate recovery uses the primary volumes that have been ADDVOLd to DFSMShsm.
The SETSYS ABARSVOLCOUNT(NONE |ANY) command affects the way in which SMS-managed data set allocations are performed by DFSMSdss for L0 data sets dumped from primary volumes.