DSF Technical Summary

FDRDSF

Program FDRDSF (Data Set Functions (DSF)) performs backups and restores of selected data sets and VSAM clusters. It can also do data set restores from full-volume backup tapes produced by FDR, ABR, or SAR. See FDRCOPY-Copy-or-Move-Data-Sets for a description of FDRCOPY, which performs DASD-to-DASD data set copies.

Data set backups

FDRDSF backups are similar to FDR backups, using the same format, but containing only the information and data tracks associated with the data sets selected by DSF control statements. You may select data sets by specific name, by prefix, or by sophisticated data set name masking. DSF backups operate on one DASD volume at a time, reading the VTOC of the volume, backing up the data sets you have selected and writing the backup to a tape or DASD data set. A separate backup data set is required for every DASD volume processed but that backup data set may contain backups of many original DASD data sets.

The backup contains an image of:

All tracks that are allocated to the selected data sets and VSAM clusters, according to the DSCBs in the VTOC.
An edited version of information from the VTOC and VVDS is also stored at the beginning of the backup, serving as an index of the data actually in the backup, and providing information for allocation of output data sets.
The VTOCIX and VVDS may be backed up as data sets, if DSF control statements select them. However, neither of these is required to be able to restore data sets from the backup, and they are usually not backed up.
Some information contained only the catalog entry for the data sets being backed up will also be included in the backup. This currently includes PATH definitions for the Alternate Indexes (AIXs) of VSAM clusters and the aliases of VSAM user catalogs.

Tip

If you are licensed for ABR, we recommend the use of PGM=FDRABR with TYPE=APPL for data set level backup.

Data set restores

FDRDSF data set restores are considerably different from FDR full-volume restores:

You may restore all data sets on the backup, or only selected data sets and/or VSAM clusters. The input to the restore may be an FDR, ABR, or SAR full-volume backup, or a DSF or ABR data set backup.
The data tracks of the selected data sets may be restored to a different physical location (cylinder and head address) than the original tracks occupied. In other words, you do not have to be concerned about the location of the output data set or the number of extents the data set is in.
Data sets and clusters may be renamed during restore.
If an output data set (either the original data set name or the new name) already exists, and is large enough; DSF replaces the contents of the existing data set and updates its describing information (VTOC and VVDS information). By default, DSF restores an existing data set to whatever volume it is currently cataloged.
If an output data set does not exist, DSF allocates it, automatically making it large enough to hold the contents of the input data set. Usually, DSF also catalogs the output data set as well (if the output data set is already cataloged to another volume, DSF does not catalog it unless you instruct it to do so). VSAM clusters must be cataloged when they are allocated, so a VSAM allocation fails if it is already cataloged (but you have an option to delete the existing cluster and catalog the new one in its place).
DSF usually restores data sets to the same device type they were backed up from (for example, from a 3390 backup to a 3390). This is called a like device or physical restore. The size (number of cylinders) on the original DASD volume and the output volume is not important, as long as the output has enough free space to hold the output data sets being allocated. In a like restore, the original data tracks of the selected data sets are restored exactly as they were backed up (but there is an option to re-block certain data set types).
Output data sets may be directed to various output DASD volumes. Data sets from one backup, originally all on the same DASD volume, can be restored to many output DASD volumes concurrently (reading the backup only once). FDRDSF JCL must point to the backup data sets, but the output volumes can be identified by JCL or by DSF control statements. You can also identify a list or group of volumes as the target volume; DSF will find one with sufficient space for the data set.
Multi-volume data sets can be restored, but only to the same number of volumes they originally occupied when dumped. Multi-volume VSAM is handled, but only when restored to the original device type.
At the end of the restore, DSF updates the DSCB of the output data set and, for VSAM and SMS-managed data sets, its VVDS entry, so that they properly describe the data that was restored. If a restore is interrupted or canceled, this update is not done and the data sets are probably unusable even though all the data tracks are restored.
If DSF allocated an output data set and the restore of that data set gets errors, such as DASD I/O errors, the data set is deleted from DASD, to avoid leaving unusable and uncataloged data sets.

Cataloging Non-VSAM output data sets

When restoring single-volume, non-VSAM data sets:

If DSF allocates space for the output data set, then the default is that DSF catalogs the data set to the output volume, unless the data set was already cataloged. Therefore, if the data set already exists on another volume and is cataloged to it, a DSF restore does not disturb it.
If the RECAT operand is specified, it catalogs the newly allocated data set to the output volume, whether the data set was cataloged to the input volume before the operation, or cataloged elsewhere, or not cataloged at all. This allows you to insure that the catalog points to the restored data set.
If the NOCAT operand is specified, then DSF does not catalog the newly allocated data set. This is ignored for SMS-managed data sets that must always be cataloged.
Cataloging/recataloging of non-VSAM data sets occurs at the end of the restore, and is bypassed if any restore errors have occurred for a given data set.
If the output data set exists on DASD before the restore, then DSF will not update the catalog, unless the CATIFALLOC operand is specified. CATIFALLOC causes DSF to apply the same rules described above for data sets allocated by DSF.
In the cases where DSF catalogs the output data set, if the output DSNAME was cataloged before the restore, DSF first deletes the old catalog entry. If the old catalog entry had non-specific SMS candidate volumes (*), these candidates are lost. If desired, they can be reestablished by IDCAMS ALTER ADDVOLUMES. If the old catalog entry had an ALIAS (an alternate name for a non-VSAM data set), the alias is kept.

Important

If a DSF restore is interrupted by an abend or system crash, then the output data sets are left on DASD, but are not cataloged. You should resubmit the restore to insure that all data tracks are restored, but the output data sets are already allocated so DSF does not catalog them unless you specify the operand CATIFALLOC.

For multi-volume, non-VSAM data sets, the above rules for single-volume data sets apply, with the following modifications:

