FDR Processing by Type of Data Set

This section describes how FDR data set operations (including DSF dump and restore, ABR dump and restore, and FDRCOPY copy and move) handle specific types of data sets.

Since FDRCOPY is essentially a data set dump and restore in the same task, all comments on dump apply to the input side of FDRCOPY and all comments on restore apply to the output side, unless there are specific notes about FDRCOPY.

As described in Data-Movement-Between-Different-DASD, a “physical” restore is usually used when restoring a data set unmodified to the same type of DASD it was dumped from; tracks are restored exactly as they were on the input DASD, except that they may be at new locations on the output DASD. A “logical” restore is usually used when restoring to an unlike DASD type, or when re-blocking of the data set is requested; the data set is rearranged for the new DASD geometry.

Unlike some competing products, all FDR backups are “physical” so that exact images of the input data set's tracks are written to the backup. The DSCB and VVDS records for all data sets dumped are written to the beginning of the backup data set for restore use. An FDR or ABR full-volume backup treats individual data sets the same as a data set backup, except that the default of DATA=ALL instead of DATA=USED is used.

Pervasive encryption on z/OS

Data set level encryption allows the data to remain encrypted during administrative functions such as backup/restore, migration/recall, and replication/copy, thus, FDR does not decrypt these data sets when performing these functions.

Restrictions for pervasive encryption:

• System data sets (such as catalogs, HSM data sets, RACF data sets) must not be encrypted unless otherwise specified.
• Encrypted data sets are supported only on 3390 device types.
• Sequential (non-compressed) data sets with a BLKSIZE of less than 16 bytes cannot be encrypted as they cannot be extended format.
• Data sets used during IPL must not be encrypted.

Physical Sequential

As the name implies, Physical Sequential (PS) data sets are simple DASD data sets that are written and read sequentially (from the start to the end).

Physical Sequential dump

Only the used tracks in a Physical Sequential (PS) data set (up to the “last block pointer” in the Format 1 DSCB) are dumped, unless the option DATA=ALL is in effect. If the last block pointer is all zeros (that could mean that the data set contains no records, or that it was never opened for output, or that it was updated by an access method that does not maintain the LBP), the entire allocated space is dumped.

Physical Sequential restore

Normally the used tracks of a Physical Sequential (PS) data set are restored (up to the last block pointer); DATA=ALL restores all of the allocated tracks and should be used only when restoring from a dump taken with DATA=ALL. A physical restore restores each track image for each selected track. A logical restore rearranges and/or reblocks the data set and restores data until an End-Of-File (EOF) record is encountered; DATA=ALL is ignored.

If reblocking is requested (BLKF= operand), and the data set has RECFM=FB or VB the logical records are reblocked to the new physical blocksize, which must be larger than the original blocksize except when restoring to a DASD with a smaller track size than the original DASD.

Physical Sequential allocation

If the output data set does not exist on the target output volume, FDR allocates it. It is allocated with the same number of tracks as the original unless the CYL=, TRK=, RLSE=, or %FREE= operands are specified (for a logical restore to an unlike device the space may be recalculated). The allocated space may be in fewer or more extents than the original, but the total tracks allocated must equal or exceed the number of tracks to be restored.

Physical Sequential multi-volume

Since FDR is a volume-oriented product, the pieces of multi-volume PS data sets are backed up to separate backup files. During the restore, FDR allocates each piece of the multi-volume data set on a separate volume, so it must be restored to as many volumes as it was dumped from. The data set is not usable until all original pieces have been restored.

Physical Sequential Extended format

On SMS-managed volumes, you can create a new format of PS data set called Physical Sequential Extended (PSE); also called an Extended Format (EF) data set. PSE data sets can be striped (allocated as multi-volume for performance) and/or compressed. FDR can allocate PSE data sets on SMS-managed volumes, and restores the striping and compression information.

Physical Sequential large sequential

In z/OS 1.7 and above, you can create a “large sequential” data set that can potentially exceed 65535 total tracks on a single volume. These data sets can exist on both SMS-managed and non-SMS volumes. These large sequential data sets are not “extended format” that was previously required for over 65535 tracks on SMS-managed volumes; they are in standard sequential data set format.

Partitioned (PO–PDS)

Partitioned Data Sets (PDS) contain mini-sequential data sets called “members”, pointed to by a directory. They are typically used for program libraries, source libraries, and control statement libraries.

Partitioned (PO–PDS) dump

Only the used tracks in a PO data set (up to the “last block pointer” in the Format 1 DSCB) are dumped, unless the option DATA=ALL is in effect.

