FDRCOPY introduction

In most respects, FDRCOPY is similar to a DUMP with FDRDSF followed by a RESTORE, except that no backup file is involved and input and output I/O are done concurrently.

FDRCOPY can copy or move individual data sets, groups of data sets, or all of the data sets on a volume. Data sets can be selected or excluded by DSORG. Absolute tracks addresses can also be copied. Data sets can be copied or moved to the same name or to a new name. An unlimited number of data sets can be copied or moved in one execution. Data sets may be copied or moved from any number of input DASD volumes, and output data sets may be directed to any number of output DASD volumes. The output volume may be a different device type from the input DASD volume.

PDS reorganization

FDRCOPY can reorganize Partitioned Data Sets (PDSs) in place, compressing all active members to the beginning of the PDS to allow room for new members to be added. This is similar to an IEBCOPY compress-in-place, but FDRCOPY is 50% to 90% faster than an equivalent IEBCOPY, with similar reductions in CPU and I/O resources. FDRCOPY is capable of reorganizing many PDSs on one or many volumes in one step, with just a few simple control statements. PDSs to be processed may be selected from specified volumes or selected from system catalogs, using all of the selection criteria of FDRCOPY (except that only DSORG=PO data sets are selected).

FDRCOPY PDS REORG may be automatically invoked to process IEBCOPY compress-in-place operations without any changes to the JCL and control statements for IEBCOPY (see IEBCOPY in Operating System Exit Options for FDRABR and FDRREORG).

PDS reorganization is requested by the REORG statement, as described in Working-with-FDRREORG. However, the REORG function is enabled only if your installation is licensed for FDRREORG, a separately-priced component of FDR.

FDRCOPY also supports simulation of PDS reorganization, via the SIMREORG control statement. SIMREORG must still read the PDSs but only simulates rewriting the data, reporting on the number of tracks that are reclaimed by a real REORG.

FDRREORG (see Working-with-FDRREORG) reorganizes VSAM data sets, Innovation Access Method (IAM) data sets, and PDSs, using FDRCOPY internally for the PDS reorganization. If you execute PDS reorganization through FDRREORG, it enhances the reorganization process by providing additional selection criteria and retrying unavailable data sets, among others. However, these enhancements may add additional overhead; executing FDRCOPY REORG directly provides the fastest PDS reorganization.

Specifying data sets to be copied or moved

FDRCOPY copies or moves user-specified data sets from one or more input DASD volumes to one or more output DASD volumes. The data sets to be processed can be specified by individual name. Groups of data sets may be selected using a generic data set name filter, or the ALLDSN operand may be used to copy or move all of the data sets on a volume. The data sets may be selected by scanning the VTOCs of volumes specified by the user, or data sets may be selected from system catalogs. Data sets can be selected or excluded by DSORG.

By default, data sets are copied or moved under their original name, but you can cause the output data sets to get a new name. COPY usually uses a new name (so that both the original and copied data set can be cataloged) while MOVE usually uses the original name. For a COPY of a VSAM cluster, the output data set either must have a different name or be cataloged in a different catalog; on a VSAM MOVE the output data set usually has the original name.

Data set COPY and MOVE

During a COPY or MOVE:

The data tracks of the selected data sets may be copied 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 its extent count.
Data sets and clusters may be renamed during the COPY or MOVE.
A target output volume is selected for each data set being copied. If you are copying to a new name, this is the input volume by default, but you can override the target. Target volume selection rules are detailed in Target Volume Selection.
If an output data set (either the original data set name or the new name) already exists on its target volume and is large enough, FDRCOPY replaces the contents of the existing data set and update its describing information (VTOC and VVDS information). However, if you specify the PRESTAGE operand, FDRCOPY bypasses the copy of a preexisting data set.
If an output data set does not exist on its target volume, FDRCOPY allocates it, automatically making it large enough to hold the contents of the input data set. Usually FDRCOPY catalogs the output data set at the end of the copy (if the output data set is already cataloged to other than the input volume, FDRCOPY 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.
FDRCOPY usually copies data sets to the same device type they were backed up from (for example, from 3390 to 3390). This is called a like device or physical copy. 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 copy, the original data tracks of the selected data sets are copied exactly as they were backed up (but there is an option to re-block certain data set types). FDRCOPY allocates an output data set of the same size as each input data set, unless you override the size with various operands.

Output data sets may be directed to various output DASD volumes. Data sets from one input volume can be copied to many output DASD volumes concurrently. The input and output volumes can be identified by JCL or by FDRCOPY control statements. You can also identify a list or group of volumes as the target volume; FDRCOPY finds one with sufficient space for the data set. However, a single volume data set must be copied to a single volume. By default, FDRCOPY processes one input volume at a time, but you can specify MAXTASKS=n (1-5) to process up to five input volumes concurrently. MAXTASKS= greater than one requires that data sets be selected using the CATDSN= operand for proper handling of data set enqueues.

Multi-volume data sets can be copied, but only to the same number of volumes they currently occupy when dumped. Multi-volume VSAM is handled, but only when copied to the same device type with a physical copy. One exception: if a cluster is multi-volume because it has a data component on one volume and an index component on another volume, both components can be copied to one volume.

At the end of the copy from each input volume, FDRCOPY updates the DSCB of each output data set and, for VSAM and SMS-managed data sets, its VVDS entry, so that they properly describe the data that was copied. If a copy is interrupted or canceled, this update is not done and the data sets are probably unusable even though all data tracks were copied.

If FDRCOPY allocated an output data set and the copy 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.

Target volume selection

While processing the data sets selected from a given input DASD volume, FDRCOPY can copy/move them to one or more DASD volumes concurrently. The target DASD volume is selected for each data set by the following rules:

If the NVOL= operand is specified on the SELECT statement that selected the data set, that volume or volumes are used. See the description of “NVOL=” in Section 21.5 for details of target volume selection.
If the input volume being processed is specified by a DISKx DD statement in the FDRCOPY JCL and there is a matching TAPEx DD statement pointing to a DASD volume, then the DASD to which it points is selected for output.
If you are copying or moving a data set to a new name, and the output data set name is cataloged, then the volume to which it is cataloged is chosen. If the data set is cataloged as being on multiple volume serials, then the volume serial number is selected from that list based on the volume sequence number in the F1 DSCB (field DS1VOLSQ) of the input data set. When copying or moving a data set under its original name, FDRCOPY does not check if the data set is cataloged to another volume.
If none of the above applies, the data set is copied or moved to the input volume. However, any attempt to copy or move a data set back on top of itself is rejected.

Important

Ensure that the target volume specified is correct to prevent accidentally overlaying a current cataloged data set with a copy of an uncataloged data set with the same name. Using the NVOL= keyword is the best way to specify a specific volume to move or copy a data set.

If System Managed Storage (SMS) is active on this system, and the data set does not already exist on the volume selected by the rules above, SMS is invoked to decide if the data set should be SMS-managed. If so, SMS selects an output volume. SMS rules are detailed in SMS Support.

Cataloging Non-VSAM output data sets

When copying or moving single-volume, non-VSAM data sets:

On a COPY, if FDRCOPY allocates space for the output data set, then the default is that FDRCOPY catalogs the data set to the output volume, unless the data set was already cataloged. (For a copy to the original name, if the input data set is cataloged, the output data set is not cataloged).
On a MOVE, the default is that if FDRCOPY allocates space for the output data set, then FDRCOPY catalogs the data set to the output volume unless the data set was cataloged to a volume other than the input volume before the operation. (For a move to the original name, if the input data set is cataloged to the input volume, it is recataloged to the output volume).
If the RECAT operand is specified, it always 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 copied data set
If the NOCAT operand is specified, then FDRCOPY does not catalog the newly allocated data set. This is ignored for SMS-managed data sets that must always be cataloged.
Cataloging or recataloging of non-VSAM data sets occurs at the end of the copy/move, and is bypassed if any errors have occurred for a given data set
If the output data set exists on DASD before the restore, then FDRCOPY does not update the catalog, unless the CATIFALLOC operand is specified. CATIFALLOC causes FDRCOPY to apply the same rules described above for data sets allocated by FDRCOPY.
In the cases where FDRCOPY 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 COPY or MOVE 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 FDRCOPY job, to insure that all data tracks are copied, but the output data sets are already allocated so FDRCOPY 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 (for example, MOVE or COPY to a new name), FDRCOPY 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 FDRCOPY 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 COPY without RECAT, FDRCOPY 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.
So, when doing a MOVE, or a COPY with RECAT, of a cataloged multi-volume data set to the same name, the resulting data set and catalog entry is usable and correct, whether the data set is moved from one, some, or all of its original volumes. When doing a MOVE or COPY of a cataloged multi-volume data set to a new name, it is necessary to move or copy the data set from all of its volumes to get a usable data set and catalog entry. If a multi-volume data set is being moved or copied to a new device type, it is not usable until all pieces are on the same device type. If you do not copy one or more pieces of the data set, the catalog entry is inaccurate and the data set is not usable (it may contain ####nn or original volume serial numbers). It is your responsibility to insure that the data set is copied from all the volumes it occupies; luckily, this is easy with the CATDSN= operand, selecting data sets from the catalog.
If you do a MOVE of a multi-volume non-VSAM data set to a new name, FDRCOPY does not uncatalog the original data set, although it scratches the pieces from DASD. You need to uncatalog it manually after the MOVE successfully completes.

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 copied may already be cataloged to other than the input volume; if so, specify RECAT if you want the newly copied data set to be the cataloged data set. 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).

SMS-managed data sets are always cataloged, so a copy/move to an SMS-managed data set requiring allocation will fail if the data set cannot be cataloged. When moving SMS-managed data sets they are automatically recataloged to the new volume, but for a copy to a new name that already exists somewhere, RECAT may be required. NOCAT is ignored for SMS-managed data sets.

Deleting the input data set

At the end of a MOVE operation, the input data sets are deleted. Deletion is bypassed for a given data set if any errors have occurred for that data set

For a multi-volume data set, only the portion on the current input volume is deleted. Portions on other volumes remain on DASD, unless they are also moved.

If you MOVE a non-VSAM data set to a new name (by specifying NEWN=, NEWG=, or NEWI=), the input data set is uncataloged if it is a single-volume data set. MOVE to a new name does not uncatalog multi-volume input data sets. A MOVE to the original name simply updates the catalog to point to the new location.

FDRCOPY does not delete multi-volume VSAM data sets. It also does not delete VSAM clusters that are not properly cataloged or not cataloged at all.

On a COPY operation, the input data set remains on DASD (although the catalog is updated to point to the output data set, if the RECAT operand is specified and the output data set has the same name).

Absolute track address option

If the user specifies physical track starting and ending addresses in decimal, FDRCOPY copies the requested physical segment from the input volume to the same physical location on the output volume. This operation does not update the VTOC on the output volume to reflect the data sets that have been affected.

A MOVE operation for absolute track addresses is treated as a COPY. Since the operation is not associated with a data set, there is no input data set to delete.

Extreme caution should be used when copying tracks within the VTOC, VTOC index, or VVDS, or the volume label track, since an error may make data sets or the entire volume unusable.

VSAM support

FDRCOPY supports VSAM files using the base cluster name. FDRCOPY copies or moves all of the components associated with the cluster on a volume, including Alternate Indexes (AIXs) and key ranges. In addition, FDRCOPY copies or moves the VVR information found in the VVDS. A VSAM cluster can be selected by individual name or as part of a data set group, or is included when the ALLDSN operand is used to copy or move all of the data sets on a volume. If the output cluster does not exist on DASD before the copy or move, then FDRCOPY allocates space for it by invoking SVC 26 to do a DEFINE.

When FDRCOPY does a DEFINE for VSAM, some of the information that exists only in the catalog is copied from the input cluster, including expiration date, owner ID, passwords, and other VSAM security fields. If the input cluster has candidate volumes, they are copied to the output cluster only if the input cluster does not currently have data on multiple volumes. The creation date is copied on a MOVE operation; on a COPY operation the creation date of the output cluster is the run date. If the input cluster is protected by a discrete RACF profile, then the output cluster is also protected by a discrete RACF profile, which is created by using the profile of the input cluster as a MODEL. If the input profile name does not actually exist, the output cluster is created with no discrete profile. Path names for Alternate Indexes (AIXs) are copied or moved.

For VSAM, all data sets must be cataloged; the NOCAT, RECAT, and CATIFALLOC operands are ignored.

FDRCOPY copies track by track; the cluster is not reorganized.

See VSAM-Special-Considerations.

VSAM – MOVE

A MOVE operation for a VSAM cluster can use either the same name or a new name. On a MOVE to the original name, FDRCOPY defines the output cluster with temporary cluster and component names as defined by the TTIME=operand. By default, it inserts an index level of “.Txxxx”, where “xxxx” is a time-stamp consisting of four hexadecimal digits. “.Txxxx” is inserted as the next-to-last index level of the temporary name for the output cluster and for each of its components. If the original name is longer than 38 characters, characters are removed from the original name as necessary, preceding the point of insertion. If these temporary names would violate your installation naming standards, use the TTIME= operand to change the temporary name.

FDRCOPY deletes the input cluster at the end of a MOVE if no errors have been encountered. If the MOVE was to the original name, FDRCOPY then alters the names of the output cluster and its components back to the original names.

If errors are encountered during a MOVE, before the input cluster is deleted, FDRCOPY attempts to DELETE the output cluster; if it is successful, no action is required, and the input cluster is unchanged. If it fails, then both the input cluster and the output cluster remain on DASD and you need to manually clean them up:

If the MOVE was to the original name, then the output cluster has the temporary name. If the move is re-attempted, a new output cluster is created with a different time-stamp in its temporary name. After the earlier output cluster is no longer needed for investigation of the error, you should DELETE it with IDCAMS.
If the MOVE was to a new name, then the output cluster will have the new name. If the MOVE is re-attempted, FDRCOPY will find and reuse the earlier output cluster.
If errors are encountered during a MOVE, while the input cluster is being deleted, then the input cluster may or may not still be on DASD, as indicated by the error codes, and the output cluster is on DASD. If the MOVE was to the original name, then the output cluster will have the temporary name. You can use IDCAMS DELETE and ALTER to clean up this condition.

If errors are encountered during a MOVE to the original name, while the output cluster is being renamed, then the input cluster is gone, and the output cluster remains on DASD; some parts of the output cluster may have been renamed to the original name. You can use IDCAMS ALTER to clean up this condition.

A MOVE of a multi-volume VSAM cluster is not supported. A MOVE of a KSDS with the “keyranges” attribute, even though they are on the same volume as the base cluster, can only be done to a new name. Multi-volume VSAM can be moved by dumping all components with DSF, deleting the cluster, and restoring to new volumes (see Working-with-FDRDSF).

VSAM – COPY

A COPY operation for a VSAM cluster must always specify either a new name for the output cluster and all its components, or a different catalog (ICFCAT=). The reason is that all VSAM files are cataloged as soon as they are created, and there cannot be two catalog entries for the same cluster name in the same catalog.

A COPY of a multi-volume VSAM cluster is supported in most cases. See Multi-Volume VSAM Considerations in VSAM-Special-Considerations.

VSAM – New names

For a VSAM COPY/MOVE to a new name, it is recommended that you use the NEWGROUP= or NEWINDEX= operands to rename the cluster; the changes specified are made to the output cluster name, all its component names, and any alternate index (AIX) cluster names. For a cluster with no AIXs, you can specify NEWNAME=; the cluster is renamed and IBM defaults are used to name the components (which usually involves adding “.DATA” or “.INDEX” to the cluster name).

VSAM catalogs and VVDSs cannot be copied to a NEWNAME.

Catalog

FDRCOPY cannot copy or move a VSAM catalog (BCS), because a catalog cannot be copied or moved to a new name, even temporarily. You can move a catalog by dumping it with DSF, deleting the old catalog with the IDCAMS command “DELETE catname RECOVERY”, and restoring the catalog to the new volume (see Working-with-FDRDSF for information on using DSF).

VVDS

FDRCOPY cannot copy or move a VVDS (VSAM Volume Data Set, SYS1.VVDS.Vvolser) as an entity. Instead, FDRCOPY updates the VVDS on the output volume to reflect the attributes of the clusters that have been copied or moved.

SMS Support

On a system with IBM’s System Managed Storage (SMS) active, FDRCOPY supports copying and moving SMS-managed data sets, and conversion of non SMS-managed data sets to SMS management and back again.

When processing input data sets that are SMS-managed, FDRCOPY will extract 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.

When output data sets must be allocated on a SMS system, SMS is invoked for every such data set, 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=storclas, NULLSTORCLAS, MGMTCLAS=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 is not SMS-managed, a null class is passed).
The 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, FDRCOPY allocates the data set on a non SMS-managed volume (a target non SMS-managed volume must be indicated by a TAPEx DD statement or a NVOL= operand on the SELECT statement). Even if data sets are allocated by SMS on a number of different volumes, FDRCOPY outputs those data sets in one pass of the input volume.

So, FDRCOPY 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 output 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 if the NULLSTORCLAS operand is specified. FDRCOPY can also be used to move SMS-managed data sets to new volumes if the SMS storage groups are redefined.

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 placed, by use of the BYPASSACS and BYPASSSMS operands on the COPY/MOVE statement.

More detail on SMS Support is in Working-with-System-Managed-Storage.

Processing specific types of data sets

Details of 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 FDRCOPY to automatically use the hardware features of certain DASD subsystems to move data tracks from one volume to another without the channel overhead of sending the data to and from the CPU. This currently works on EMC VMAX systems with the TimeFinder and SnapShot features and IBM and Hitachi Vantara systems with the FlashCopy feature. When FDRCOPY detects that the input and output DASD volumes for any data set are in the same DASD subsystem, and that subsystem is enabled one of the supported hardware features, it is automatically used. The elapsed time of the COPY or MOVE is significantly reduced. FDRINSTANT is described in:

FDRINSTANT also enhances FDRCOPY to provide the ability to take copy data sets 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 at that point-in-time. FDRINSTANT can then read the offline DASD and create the required backups or copies, without relabeling the DASD or bringing it online. FDRINSTANT for various hardware platforms is described in: