There are no special requirements to back up a catalog. Either
the catalog is backed up during volume backup of the volume it is
on, or it can be backed up by the BACKDS command. Although the catalog
is open when the backup occurs, DFSMShsm enqueues on the catalog to
prevent it from being updated while DFSMShsm makes the backup version.
Because this enqueue prevents access to the catalog by any other
user, for the duration of the backup, it is imperative that the elapsed
time of the backup be kept as short as possible.
Defining the user catalog with as large a data control interval
size as possible dramatically reduces the elapsed time to back up
a user catalog. Therefore, the user catalogs should be defined with
a data control interval size of one half track.
Use the following procedure to recover a backup version of a catalog:
- Purge all jobs that allocate the volume.
- Issue the F CATALOG,OPEN(volser) command
to determine which catalogs on the target volume are allocated.
- Issue, for each catalog that is open:
F CATALOG,UNALLOCATE(catalogname.)
to cause the catalog address
space to close the catalog and deallocate it.
- Issue the RECOVER command to DFSMShsm.
If DFSMSdfp is installed, aliases of the catalog are backed up
and recovered. When DFSMShsm attempts to recover a catalog, the following
rules apply:
- If the catalog does not exist, it is defined, along with its aliases,
from the backup version.
- If the catalog is empty, any aliases for that catalog in the system
catalog are not deleted. Aliases that were backed up are defined for
the recovered catalog if they do not already exist in the system catalog.
- If the catalog is not empty, it is deleted and redefined from
the backup version. Any aliases for that catalog in the system catalog
are not deleted. Aliases that were saved with the backup version are
not added to the system catalog.
The recovery of a catalog has the following restrictions:
- A catalog cannot be recovered with a new name.
- Aliases in the catalog are not backed up or recovered unless DFSMSdfp
is installed on the system.
- If you need to recover the master catalog, you must recover it
on a different z/OS® image.
- You must be a DFSMShsm-authorized user.
- If you do not use RACF® discrete
profiles for VSAM data sets, you can recover the catalog to the volume
of your choice. If, however, you do use RACF discrete profiles for some
VSAM data sets, the following restrictions apply:
- If the catalog contains entries for VSAM data sets that are protected
by RACF discrete profiles,
we recommend that you recover the catalog to the same volume it was
on when it was backed up. If the catalog is recovered to a different
volume, all VSAM data sets that were protected by a discrete profile
are now either unprotected or protected by a generic profile that
might not provide the level of access and security desired.
The RACF profile of a VSAM data set
reflects the catalog volume. DFSMShsm does not update these profiles
when it recovers a catalog. To restore the level of protection that
a discretely-protected VSAM data set had before the catalog was recovered
to a different volume, you have to update the data set's discrete
profile to indicate the new volume. The task of deciding whether to
update a discretely-protected VSAM data set's discrete profile,
and making the update, can be left to the owner of the data, if an
installation so desires.
When recovering non-SMS-managed catalogs,
you can use the TOVOLUME parameter to specify the volume from which
the catalog was backed up.
When recovering SMS-managed catalogs,
you can assign a storage class with the GUARANTEED SPACE attribute
as a means of requesting that the catalog is recovered to its original
volume.
- The HRECOVER command will fail if an ALIAS is substituted for
the data set name of a catalog, even if the user is DFSMShsm-authorized.