Partitioned (PO–PDS) restore

Normally the used tracks of a PO data set are restored (up to the last block pointer); DATA=ALL restores all of the allocated tracks and should be used only when restoring from a dump taken with DATA=ALL. A physical restore restores each track image for each selected track; the PDS is not compressed.

A logical restore rearranges the data set, and updates the PDS directory to point to the new location of each member (note lists are also updated). Only live members (pointed to by a current directory entry) are restored, so the PDS is compressed. Diagnostics are produced if invalid directory entries or members are found during the logical restore. Logical restore reads the input data only up to the EOF (End-of-File) following the last active member; DATA=ALL is ignored.

If re-blocking is requested (BLKF= operand), the new physical blocksize is stored in the Format 1 DSCB of the PDS, and is used for new or updated members, but the existing members are not re-blocked during the restore.

PDS directories cannot be expanded in size during a restore. Even if the output data set is preallocated with a larger directory, the restore resets it to its previous size. If you are licensed for FDRREORG, the REORG command of FDRCOPY may be used to compress PDSs and expand directories (see FDRREORG-Reorganization-and-Compression).

Partitioned (PO–PDS) allocation

If the output data set does not exist on the target output volume, FDR allocate it. It is allocated with the same number of tracks as the original unless the CYL=, TRK=, RLSE=, or %FREE= operands are specified (for a logical restore to an unlike device the space may be recalculated). The allocated space may be in fewer or more extents than the original, but the total must equal or exceed the number of tracks to be restored. PDSs cannot be multi-volume.

Partitioned Data Set Extended

Externally Partitioned Data Set Extended (PDSE) data sets are used like standard PO data sets, but internally they have 4K blocks and an expandable directory, and reuse space so that they rarely need compression. They can exist on SMS-managed and non-SMS volumes.

Partitioned Data Set Extended dump

All allocated tracks are dumped.

Partitioned Data Set Extended restore

All allocated tracks are restored. A physical restore restores each track image. A logical restore rearranges the 4K blocks to fit on the new device; since pointers in a PDSE are by relative block number, not TTR, no other changes are made. If BLKF= is specified, the simulated blocksize used by access methods is updated in the Format 1 DSCB, but the 4K internal blocks of the PDSE are not changed. An IGWNOTIF macro is issued to purge any PDSE data still in buffers for this PDSE. A restore or copy can be used to convert a SMS-managed PDSE to non SMS-managed or vice versa.

Partitioned Data Set Extended allocation

If the output data set does not exist on the target output volume, FDR allocates it. It is allocated with the same number of tracks as the original unless the CYL=, TRK=, RLSE=, or %FREE= operands are specified (for a logical restore to an unlike device the space may be recalculated). The allocated space may be in fewer or more extents than the original, but the total must equal or exceed the number of tracks to be restored.

Hierarchical File System

Hierarchical File System (HFS) data sets use the same internal structure as PDSEs but they are used to store UNIX-style files for use with z/OS UNIX System Services (USS) (previously called Open Edition/MVS). They can exist on SMS-managed and non-SMS volumes.

Hierarchical File System dump

All allocated tracks are dumped. If HFS=QUIESCE (or ZFS=QUIESCE) is specified on the DUMP, COPY, SNAP, SPLIT, PSPLIT, FCOPY, CONSNAP, CONSPLIT, CONPSPLIT, or CONFCOPY statement, FDR first tries to get a SYSDSN enqueue on the HFS data set. If it is successful, the HFS file cannot be mounted to z/OS UNIX so this is sufficient to insure that no other task can use it during the backup. If the enqueue fails, which probably means that the HFS file system is mounted, FDR attempts to do a “quiesce” function to lock out all users of the file system until the backup is complete. This may cause other z/OS UNIX tasks using that HFS file system to wait. If HFS=QUIESCE is used and ENQ=RESERVE was specified, the backup must be run on the system on which the HFS file system is owned (shared HFS) or mounted (non-shared HFS); otherwise the backup may fail or hang (ENQ=RESERVE may be the default for certain FDR operations, such as FDRINSTANT).

FDR jobs that use HFS=QUIESCE must be authorized to use z/OS UNIX services; the userid under which the dump is run must be defined to your security system and it must have a z/OS UNIX UID assigned to it; it does not have to be a UNIX superuser. In IBM RACF, the UID is assigned in an OMVS segment attached to the userid or by a default OMVS segment defined by the resource BPX.DEFAULT.USER in class FACILITY; see IBM RACF documentation for details. For other security systems, consult their documentation for the equivalent functions.