If the data set is not already cataloged, DSF creates a new multi-volume catalog entry with the current output volume in the proper slot as indicated by the volume sequence number in the DSCB. If the volume sequence number is higher than 1, FDRCOPY fills in the preceding slots in the catalog entry with a dummy volume serial of “####nn”.
If the data set is already cataloged, DSF updates the catalog entry by putting the current output volume into the proper slot as indicated by the volume sequence number in the DSCB. On a RESTORE without RECAT, DSF updates the catalog entry only if the slot for this output volume contains the dummy volume serial of “####nn”; otherwise a warning message is issued.
When all pieces of a multi-volume data set have been restored, the catalog entry properly points to all the volumes to which it was restored (remember that a multi-volume data set must be restored to the same number of volumes it was backed up from). If the data set is already cataloged, this is true only if RECAT is specified. If you do not restore one or more pieces of the data set, the catalog entry is inaccurate and the data set is usable (it may contain “####nn” or original volume serial numbers). It is your responsibility to insure that the data set is backed up from all the volumes it occupies and is restored to the same number of volumes.

All of these rules sound complicated, but they are designed to automatically do the right things when cataloging non-VSAM data sets. You need to be concerned only if a data set being restored may already be cataloged to another volume; if so, specify RECAT if you want the newly restored data set to be the cataloged data set, leaving the other data set uncataloged. Specify CATIFALLOC if there is a chance that the output data set is already allocated but is not currently cataloged (and you want it to be the cataloged version).

VSAM support

DSF supports backup, restore, and allocation of VSAM clusters similarly to the way it handles non-VSAM data sets, with these differences:

DSF always refers to all components of a cluster by the base cluster name. You cannot select clusters by component name.
For clusters that have Alternate Indexes (AIXs), the Alternate Indexes (AIXs) are automatically selected, using the base cluster name. You never refer to an AIX by its AIX name.
DSF backup selects all components of the selected clusters (including AIX components) from the volumes being backed up. If a cluster has components on multiple volumes, it is your responsibility to backup that cluster from all of its volumes (you may want to use ABR Application Backup, described in FDRAPPL-Application-Backup, to automate this type of backup).
If DSF restore finds that the cluster's components already exist on the output DASD volumes; it restores the data back to the existing allocation.
If the cluster does not exist, DSF restore allocates and catalogs the cluster at the beginning of the restore (unlike non-VSAM data sets, VSAM clusters must be cataloged at the time they are allocated). If the backup contains a base cluster and one or more of its AIXs, the base is defined before the AIXs automatically. However, if the base cluster is on one volume and the AIX on another, it is your responsibility to restore the base cluster before the AIXs; contact BMC Support for assistance if necessary.
PATHs are catalog-only entries that relate base clusters to AIXs. When DSF defines an AIX, it will also define its PATHs.
If the cluster does not exist on the output volume but is already cataloged, the allocation fails unless the VRECAT operand is specified. VRECAT allows DSF to delete the cataloged cluster and redefine the new one in its place; this works even if only the catalog entry for the cluster exists (no actual data set on another DASD volume).
If the cluster includes a multi-volume component, or has data and index on separate volumes, special procedures are used (see Special-Considerations). The cluster will not be usable until all components have been restored.
At the end of the restore, the DSCB and VVDS entries for each component are updated.

For more information on VSAM operations, see Special-Considerations.

Absolute track operations

FDRDSF can also dump and restore data tracks by their physical, absolute track address. The tracks to be processed do not have to be allocated to a data set; you can select any tracks within the physical limitations of the input or output DASD volume. Ranges of tracks to be processed are identified by a starting and ending track address (cylinder and head number in decimal).

Absolute track restores can be done from any FDR, DSF, ABR, or SAR backup, including a DSF absolute track backup, as long as the requested tracks are on the backup data set.

DSF print options

DSF provides an option to print the contents of DASD tracks by fully-qualified data set name, by absolute track address, or by using generic data set name selection. For each track selected, DSF prints the record zero (R0) plus each physical record on the track. The count field, key (if any) and data are printed in storage dump format (hexadecimal plus EBCDIC).

SMS support

When dumping, DSF (as well as FDR and ABR) backs up SMS information from the VVDS and VTOC for both VSAM and non-VSAM data sets. This includes SMS class information (storage, management, and data classes), and SMS indicators. For those data set types supported only on SMS-managed volumes (such as Extended Format (EF) data sets), all information necessary to recreate the data set is also preserved.

When DSF restores a data set, SMS is invoked for every data set that must be allocated, to decide if the data set should be managed by SMS, or allocated as non SMS-managed. The SMS storage class and management class Automatic Class Selection (ACS) routines are invoked; they are passed input class names:

If the user specified STORCLAS=, NULLSTORCLAS, MGMTCLAS=, or NULLMGMTCLAS, those overriding values are used.
If the storage class or management class (or both) were not overridden by the user, the class associated with the input data set is used.
If the input data set was not SMS-managed, null classes are passed.
Your Automatic Class Selection (ACS) routines may accept those classes, or override them with different values or even null values.

If SMS assigns a storage class to a data set, it is SMS-managed; SMS is invoked again to allocate the data set on a volume chosen by SMS. If no storage class is assigned, DSF allocates the data set on a non-SMS volume (a target non-SMS volume must be indicated by a DISKx DD statement or a NVOL= operand on the SELECT statement). Even if data sets are allocated by SMS on a number of different volumes, DSF restores those data sets in one pass of the backup file.

So, DSF can be used to convert data sets to SMS management, simply by updating the SMS Automatic Class Selection (ACS) routines to assign storage classes to the restored data sets, or by specifying a storage class via the STORCLAS= operand on the SELECT statement. Data sets can be converted back to non SMS-managed if the Automatic Class Selection (ACS) routines assign no storage class or the NULLSTORCLAS operand is specified. However, FDRCOPY (FDRCOPY-Copy-or-Move-Data-Sets) or FDRCONVT (FDRCONVT-Overview) may be a better choice for conversion of data sets

Storage administrators, with proper authority, can override or bypass many of the SMS functions, to directly specify SMS classes, or to specify the volume serial on which SMS-managed data sets are to be restored, by use of the BYPASSACS and BYPASSSMS operands on the RESTORE statement.

More detail on SMS support is in System-Managed-Storage-SMS.

Processing specific types of data sets

Details of DSF and ABR processing for various types of data sets are in FDR-Processing-by-Type-of-Data-Set.

FDRINSTANT

If you are also licensed for FDRINSTANT, it enhances DSF to provide the ability to take backups that are frozen at a given point-in-time. This works with almost any DASD subsystem. It allows you to capture a point-in-time image of an online DASD volume to an offline DASD volume, effectively preserving the image of the online DASD volume at that point-in-time. FDRINSTANT can then read the offline DASD and create the required backups or copies, without relabeling the DASD volume or bringing it online. FDRINSTANT for various hardware platforms is described in: