Data Set Restore Rules
When a data set is restored by FDRDSF or FDRABR, or copied by FDRCOPY, various pieces of “meta-data” (data that describes the contents of the data set) must also be updated with meta-data from the original data set. This “meta-data” must be accurate so that the data set is usable. The describing meta-data must be updated even if the output data set is preallocated, since it may be different from what was specified by the user during the allocation.
The meta-data always includes the Format 1 DSCB in the VTOC for a data set (for VSAM, there is a DSCB for each component). For VSAM, there is also a VSAM Volume Record (VVR) in the VVDS for each component. For non-VSAM, SMS-managed data sets, there is a non-VSAM Volume Record (NVR) in the VVDS. All of these are updated as appropriate.
In the following text, whenever it refers to “copying a field from the input”, the input is either the backup data set for a restore, or the input (original) data set for a copy or move. The indicated fields of the output data set are updated with the values of those fields in the input data set.
What is updated in the DSCB
The Format 1 DSCB field names in these tables are taken from the IBM IECSDSL1 macro, used to map DSCBs.
These fields are always copied from the input.
DS1VOLSQ
Volume Sequence Number (for multi-volume data sets).
DS1NOBDB
Bytes used in last Directory Block.
DS1FLAG1
Special SMS indicators.
DS1SYSCD
System Code.1
DS1DSORG
Data Set Organization.
DS1RECFM
Record Format.
DS1OPTCD
Option Code.
DS1LRECL
Record Length.
DS1KEYL
Key Length.
DS1RKP
Relative Key Position.
DS1TRBAL
Track Balance (unused bytes on the last used track).2
The following fields are never modified in the DSCB of the output data set, since the data set may have a different location and/or a different number of extents than the original:
DS1CREDT
DS1NOEPV
Number of extents.
DS1EXNTS
First three extent descriptors.
DS1PTRDS
Pointer to Format 2 DSCB (ISAM) or Format 3 DSCB (more than three extents), if any.
The following DSCB fields are handled specially during the restore or copy/move:
DS1DSSN
Data Set Serial – this field normally contains the volume serial of the DASD volume where the data set resides (for multi-volume data sets it points to the first volume of the data set). If DS1DSSN on the input matches the volume serial number of the input DASD or the DASD that was backed up, then DS1DSSN on the output volume is changed to that output volume serial number. If not, it is restored unchanged.
DS1EXPDT
Expiration date – copied from the input, if zero on the DASD.5,6
DS1REFD
Last Reference Date – is always set to today’s date on RESTORE and COPY, copied from the input on MOVE.6
DS1BLKL
Block Length – copied from the input unless BLKF= is used to re-block the data set.
DS1SMSFG
SMS Indicators (including PDSE and HFS flags, which may be set on non-SMS volumes as well) – if the output data set is SMS-managed, this flag byte is never copied from the input (flags are already set in the output DSCB). When restoring a non SMS-managed data set to non SMS-managed, the byte is always copied. When restoring an SMS-managed data set to non SMS-managed, the byte is copied but SMS-managed-only flags are reset.
DS1SCEXT
Extended Secondary Allocation Fields – they are valid only if a flag is set in the DS1SCALO field. They are copied from the input only if the extended secondary allocation flag is not set on the output DSCB.
DS1DSIND
Data Set Indicators – copied from the backup except that the update indicator X'02' is always turned on.
DS1LSTAR
Last Used Track (relative track number) – copied from the input except for PDSE and HFS data sets.7
DS1SCALO
Secondary allocation – copied from the input, if zero on the DASD volume. If the output data set is preallocated and a secondary allocation quantity was specified, it is not modified by restore.8
ABR RESERVED BYTES
Displacement 103 and 104 (decimal) in the DSCB – these fields are used by ABR Volume Backups; they contain flags and the current cycle number. Depending on the circumstances,
The bytes may be zeroed (indicating no current backup),
The bytes may be preserved in the output data set,
The bytes may be copied from the input,
The bytes may be copied from the input and modified to indicate that the ABR backup read for the restore is the current backup of the data set (if OLDBACKUP is enabled, the old backup information in DS1SYSCD is also modified).
Fields in the VVDS
On each volume, the VSAM Volume Data Set (VVDS) contains additional information about VSAM clusters and SMS-managed data sets. The VSAM data is in a record called the VSAM Volume Record (VVR); this includes SMS information for SMS-managed clusters. For SMS-managed, non-VSAM data sets, the data is in a record called the non-VSAM Volume Record (NVR).
The VVR and NVR are each divided into cells and sometimes sub-cells (cells within another cell). Each cell type has a number. A Type 24 sub-cell is common between VVRs and NVRs, but in general, they consist of cells unique to the VVR or NVR.
The text in the following sections describes in general terms what information is restored or modified in each VVDS record. It does not attempt to give details of processing for every field within those cells.
What is updated in the VVR
A VVR may be a VVDS record type Z or Q; each represents a component of a VSAM cluster, so a volume can contain two VVRs for a KSDS with data and index on the same volume. Z records are present on the primary (first) volume of each component of the cluster (the first volume of the data and the first volume of the index, if present). Q records exist on secondary volumes for multi-volume data sets. Q records are also used for imbedded indexes (the IMBED option of IDCAMS DEFINE CLUSTER). In this case a volume might contain two VVRs for the index component, a Z or Q for the real index and a Q for the index imbedded in the data component (although IBM no longer allows the creation of imbedded indexes, existing clusters with IMBED still work).
VVR header
Identifies the record type (Z or Q) and contains:
Component name.
Cluster name.
Name of the ICF catalog in which the cluster is cataloged.
Base cluster name (same as “cluster name” except for Alternate Indexes (AIXs) where the cluster name is the AIX cluster, while this field points to the base cluster to which the AIX is related.
These are not changed; if FDR allocated the data set then they are already correct; if not, FDR does not overlay the existing names.
Type 21 cell
Exists only in the Z record on the primary (first) volume of each component and contains some descriptive information, including:
Cluster attributes (for example, SPEED and REUSE).
Sharing attributes (SHAREOPTIONS(n,n)).
Space allocation attributes (primary and secondary allocation quantities).
High-allocated and high-used Relative Byte Addresses (RBAs) for the entire component.
Flags indicating if the cluster is an Extended Format (EF) or Extended Attribute (EA) cluster. These can exist only on SMS-managed volumes. VSAM EF clusters can be compressed and can exceed 4GB in size.
Most of these fields are copied from the input.
Type 24 sub-cell
Part of the Type 21 cell, it contains SMS information, primarily the SMS storage, management and data class names assigned to the data set. These are not changed; if FDR allocated the data set then they are already correct; if not, FDR does not overlay the existing classes.
Type 60 cell
Exists only in the Z record on the primary volume of each component and contains some basic descriptive information and statistics, including:
Cluster attributes (for example, INDEXED, IMBED, KEYRANGE, LINEAR).
Free space information.
Format information (for example, CIs per CA, CISIZE).
Usage statistics (for example, number of CA splits).
Last-updated timestamp.
Number of extents in the entire component.
Most of these fields are copied from the input.
Type 23 cell
Exists in all Z and Q records on every volume of each component and describes the piece of the component on that volume, including:
Volume/component attributes (for example, Q record for imbedded index).
Format information (for example, physical block size, blocks/track).
High-allocated and high-used Relative Byte Addresses (RBAs) for the component on this volume.
Number of extents in the component on this volume.
Extent descriptions (starting and ending track addresses) and RBA ranges for each extent.
Since this cell describes the cluster as it is allocated on the output volume, most of these fields are not copied from the input.
Type 27 cell
Contains information for Extended Format (EF) data sets on SMS-managed volumes. VSAM EF data sets include compressed clusters and clusters over 4GB in size. The entire cell is restored; it is created if it does not exist.
Type 29 cell
Contains information on Record-Level Sharing (RLS). The entire cell is restored; it is created if it does not exist.
Type 2A cell
Contains information for Extended Attribute (EA) data sets on SMS-managed volumes. This is primarily for data sets used by Network File System (NFS). The entire cell is restored; it is created if it does not exist.
When restoring or copying to a preallocated cluster (not allocated by FDR), FDR verifies that certain critical characteristics of the cluster on the output volume match those of the input data set, such as type (INDEXED, IMBED, and the rest), allocation (CISIZE, CIs per CA), and attributes (such as EF). Message FDR152 is printed when there is a mismatch; please review that message for all of the attributes that must match.
What is updated in the NVR
An NVR (VVDS record type N) exists only on the first or only volume of a SMS-managed, non-VSAM data set.
NVR header
Identifies the record type (N) and contains the data set name and the name of the ICF catalog in which the cluster is cataloged. These are not changed; if FDR allocated the data set then they are already correct; if not, FDR does not overlay the existing names.
Type 22 cell
Contains some basic indicators. For GDGs, it indicates if the generation is active, deferred, or rolled-out. It also indicates if the data set is a PDSE or HFS data set. There are flags indicating if the data set is an Extended Format (EF) or Extended Attribute (EA) data set. All of these are restored.
Type 24 sub-cell
Part of the Type 22 cell, this contains SMS information, primarily the SMS storage, management and data class names assigned to the data set. These are not changed; if FDR allocated the data set then they are already correct; if not, FDR does not overlay the existing classes.
Type 28 cell
Contains information for Extended Format (EF) data sets. Non-VSAM EF data sets include striped and compressed sequential data sets. The entire cell is restored; it is created if it does not exist.
Type 2B cell
Contains information for Extended Attribute (EA) data sets. This is primarily for data sets used by Network File System (NFS). The entire cell is restored; it is created if it does not exist.
FDRABR coexistence with CA disk
Beginning with FDR Release 05.04.83, ABR can coexist with CA Disk. This coexistence requires the use of some of the reserved fields used by ABR. Refer to FDRABR-Coexistence-with-CA-Disk for more information on which fields are affected.
VM and Linux volumes managed by FDRABR
ABR managed volumes require an ABR Model DSCB, which is a VTOC entry on a normal z/OS volume. VM and Linux volumes that do not have z/OS VTOC contain an 4K record containing the ABR Model DSCB on Cylinder 0 Track 14 of the DASD volume. Changing this record by another product will cause ABR backup information to be corrupted.