If both the enqueue and the quiesce fail, then updates to the HFS file system may occur during the backup, which may make the backup unusable. For data set backups, if ENQERR=BYPASS is specified, the HFS data set is not backed up if the quiesce fails. If the HFS file system is mounted for read/write on another system, the quiesce may not prevent updates on that system so you should backup such HFS data sets only on a system where they are mounted as read/write.

Quiesce is not used for COMPAKTOR, ABR Archive, or FDRCOPY MOVE. In these functions, HFS data sets are bypassed or made unmovable if the SYSDSN enqueue fails. If you want to move or archive HFS data sets, you must dismount them first.

When HFS data sets are dumped with FDRINSTANT, HFS=QUIESCE should be specified only on the SNAP, SPLIT, PSPLIT, FCOPY, CONSNAP, CONSPLIT, CONPSPLIT, or CONFCOPY statement, and not on the DUMP statement, since the data set needs to be quiesced only while the point-in-time image is being created.

Hierarchical File System restore

All allocated tracks are restored. A physical restore restores each track image. A logical restore rearranges the 4K blocks to fit on the new device; since pointers in an HFS data set are by relative block number, not TTR, no other changes are made. A restore or copy can be used to convert an SMS-managed HFS data set to non SMS-managed or vice versa. If you are restoring to an existing HFS data set, you must unmount the file system before doing the restore.

Hierarchical File System allocation

If the output data set does not exist on the target output volume, FDR allocates it. It is allocated with the same number of tracks as the original. You must not use CYL=, TRK=, RLSE, or %FREE to change the size of a restored HFS file system, since this does not update internal pointers in the HFS file system that indicate its size.

zSeries File System

zSeries File System (zFS) data sets are another type of file system for UNIX System Services (USS), introduced in z/OS 1.2. zFS data sets are linear VSAM clusters.

Unlike HFS files, which use “lazy writes”, zFS files use immediate writes, so user updates to the file system are immediately written to DASD. Although this reduces the likelihood that a zFS file that is backed up while it is active is corrupted or unusable when it is restored, we recommend that zFS files be quiesced or unmounted before they are backed up, to be sure of getting a good image of all USS files within the zFS data set.

zSeries File System dump

FDR treats zFS data sets like any other VSAM linear cluster. All allocated tracks are backed up.

If ZFS=QUIESCE (or HFS=QUIESCE)⁹ is specified on the DUMP, COPY, SNAP, SPLIT, PSPLIT, FCOPY, CONSNAP, CONSPLIT, CONPSPLIT, or CONFCOPY statement, the following FDR functions handle zFS data sets similarly to HFS data sets.

• DUMP operations under FDRDSF
• COPY operations under FDRCOPY
• Data set DUMP (TYPE=ABR, TYPE=DSF, TYPE=AUTO, or TYPE=APPL) operations under FDRABR
• Full volume backup (TYPE=FDR) operations under FDRABR executing FDRINSTANT (where the main control statement is SNAP, SPLIT, PSPLIT, FCOPY, CONSNAP, CONSPLIT, CONPSPLIT, or CONFCOPY instead of DUMP)
• Backup operations under FDR executing FDRINSTANT (where the executing program (PGM=) is FDRSNAP or FDRFLASH).

For these functions, FDR first tries to get a SYSDSN enqueue on the zFS data set. If it is successful, the zFS data set cannot be mounted to z/OS UNIX so this is sufficient to insure that no other task can use it during the backup. If the enqueue fails, which probably means that the zFS file system is mounted, FDR attempts to do a “quiesce” function to lock out all users of the file system until the backup is complete. This may cause other z/OS UNIX tasks using that zFS file system to wait. If ZFS=QUIESCE is used and ENQ=RESERVE was specified, the backup must be run on the system on which the zFS file system is owned (shared zFS) or mounted (non-shared zFS); otherwise the backup may fail or hang (ENQ=RESERVE may be the default for certain FDR operations, such as FDRINSTANT).

FDR jobs that use ZFS=QUIESCE must be authorized to use z/OS UNIX services; the userid under which the dump is run must be defined to your security system and it must have a z/OS UNIX UID assigned to it; it does not have to be a UNIX superuser. In IBM RACF, the UID is assigned in an OMVS segment attached to the userid or by a default OMVS segment defined by the resource BPX.DEFAULT.USER in class FACILITY; see IBM RACF documentation for details. For other security systems, consult their documentation for the equivalent functions.

If both the enqueue and the quiesce fail, then updates to the zFS file system may occur during the backup, which may make the backup unusable. For data set backups, if ENQERR=BYPASS is specified, the zFS data set is not backed up if the quiesce fails. If the zFS file system is mounted for read/write on another system, the quiesce may not prevent updates on that system so you should backup such zFS data sets only on a system where they are mounted as read/write.

When zFS data sets are dumped with FDRINSTANT, ZFS=QUIESCE should be specified only on the SNAP, SPLIT, PSPLIT, FCOPY, CONSNAP, CONSPLIT, CONPSPLIT, or CONFCOPY statement, and not on the DUMP statement, since the data set needs to be quiesced only while the point-in-time image is being created.

For FDR full volume backups without FDRINSTANT and ABR full volume backups without FDRINSTANT, you need to execute a batch utility to quiesce zFS data sets before you back up those data sets or volumes containing them, and unquiesce them after the backup. Here is a sample job stream from the zFS Administration manual for quiesce:

//QUIESCE EXEC PGM=IOEZADM,REGION=0M, // PARM=('quiesce -aggregate zFSname') //SYSPRINT DD SYSOUT=* //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* //CEEDUMP DD SYSOUT=* //SYSUDUMP DD SYSOUT=*

Replace “zFSname” with the name of the zFS linear VSAM cluster. Change “quiesce” to “unquiesce” to enable the zFS data set for use after the backup.

Quiesce is not used for COMPAKTOR, ABR Archive, FDRCOPY MOVE, or FDRMOVE. In these functions, zFS data sets are bypassed or made unmovable if the SYSDSN enqueue fails. If you want to move or archive zFS data sets, you must dismount them first.

zSeries File System restore

All tracks in the zFS cluster are restored. You should only restore a zFS cluster to an output cluster of the same size, since zFS tracks available space internally and may not recognize the size change.

zSeries File System allocation

If the output zFS cluster does not exist, FDR allocates it, with the same size as the original cluster. You must not use CYL=, TRK=, RLSE, or %FREE to change the size of a restored zFS data set, since this does not update internal pointers in the zFS data set that indicate its size.

Direct Access (BDAM)

Direct Access (DA) (BDAM) data sets can be read or written directly, that is, any record in the data set can be read or updated at any time. DA data sets are typically used by third-party software for database storage (such as some database vendors).

Direct Access (BDAM) dump

All allocated tracks are dumped.

Direct Access (BDAM) restore

A physical restore restores all allocated tracks in a DA data set. A logical restore never re-blocks DA data sets, so it is used only for restores to unlike DASD types.

Logical restore does not restore DA data sets that were created with absolute track addressing (OPTCD=A). Logical restore rearranges the data blocks to fit on the new device type only for fixed-length (RECFM=F/FB) data sets. Variable-length (RECFM=V/VB) or undefined length (RECFM=U) DA data sets are restored by a physical (“track-image”) restore and that restore fails if the input data set has more data on a track than fits on a track of the output DASD.

A “track-image” restored DA data set may or may not be usable depending on the requirements of the program that accessed it; FDR has no way of knowing what those requirements are.

IAM data sets may be DA; see IAM Data Sets. Other software vendors may use DA files for databases or other uses. Contact BMC Support or the vendor for information on the use of FDR with these files.

Direct Access (BDAM) allocation

If the output data set does not exist on the target output volume, FDR allocates it. It is allocated with the same number of tracks as the original unless the CYL=, TRK=, RLSE=, or %FREE= operands are specified (for a logical restore to an unlike device the space may be recalculated). The allocated space may be in fewer or more extents than the original, but the total must equal or exceed the number of tracks to be restored.

Direct Access (BDAM) multi-volume

Since FDR is a volume-oriented product, the pieces of multi-volume DA data sets are backed up to separate backup files. During the restore, FDR allocates each piece of the multi-volume data set on a separate volume, so it must be restored to as many volumes as it was dumped from. The data set is not usable until all original pieces have been restored.

Unmovable

PS, PO, and DA data sets can be marked as unmovable in the Format 1 DSCB (via DSORG=PSU, POU, or DAU). An unmovable data set can be restored ONLY to the same track addresses on the output volume as it occupied on the input volume. If the data set does not already exist on the output volume, and it was allocated as a single extent on the input volume, FDR attempts to allocate space for it at the same locations. If it occupied more than one extent on the input volume or if the required space is not free on the output volume, it cannot be allocated. If the user preallocates space for an unmovable data set, it must be allocated at the correct locations; if any extent is not at the same location, message FDR111 is issued, indicating where the allocations should be made. Unmovable data sets cannot be restored to an SMS-managed volume.

