VSAM Special Considerations

This section explains some of the special considerations that a user should be aware of when dumping or restoring VSAM clusters.

There are special rules and considerations for multi-volume clusters. If multi-volume clusters are involved, be sure to read Multi-Volume VSAM Considerations.

What FDR dumps

FDR, DSF, and ABR backup VSAM Clusters. All of a cluster’s associated components that reside on a single volume are dumped. This includes the index, data, Alternate Indexes (AIXs), key ranges, and the rest. In addition, FDR saves the VVR information contained in the VVDS for each component in control records at the beginning of the backup. Information on PATH names of Alternate Indexes (AIXs) and aliases of user catalogs is also extracted from the catalog and saved on the backup. The only information FDR does not preserve is other information exclusively maintained within the catalog, including passwords, RACF indicators, and Candidate Volumes. These fields are not recorded by FDR and are not restored. On non-SMS volumes, the expiration date is also only in the catalog and is not preserved; on SMS-managed volumes, the expiration date of ICF clusters is preserved.

FDR dumps VSAM files by track image, which is the same technique used for every other type of file. FDR is not access method oriented. If logical errors exist within the file, they are not detected by FDR. However, certain types of errors within the VVDS data set are detected and reported.

For DSF and ABR data set backups, SELECT statements should select VSAM clusters only by the base cluster name, never by individual component names or alternate index cluster names. Even if a volume contains only an alternate index (AIX), the base cluster name must be used, not the AIX cluster name. However, COMPAKTOR SELECT statements, which may be used to position VSAM components, accepts ONLY component names.

VSAM last reference date

VSAM OPEN updates the DSCB with the update flag (for OPEN OUTPUT or UPDATE) and the last reference date (for any OPEN), but only in the DSCB of the data component of the base cluster and only on the first volume of a multi-volume cluster. They are not set in the DSCBs of index components or alternate index components. They are not set at all in the base data component for a keyrange KSDS.

ABR volume backups

ABR incremental Volume Backups select VSAM clusters. If the update flag is on for any component of a cluster, ABR backs up all of the associated components that reside on the volume being dumped. Since the update flag is never set on secondary volumes, when ABR finds that a volume contains only secondary pieces of a cluster it always backs them up. VSAM can be totally excluded only by a statement such as: EXCLUDE ALLDSN,DSORG=EF

ABR Application Backups

ABR Application Backups (FDRAPPL) back up VSAM clusters. Since the catalog is normally used to locate data sets for Application Backup, all components of the selected clusters are backed up from cataloged volumes. The Application Control File records all cluster and component names.

ABR Archive and Superscratch

ABR can Archive or Superscratch VSAM Clusters. VSAM clusters can be selected manually (SELECT statement) or by automatic criteria such as ADAYS=. For the operands ADAYS= or ADATE=, ABR only uses the last reference date stored in the data component of the base cluster. For multi-volume VSAM, the last reference date is stored only in the DSCB of the base data component on its first volume, so ABR locates and obtains that DSCB for ADATE=/ADAYS= processing if it is not on the volume currently being processed.

The operands IFNOTCAT and MAXGDG= do not apply for VSAM clusters and are ignored. The EXPIRED operand only works on SMS-managed clusters. If the SIZE= operand is specified, this size is checked against each of the components; if any component exceeds the size specified, the entire cluster is archived.

The operator is not given message FDRW23 on unexpired VSAM Clusters. If the VSAM Cluster is not expired, ABR does not scratch the cluster unless VEXPD=NONE or EXPD=NONE is specified on the DUMP control statement.

The Archive Control File records the cluster name and each of its component names. ABR prints an FDR314 message for each of the components selected, and when the last component for the cluster is printed, it prints an FDR314 message for the cluster name. For multi-volume VSAM, the cluster is not scratched until it has been backed up from every volume that it exists on; all of those volumes must be processed in the same ABR Archive step (if some volumes of the cluster are not processed in a given ABR step, message FDR154 is issued and the cluster is not scratched).

VSAM restore rules

For FDR and ABR full-volume restores, the VVDS and all VSAM components are, of course, restored. It is the user's responsibility to be sure that the clusters are properly cataloged; no cataloging is done by a full-volume restore.

DSF and ABR data set restores can restore VSAM files from data set or full-volume backups. The base cluster name, not individual component names, is always used to select VSAM. Once selected, all of the components of a cluster which exist on the backup (from one single DASD volume) are restored; this includes the data, index, Alternate Indexes (AIXs), and key range components. An alternate index cluster cannot be restored individually unless it resides on a volume by itself (see Multi-Volume VSAM Considerations), and even then, it is selected using the base cluster name, not the AIX cluster name.

Data set restores can be “physical” or “logical”. A physical restore is a “track-image” restore and is used when the cluster is being restored to the same DASD device type as the original cluster resided on; the tracks of the data set look exactly as they did when dumped, and the cluster is not reorganized or rearranged in any way. A logical restore is used when restoring a VSAM cluster to a different device type (a “unlike” restore); the control intervals in the component are rearranged to fit on the new device type, but the cluster is still not reorganized. Use FDRREORG to reorganize VSAM KSDS clusters.

Logical restore may change cylinder-allocated clusters to track-allocated; this is normal and causes no performance problems. Logical restore is sometimes used for KSDS clusters with the IMBED option, even when restoring to a like device.

After the individual components have been restored, the VVR information in the VVDS data set is updated for each component. Information exclusively maintained in the VSAM catalog is not updated. This includes passwords, RACF indicators, and candidate volumes; it also includes the expiration date for ICF clusters on non-SMS volumes. This is not a problem if the data set is being restored back into the original VSAM cluster. If you predefine the cluster for the restore, you should specify this information in the DEFINE. If FDR defines the cluster, you should re-establish this catalog information with the IDCAMS ALTER command after the restore. If the cluster was protected by a IBM RACF discrete profile, that protection must be re-established in the catalog with a RACF command.

When an alternate index (AIX) is allocated by FDR, all PATH names associated with that alternate index are also defined. However, PATHs that relate only to the base cluster (similar to aliases for non-VSAM data sets) are not defined; you must manually do a DEFINE PATH for them.

The restore printout reports on each component name restored, giving its associated cluster name.

FDRCOPY of VSAM

An FDRCOPY disk-to-disk data set copy or move (see FDRCOPY-Copy-or-Move-Data-Sets) is essentially a simultaneous dump and restore, so the preceding rules for backup and restore of VSAM apply. However, since the input cluster still exists during the copy, information only in the catalog (passwords, expiration date, and the rest) is copied to the equivalent output cluster. If the input cluster was protected by a discrete RACF profile, a discrete profile is created for the output cluster using the input profile as a model. If the input cluster has candidate volumes, they are copied to the output cluster only if the input cluster currently has data on only a single volume.

Since two clusters by the same name cannot exist in the same catalog, an FDRCOPY COPY of a VSAM cluster must be to a new name unless the new cluster is directed to a new catalog; these options are described in following paragraphs. A MOVE of a VSAM cluster is accomplished by assigning temporary names to the output cluster and its components; they are renamed after the input cluster is deleted. See FDRCOPY-Copy-or-Move-Data-Sets for details.

FDRCOPY supports both “physical” and “logical” copies (as detailed under VSAM Restore Rules), so clusters can be copied or moved to “unlike” DASD devices.

NEWNAME restore

A VSAM cluster can be restored or copied/moved to a new name (NEWNAME=) or new group name (NEWGROUP=) or with new or replacement index levels (NEWINDEX=). ICF catalogs and SYS1.VVDS data sets cannot be renamed so they cannot be copied or moved, they can only be restored.

If NEWNAME= is specified, this name is used as the new output cluster name:

• If the named output cluster already exists, a LOCATE is done to determine the associated component names for that cluster, matching each type of component (data, index, alternate index) with the corresponding component from the backup. If NEWNAME= is specified for clusters which contain more than one alternate index, the Alternate Indexes (AIXs) may not be correctly restored.
• If the cluster named by NEWNAME= does not exist it is allocated by FDR, allowing VSAM to generate default names for the components. FDR uses the generated names as implied “newnames” for the components. A VSAM cluster that contains Alternate Indexes (AIXs) cannot be allocated if NEWNAME= is specified.

We recommend the use of NEWGROUP= or NEWINDEX= instead of NEWNAME= if the output cluster must be allocated.

If NEWGROUP= or NEWINDEX= is specified, FDR applies the group name or indexes to the cluster name and all of the associated components, including any alternate index clusters and their components. If any of the cluster or component names are too short or contain too few index levels, or if the generated new names are duplicates of one another, the restore fails. If the new cluster name does not exist, the cluster is allocated using all of the new component names. If the new cluster is preallocated, then all of the existing component names must match the new names generated by FDR.

Allocating VSAM clusters

If the components of the output cluster are found on the output DASD volume, such as when restoring the backup copy of an existing cluster, FDR simply overlays the contents of the components; no allocation is required. However, a logical (unlike) restore of VSAM cannot restore to a preallocated cluster.

If the output cluster name is not found on the target DASD volume, the cluster is allocated (see Multi-Volume VSAM Considerations). The cluster is allocated so that each component has a primary allocation equal to the total amount of space the data set occupied when it was dumped, so a component that was in multiple extents when dumped may occupy fewer extents when restored.

The primary allocation of the data component of the base cluster may be overridden by the CYL= or TRK= operands of the SELECT statement, but the value specified should be equal to or greater than its original allocation (if not, FDR extends the data set to its original size). On track or record allocated clusters, VSAM rounds up the value you specify to a multiple of the number of tracks in the CA. When doing a “logical” restore or copy/move to a different DASD type, the allocation quantity is adjusted.

The ICF catalog into which the new cluster is defined depends on the ICFCAT= parameter on the RESTORE statement:

ICFCAT=ORIGINAL

The cluster’s original catalog name is used. If that catalog does not exist on the system where the restore is run, the allocation fails with message FDR157 COMP=0004 CODE=00120; use ICFCAT=ALIAS to direct the cluster to a different catalog. ICFCAT=ORIGINAL is ignored when restoring a cluster to a new name; ALIAS is forced instead.

ICFCAT=ALIAS

FDR attempts to locate the user catalog associated with the new cluster name in the master catalog; if found, this catalog is used; if the alias does not exist in the master, the master catalog is used. Multi-Level Alias (MLA) is supported.

ICFCAT=ORIGINAL is the default when restoring a cluster to its original name. When restoring to a new name, ICFCAT=ALIAS is the default.

Since VSAM clusters must be cataloged at the time they are allocated, the define of a cluster normally fails if the cluster name or any component name already exists in the catalog in which FDR is attempting to catalog the cluster. This might be the case if the cluster currently exists on another volume, or if you are restoring a cluster that does not exist on its target volume but is still cataloged. The VRECAT operand on RESTORE commands allows FDR to allocate a cluster even if it is in the catalog. VRECAT attempts to DELETE the cluster; if that fails, a DELETE NOSCRATCH is attempted.

Although IBM no longer allows new clusters to have the IMBED, REPLICATE, or KEYRANGE options, FDR is able to allocate output clusters with these options if they were used in the clusters being restored.

User allocated VSAM clusters

Although it is possible for you to preallocate new output VSAM clusters with IDCAMS DEFINE, and then restore into them with FDR, it is usually much simpler to let FDR allocate the clusters.

If you preallocate the output clusters, all the characteristics of the cluster must match those of the cluster being restored, such as the type of cluster, options, CISIZE, CASIZE, physical blocksize, and the rest. For some options (such as IMBED, REPLICATE, KEYRANGE) IDCAMS may ignore the options, producing a cluster that is not usable by FDR. FDR produces an FDR152 message indicating any mismatched attributes if the output cluster is not allocated correctly.

If a VSAM cluster being restored has the original cluster name but the component names are different from the original cluster, specify the same cluster name in both the DSN= and NEWNAME= operands. This forces FDR to locate the new component names from the catalog.

For logical (unlike device) restore or copy/move, you must let FDR define the cluster.

ICF catalog restore

DSF and ABR can dump and restore ICF catalogs to a like DASD type. ICF catalogs can be restored without restoring or affecting the clusters cataloged within them. After a restore, an IDCAMS DIAGNOSE should be run against the catalog to detect any inconsistencies between the catalog and the VVDS data sets associated with it. This detects clusters that are in the catalog but were scratched since the backup. These entries can be deleted using IDCAMS with a DELETE NOSCRATCH command. A DIAGNOSE of all the VVDSs that reference this catalog detects clusters that were added since the backup. An IDCAMS DEFINE RECATALOG command re-establishes these clusters in the catalog; information exclusively maintained in the catalog is not re-established automatically, but must be specified on the DEFINE RECATALOG command.

This is a significant advantage over other methods of restoring these catalogs that require the individual clusters to be restored in order for the catalog to be recreated.

ICF catalogs can be restored to a new volume. FDR alters the self-defining records within the catalog to reflect the new volume serial. However, ICF catalogs can only be restored to the same DASD device type they were dumped from.

ICF catalogs cannot be restored to a NEWNAME. The reason for this restriction is that the clusters cataloged within this catalog, including its own self-defining record, would not know the NEWNAME. If a catalog is re-allocated, VSAM may assign a new name to the index component of the catalog. FDR is designed to recognize this change without the use of NEWNAME.

DSF and ABR allocate an output ICF catalog if it does not already exist on the target volume, automatically connecting it into the master catalog of the system it is restored on and the VVDS on the volume it resides on. You cannot restore an ICF catalog to a new volume while the original catalog is known to the master catalog, because this would create a duplicate entry in the master catalog. You must use IDCAMS to either DELETE the original catalog (possibly specifying RECOVERY), or do an EXPORT DISCONNECT.

Because of the above considerations, FDRCOPY cannot copy or move an ICF catalog.

When an FDR RESTORE defines an ICF catalog, it also defines any aliases that the catalog had at the time it was dumped.

You should not restore a catalog in the same job step that restores any data sets that are cataloged in that catalog. For example, if the restore does a DEFINE for a data set, the new catalog entry is wiped out when the catalog is restored.

VVDS dump and RESTORE

DSF or ABR can back up the SYS1.VVDS.Vvolser data set. If a restore of this data set is to be done, it should be done with care. This data set is, in effect, the VTOC for the VSAM files on this volume (and on SMS-managed volumes, for non-VSAM data sets as well). If a VVDS is restored, there exists the potential that the information contained in the VVDS, the VTOC, and the catalog are “out-of-synch”. An IDCAMS DIAGNOSE should be run after a VVDS restore, on the VVDS and all the catalogs that use the volume that detail most of the inconsistencies between the VVDS, the VTOC, and the ICF catalogs. Any errors must be manually corrected.

To ensure that the VVDS is not accidentally restored, DSF and ABR do not restore the VVDS unless the fully qualified name is specified (DSN=) and PROT=NONE is coded on the RESTORE statement. The VVDS should be the only VSAM cluster restored in this execution. If the VVDS is included as part of an ALLDSN or DSN=mask restore, it is bypassed with a warning message.

The SYS1.VVDS data set cannot be restored to a new name, and it must be restored to the same tracks that it was dumped from. The reason for these restrictions is the presence of self-defining records within the VVDS and every catalog that references it. Therefore, if the VVDS has been deleted or the volume re-initialized, it is not possible for FDR to allocate and restore a usable VVDS (except by full-volume restore). If the VVDS has been lost, you generally have to recover a backup copy of every VSAM cluster on the volume (non-VSAM data sets as well on a SMS-managed volume).

If the volume serial number is changed on a volume containing a VVDS, all of the VSAM clusters on that volume are inaccessible. The FDR system is not able to dump and restore them by cluster name.

FDRCOPY cannot copy or move a VVDS.

Since FDR updates the VVDS during the allocation and restore or copy/move of an ICF cluster, it is almost always a mistake to explicitly restore the VVDS, except during a full-volume restore. Contact BMC Support for advice before attempting to restore the VVDS.

Multi-volume VSAM considerations

Multi-volume VSAM Clusters are VSAM clusters having components that reside on multiple volumes. There are four types of multi-volume clusters:

1.A KSDS with the index component on one volume and the data component on another

2.A KSDS with an alternate index on a different volume

3.A key range KSDS with the keyranges on multiple volumes

4.Any type of cluster where any component, including a single keyrange component, has expanded to multiple volumes.

In addition, there are two types of single-volume VSAM clusters that because of their special allocation requirements, are treated like multi-volume clusters during allocation:

1.A “split imbedded index” KSDS, that is, a KSDS with the IMBED option, where the high-level index component has expanded into additional extents

2.Any keyrange KSDS.

Most of the comments in this section do not apply to these clusters, except for the explanation of allocation.

FDR and ABR full-volume operations can always handle multi-volume VSAM clusters, as long as all volumes involved are dumped and restored at the same time, and all volumes are restored to their original volume serial numbers. DSF, FDRCOPY, and ABR data set operations can dump, restore, and allocate multi-volume clusters, but there are some special rules and considerations:

• VSAM OPEN sets the update indicator and last reference date only for the data component on the first volume for the base cluster. KEYRANGE clusters never have indicators set even on the first volume. This presents a problem for ABR in that incremental backups cannot determine if the components residing on the remaining volumes need to be dumped. On incremental backups, ABR always dumps these multi-volume components except for an alternate index residing on a volume by itself.
• When Archive and Superscratch are selecting data sets based on the last reference date (the ADATE= or ADATES= operands, or SMS management class attribute PRIMARY DAYS NON USAGE), they locate the first volume of the cluster and obtain the DSCB of the base data component so that it can do proper date processing for the entire cluster.
• If Archive selects a multi-volume cluster from a volume, all components of the cluster on that volume are backed up and recorded in the Archive Control File. However, Archive does not delete that cluster until it has been Archived from all its volumes. It is a requirement that the cluster must be Archived from all of its volumes in the same ABR Archive Backup step; otherwise ABR cannot tell when all pieces of the cluster have been processed (SELECT CATDSN= is a way to insure that all volumes are processed by ABR). RECALL=YES is supported for multi-volume clusters; when it is finally deleted by ABR, it is recataloged as a multi-volume non-VSAM data set with the ABR RECALL indicators.
• Superscratch (DUMP TYPE=SCR) deletes a multi-volume cluster from all of its volumes if any component meets the selection criteria on any processed volume.
• If you have backed up a multi-volume cluster and wish to restore it, and the cluster still exists on DASD, you can simply restore back on top of it without deleting it, just as you can for single-volume clusters. However, the cluster must be in essentially the same state it was in when backed up; it must not have expanded to new extents, and must not have been deleted and redefined. FDR simply overlays the extents of the cluster, and update the VVDS information appropriately. You must be sure that each piece of the cluster is restored back to the volume it was dumped from; this is automatic with ABR and under user control with DSF. Rules for restoring multi-volume clusters are explained later in this chapter.
• If the cluster has been deleted from DASD (or you are restoring or copying to a new name), it is not possible for you to preallocate multi-volume VSAM components in a way which is acceptable to FDR. Let FDR allocate the multi-volume cluster.
• For program FDRABRUT (Remote Queue) to support multi-volume VSAM clusters for the BACKUP or ARCHIVE commands, the DISKUPDATE=NO option must be enabled, causing the remote queue data set to be used.

Allocating multi-volume VSAM

In most cases of multi-volume clusters, including those with multi-volume components, FDR can allocate and catalog the cluster if it does not exist on the output DASD, with these special considerations:

• A restore or copy/move is still a volume-by-volume operation. FDR processes one backup data set or one input DASD at a time, and attempts to allocate and restore only the components or parts of components on that backup or DASD. However, FDR recognizes that the cluster is multi-volume and uses a unique technique for allocating those components. If the multi-volume cluster must be allocated by FDR, the volumes must be done one at a time; you can process all of the volumes in one job or job step, but you cannot run multiple restore jobs to restore in parallel. It does not matter what order the volumes of a multi-volume cluster are processed in.
• As it proceeds, the components on each output DASD are accurately allocated and restored as VSAM. However, until the final volume of the cluster is restored, the cluster is cataloged as non-VSAM, with special indicators in the catalog entry. Once that last volume is processed, the cluster is recataloged properly as VSAM. Therefore, the cluster is not usable in any way until all pieces are successfully restored.
• If you display the catalog entry of a multi-volume cluster before FDR completes that last volume (for example, with LISTCAT), it appears as non-VSAM. The first volume serial is ####Vx where “x” indicates the type of cluster; the other volume serial numbers are the volumes where FDR has completed the restore. If you see this type of catalog entry, it is not abnormal, but simply means that there are more pieces of this cluster which must be restored or copied before it is usable. Another indication of multi-volume allocation status is the FDR311 message printed when FDR restores data sets; for a multi-volume VSAM cluster, that message says ALLOCATED but not CATALOGED until the last volume of the cluster is processed (if multiple components exist on that last volume, only the last component says CATALOGED). Once CATALOGED appears, the cluster is usable.
• When allocating a cluster with multi-volume components, FDR must be able to allocate those components on the same number of volumes they originally occupied. If an output volume cannot be selected that does not already contain a part of the component, the operation fails (but it can be rerun if another output volume can be provided). The rules for selection of output volumes depend on the program you are executing (FDRDSF, FDRCOPY, or FDRABR) and are detailed in “Target DASD Volume Selection Rules” in Section 20.8, “Target Volume Selection” in Section 21.1, and Section 50.8 “Data Set RESTORE Statement” / Section 51.8 “Archive RESTORE Statement” respectively. Providing a sufficient choice of volumes may be a matter of restoring to the original volumes, providing proper DD statements, providing an NVOL= operand, or setting up the ABR RESTORE ALLOCATION LIST to define volume pools. If the rules provide a choice of volumes, the allocation of a component or partial component may be tried on a number of volumes until one is found where it is successful.
• FDR cannot allocate an alternate index (AIX) which is itself on multiple volumes. However, the base cluster is restored and the alternate index can be redefined and rebuilt with an IDCAMS BLDINDEX if necessary.
• Even a single-volume AIX cannot be allocated unless the base cluster has been previously restored or defined, or unless the backup of the volume containing the AIX also contains the LAST piece of the base cluster to be restored. If you are doing an FDRDSF restore of a cluster with one or more AIXs on separate volumes, you must either arrange the restore so that the AIX volumes are restored after the volume containing the base cluster components, or re-restore the volumes containing the failed AIXs. ABR restores (including restores from volume backups, archive backups, and application (FDRAPPL) backups), automatically re-restore any AIXs that failed because their base cluster was not completely restored during the first restore attempt.
• Each output volume chosen by FDR must have sufficient free space to hold all the space allocated to the cluster on the equivalent input volume. For example, if the data component of a cluster had 500 cylinders on each of 3 volumes, and an index component of 10 cylinders on one volume, the cluster must be restored to 3 volumes with at least 500 cylinders of free space each, plus a volume with room for the 10 cylinder index (that could be one of the data volumes). If a chosen output volume does not have sufficient free space, FDR chooses another output volume until it is successful or all possible output volumes have been tried. If possible, a single extent is allocated on each volume to hold the extents from the input volume, but if the output volume is fragmented, multiple extents may be allocated.

Recovery from restore errors

Please read this carefully! FDR may successfully complete the restore of part of a multi-volume cluster from one or more input volumes, and then fail during the restore from another input volume; common causes include an insufficient number of output volumes and lack of free space on the output volumes.

When a restore error occurs on a multi-volume cluster, FDR cleans up the pieces it tried to restore on the current output volume but does not clean up the pieces of the cluster that were previously restored. They are left on their volumes and the special non-VSAM catalog entry is left.

If it is possible to correct the error, such as by choosing a new output volume with sufficient free space, you can restart the restore but you must re-restore only from the input volume that caused the failure. If the failure occurred on multiple input volumes, re-restore all of them.

However, if you want to re-restore the entire cluster from all volumes, you must manually cleanup the partially restored cluster before attempting the entire restore again. If you do not do this, various errors can occur.

To delete the non-VSAM left in the catalog, use the IDCAMS command:

DELETE clustername NONVSAM NOSCRATCH

To delete the components or partial components that were successfully restored, use the IDCAMS command:

DELETE componentname VVR FILE(DD1) CAT(catalogname)

This must be executed against each component on each volume where the restore was successful. The FDR311 messages in the restore listing show you which components were restored to which volumes. For a KSDS and VRRDS, part of the index component may have been restored to the same volume as part of the data component; you must issue two DELETE VVR commands to delete both components.

See the IBM Access Method Services manual for details and examples for these DELETE commands.

Restoring multi-volume VSAM

To restore a multi-volume VSAM cluster with FDRDSF, supply a TAPEx DD statement for the backup of each volume where the data set resided, and code one SELECT statement specifying the cluster name. Output volumes can be specified by DISKx DD statements or by NVOL= operands; if neither is specified, DSF restores back to the original volumes or, if the cluster currently exists on DASD, to the volumes in the catalog.

Multi-volume clusters can be copied with FDRCOPY, but not moved with FDRCOPY. Since FDRCOPY processes one input volume at a time, and the original cluster still exists, the special allocation techniques just described do not work unless a new name is given. So COPY requires a new name, which should be specified using the NEWGROUP= or NEWINDEX= operands (not NEWNAME=). If necessary, when the copy is complete, the original cluster can be deleted and the new cluster (and all of its components) can be renamed with an IDCAMS ALTER; however, it is easier to dump and restore the cluster with FDRDSF. This is an example of copying a two-volume cluster, using CATDSN= to select the input DASD volumes and using NVOL= to specify the output:

//COPY EXEC PGM=FDRCOPY,REGION=0M //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSIN DD * COPY TYPE=DSF SELECT CATDSN=MULTI.VOLUME.CLUSTER, NEWI=.+NEW,NVOL=(TEST01,TEST02) /*

For both FDRDSF and FDRCOPY, the volumes of the multi-volume cluster can be processed in one-step or in multiple steps, and in any order. However, the cluster is not usable until all volumes have been processed.

For restore from any type of ABR backup, simply provide one SELECT statement specifying the base cluster name, for example,

SELECT DSN=cluster

or a generic selection mask that selects the clusters desired.

If the cluster still exists on DASD, ABR locates all volumes it exists on, and restores the contents of each component on all volumes. If the cluster does not exist, ABR defaults to restoring to its original volumes unless you override with the NVOL= operand.

Multi-volume clusters cannot be restored or copied/moved to an unlike device type, for example, 3390 clusters can only be output to 3390s. FDRREORG, IDCAMS, or other utilities must be used if you must move multi-volume clusters to new device types.