IAM data sets

Innovation Access Method (IAM) is a separate software product from BMC Corporation that is a high-performance replacement for VSAM KSDS (indexed) and ESDS (sequential) data sets.

IAM data sets may be Direct Access (DA), Physical Sequential (PS) with RECFM=F, DSNTYPE=LARGE, or SMS Extended Format data sets. In either format, FDR properly restores them to a like or unlike DASD, with no special considerations.

Model DSCBs

A model DSCB is a data set with no tracks allocated (zero extents). They are usually used to contain model DCB information for a Generation Data Group (GDG). ABR uses a model DSCB on each volume to contain options and information about ABR's use of the volume.

Model DSCBs dump

Since there are no tracks associated with it, only the DSCB for the model is dumped in the control records on the backup data set.

Model DSCBs restore

If necessary, the model is allocated with no extents. The restore updates the model with the characteristics of the original.

The ABR Model DSCB (FDRABR.Vvolser) is never restored or moved since its information relates to the volume it exists on. Any attempt to select it results in a warning message. The ABR Model DSCB can be created or changed by the ABR ISPF dialogs (option A.I.8) or by program FDRABRM.

Generation Data Group

Generation Data Group dump

Since individual Generation Data Group (GDG) generations are simple non-VSAM data sets, they are dumped as described earlier based on their DSORG (usually PS).

Generation Data Group restore

GDG generations are restored according to the rules for their DSORG,

Generation Data Group allocation

Each GDG generation has an absolute generation number (for example, G0023V00) that increases with each new generation created. In normal use, they are usually referred to by relative generation number, relative to the most recently created generation. For example,

gdgname(+1) creates a new generation

gdgname(0) reads the most recently created generation

gdgname(-3) reads the third oldest generation.

By default, restore of a generation allocates and catalogs it under its original absolute number. If the current generations in that GDG all have higher absolute numbers, and the GDG index is full, catalog management uncatalogs (and may delete) the absolute generation that is currently the lowest one in the GDG (even if it has a higher absolute generation number than the one being restored), and catalogs the new one in its place. This may cause unexpected data loss. If multiple generations are being restored at one time, it may be that only the last one cataloged is restored correctly. If it is your intention to restore the GDG to its state at an earlier time, you should DELETE all of the currently cataloged generations and let the restored generations get cataloged in their place.

GDG data sets can be renamed to a new relative generation number using the NEWNAME= or NEWINDEX= operands on the SELECT statement, for example, NEWI=(+1) restores a GDG as the next available generation number.

See System-Managed-Storage-SMS for details on SMS-managed GDGs.

Standard User Label data set

Non-VSAM data sets may be allocated with standard user-labels (LABEL=SUL) that allocates an extra track for the storage of user labels containing application-dependent information separate from the data. FDR allocates such data sets correctly; if preallocated by the user, LABEL=SUL must be specified. The label track is always restored with a physical (track-image) restore even if the data is being restored logically.

IBM DB2

DB2 tablespaces are VSAM clusters with a special format; they are non-indexed files with a 4K CISIZE and none of the usual internal VSAM indicators; DB2 manages all data in the file. They are allocated as LINEAR clusters. FDR recognizes them by the special format of their cluster and component names:

catname.DSNDBx.dbname.psname.y000z.lnnn

The name has the following definitions:

catname

the high-level qualifier (HLQ)

x

can be “C” (for VSAM cluster) or “D” (for the VSAM data components)

dbname

the DB2 database name

psname

the table or index space name

y

can be “I” for the original name, “J” for the shadow name during a REORG, or “T” for the temporary name

z

can be either “1” or “2”

lnnn

the “l” can be “A”, “B”, “C”, “D”, or “E”, and the “nnn” is the data set number beginning with 001. Non-partition data sets always start with A001, for partition data sets:

A001-A999 for partitions 1 - 999

B000-B999 for partitions 1000 - 1999

C000-C999 for partitions 2000 - 2999

D000-D999 for partitions 3000 - 3999

E000-E999 for partitions 4000 - 4999

FDR dumps and restores DB2 files just like any other VSAM cluster, including moving or restoring to unlike DASD, with these considerations:

• If you are backing up active DB2 files, you should quiesce them or place them in read/only mode during the backup, using appropriate DB2 commands. The details vary depending on your level of DB2, but in recent releases the LOG SUSPEND and LOG RESUME commands are a convenient way of quiescing the DB2 data during the backup.
• If a DB2 file was allocated by DB2 onto a volume in a DB2 storage group (different from an SMS storage group), it can only be moved or restored to another volume in that same DB2 storage group.
• Since DB2 files must be recorded by DB2, and FDR has no way to update this information, DB2 files cannot be copied or restored to a new name; to do so makes them unusable by DB2. You must use DB2 utilities to copy DB2 files to new names and get them properly recorded.
• If you restore a back-level copy of a DB2 file, you may need to run the DB2 REPAIR utility to correct discrepancies between the data and DB2 records.

If you restore a DB2 file from an FDR backup, you may be able to bring the database up to a more current level by using the DB2 RECOVER utility to re-apply updates from the DB2 logs.

BMC Corporation has a white paper that describes how to backup DB2 files with FDR, with special emphasis on the use of FDRINSTANT for point-in-time backups; contact BMC for a copy. In addition, IBM DB2 manuals contain more information on using non-DB2 utilities such as FDR with DB2 data.

VSAM

VSAM-Special-Considerations contains details on support for VSAM clusters. In general, you can dump clusters and restore them to like or unlike DASD, or copy/move them to like or unlike DASD. You cannot restore or copy/move multi-volume VSAM clusters to unlike DASD.

VSAM clusters can also be Extended Format (EF), as described below.

Extended Format

Many SMS-managed data sets can be Extended Format (EF) data sets. EF data sets currently include:

• Striped sequential data sets. A striped data set is usually multi-volume, where record 1 is on volume 1, record 2 is on volume 2, and so on, so that multiple records can be read or written concurrently.
• Compressed sequential data sets
• Compressed VSAM KSDS clusters
• VSAM clusters over 4GB in size.

FDR allocates and restores EF data sets. EF data sets must be allocated to a SMS-managed volume that is at a hardware level that supports Extended Format. It is your responsibility to insure that your SMS ACS routines allocate the data set to an appropriate volume.

Extended Format VSAM clusters cannot be restored or copied to unlike devices, such as 3380 to 3390.

VTOC

VTOC dump

The VTOC is always dumped as a data set by full-volume dumps and by ABR Volume Backups. All tracks are dumped. In addition, any full-volume or data set dump dumps all DSCBs relating to the data sets dumped into control records at the beginning of the backup data set.

VTOC restore

Any data set restore requires that a DSCB exist in the output volume’s VTOC before it can be restored; this can be created by FDR or preallocated by the user. At the end of the restore, that DSCB is updated with information from the saved DSCB from the backup data set. (See Data-Set-Restore-Rules for details.) The VTOC cannot be restored as a data set; absolute track restore can be used to do restore the VTOC, but it is usually a mistake to try to do so. FDRCOPY never copies or moves the VTOC.

VTOC Index

VTOC index dump

If the volume has an indexed VTOC (SYS1.VTOCIX.volser), it is dumped as a data set if selected, by full-volume dumps, and by ABR Volume Backups.

VTOC index restore

The indexed VTOC on an output volume is updated by allocation of data sets and can be reconstructed from the information in the VTOC by the IBM utility ICKDSF, so it is always a mistake to restore or copy it. Any attempt to select it results in a warning message.

VVDS

VVDS dump

The VVDS (VSAM Volume Data Set, SYS1.VVDS.Vvolser) is dumped as a data set if selected, by full-volume dumps, and by ABR Volume Backups. All tracks are dumped. In addition, the VVDS records (VVRs for VSAM and NVRs for non-VSAM, SMS-managed data sets) are also recorded in control records at the beginning of the backup data set.

VVDS restore

Allocation of other output data sets by FDR or by the user creates the VVR and NVR in the VVDS of the output volume. The VVDS is automatically created by allocation if it does not exist on the volume). FDR updates the VVR/NVR information at the end of the restore. It is almost always an error to try to restore the VVDS as a data set; any attempt to select it results in a warning message. More details are in VSAM-Special-Considerations.

CATALOG

VSAM-Special-Considerations contains details on support for catalogs. FDRCOPY cannot be used to move or copy a catalog, and a catalog cannot be restored to an unlike device type such as 3380 to 3390. IDCAMS EXPORT/IMPORT or REPRO may be used if it is necessary to move catalogs to an unlike device type. Review the member MOVECAT in the Installation Control Library (ICL) for additional information.