FlashCopy for FDR/FDRDSF/FDRCOPY

To create the FlashCopy copies of the volumes to be processed by FDR, FDRDSF, or FDRCOPY, you must first execute program FDRFLASH with JCL similar to:

In the FCOPY step, one or more MOUNT statements must be provided to identify each online source volume to be copied (VOL=) and the target device (FLASHUNIT=) to which to copy it. There must be one MOUNT statement for each volume to be copied and the FLASHUNIT= value must be unique for each source volume. The online volume identified by VOL= and the target volume identified by FLASHUNIT= must be in the same subsystem and the target must be offline to the operating system. To insure that the copied volume is not accidentally brought online, FDRFLASH modifies the volume label in a way that FDR can access it but any attempt to bring it online (VARY command or IPL) fails.

FDRFLASH initiates a full-volume FlashCopy NOCOPY session for each selected online volume and offline target. If a FlashCopy session already exists between those two volumes, it is terminated before the new session is started.

FDRFLASH can also initiate a FlashCopy COPY session by adding the operand FCOPY=COPY or FCOPY=INCR to the FCOPY statement.

Ideally, you would quiesce any updates to the source volumes during the FCOPY, to insure that you can get a clean, restorable backup of every data set on the volumes. Once the FDRFLASH step ends (usually within a few seconds), the data has been copied and normal access to the source volumes can be resumed.

FDRFLASH does the same security checks as an FDR full-volume backup (see Security).

If you like, you can specify the DSNENQ= operand to check if data sets are active when copied. FDRFLASH defaults to ENQ=RESERVE to protect the VTOC during the brief FCOPY operation, but you can override it if desired. See DSNENQ= and ENQ= in FDR-Processing-Options-and-Requirements.

FCOPY supports one additional operand. VERIFYVOLSER=YES verifies that each FLASHUNIT target volume currently has the same volume serial as the corresponding online source volume. This is true if the last use of the target was for a FCOPY of this source volume, or if you have used ICKDSF to initialize the target volume. You may need to omit VERIFYVOLSER=YES on the first FCOPY since the VOLSER may not match. VERIFYVOLSER=YES is used to verify that you are not accidentally overlaying a target volume used with another source volume.

The actual backups of the offline point-in-time copies can now be taken with FDRINSTANT using:

• FDR full volume backup.
• FDRDSF data set backup.
• FDRCOPY input DASD volumes for COPY operations only.

You can also use FDRINSTANT for FDR full-volume copies (COPY TYPE=FDR) but in most cases it would be more useful to copy the online volume directly.

FDRCOPY MOVE operations from a point-in-time copy are not supported by FDRINSTANT since it deletes the input data set. Always move the live, online version of a data set.

FDRINSTANT uses standard FDR JCL and control statements with one modification. For complete details on other JCL and control statement requirements of FDR, FDRDSF, and FDRCOPY, please see:

• FDR-Fast-Dump-Restore
• FDRDSF-Data-Set-Functions
• FDRCOPY-Copy-or-Move-Data-Sets

of the FDR manual, respectively. DISKx DD statements in FDRINSTANT steps must specify the original online DASD volume, just as if you were backing it up directly.

To invoke FDRINSTANT you must add the FCOPY= operand to the DUMP or COPY statement. FCOPY= has the following forms:

Tells FDRINSTANT to read the offline copy of the online volume specified in JCL. FDR remembers the device address of the offline device most recently used as a target for a FlashCopy of each online volume unless an intervening IPL has occurred. This works only if the DUMP or COPY is run on the same system where the FCOPY was run. At the end of the backup, the FlashCopy session is left active so that additional backups may be done from the point-in-time target if desired.

Same as FCOPY=USE, but at the end of backing up each volume, FDR issues a request to the subsystem to terminate (withdraw) the FlashCopy session. Do not use REL if you wish to retain an Incremental FlashCopy session or when using FDRCOPY.

FCOPY=COPY|NOCOPY

FDRINSTANT by default establishes the FlashCopy relationship using FCOPY=NOCOPY that creates a point-in-time image without the overhead of copying all of the unmodified source tracks to the offline target volume. If the requirement exists that the offline target must contain all of the source tracks, then use FCOPY=COPY to override the default.

Specified on the FCOPY= main control card to create an Incremental point-in-time image on the offline target. FCOPY=INCR automatically forces FCOPY=COPY on the initial establish.

Specified on the FCOPY= main control card to perform a Fast Recovery Restore (FRR) of the online source volume if both of the volumes are the same device size. The offline volume is no longer a valid backup after the completion of the restore.

Other considerations for FDR control statements with FDRINSTANT:

• Since FDRINSTANT is not reading the live data, it is never appropriate to use the ENQ= or DSNENQ= operands to enqueue on the VTOC of the FlashCopy target or the data sets on the target. To do so would unnecessarily prevent access to the live data on the online volume.
• For FDRCOPY, specify DSNENQ=NONE. If you use CATDSN= to select data sets to be copied, you must make sure that all of the input volumes that are selected from the catalog have been copied by a preceding FDRFLASH step.
• Do not use the FDRCOPY MOVE statement when the input is a FlashCopy target. If you do so, the live data sets on the online volume are deleted at the end of the move.

FDRINSTANT operation

1. When ready to backup or copy data, quiesce system and/or application update activity on the online volumes, if required, and execute FDRFLASH for each original-target pair. Once the FDRFLASH step ends, you can re-enable updates on the original volumes.
2. Execute FDR, FDRDSF, or FDRCOPY with FCOPY=USE or FCOPY=(USE,REL) against each of the online volumes. The offline copy is read.

Multiple systems

FDRINSTANT requires that both the original volume and its offline copy be accessible from the operating system where the backup is run. If you execute the FCOPY on one system, but execute the backup on a second operating system that does NOT have access to the online volume, FDRINSTANT fails. There is a circumvention for FDR and FDRDSF, but you must contact BMC Support for assistance in implementing it.

FDRCOPY and Metro Mirror interaction

The use of FlashCopy to a Metro Mirror primary volume causes the Metro Mirror link to enter “Pending” state; the secondary volume is considered inconsistent. The length of this inconsistent exposure is dependent on the data transmission time. HyperSwap is disabled when any pair goes into duplex pending state.

FDRINSTANT supports the use of FlashCopy Preserve Mirror (Remote Pair FlashCopy). Preserve Mirror FlashCopy prevents the exposure of the Metro Mirror entering “pending” state by performing FlashCopy operations on both the local and remote sites.

Preserve Mirror FlashCopy is invoked by specifying the “REMOTEINSTANT=” operand on the main control statement.

An attempt is made to use FlashCopy with Preserve Mirror. If the attempt is not successful, the operation continues and REMOTEINSTANT= is ignored. FlashCopy is used and the Metro Mirror relationship may enter a “pending” state.

vIn a multi-target configuration, “PREFERRED” is not allowed due to an IBM restriction.

vIBM APAR OA49581 (last changed 18/11/20)

DFSMS documentation clarifications with new generation of DS8000 control unit (DS888X) ADR935W 00001E19-08040

The new generation of DS8000 control unit (DS888X) NO LONGER supports FCTOPPRCP(PMP): (Preferred)

An attempt is made to use FlashCopy with Preserve Mirror. If the attempt is not successful, the FlashCopy operation is terminated. If the operation is FDRCOPY, normal I/O is performed to move/copy the data.

FDRINSTANT also supports Remote FlashCopy (Inband FlashCopy), when creating the FlashCopy copy of the volumes to be processed by FDR, FDRDSF, or FDRCOPY.

Remote FlashCopy can be used when the primary volume is in a Metro Mirror (PPRC) relationship, and it is desirable to create the FlashCopy copy from the Metro Mirror secondary volume. To request Remote FlashCopy, specify REMOTEINSTANT=INBAND on the FCOPY or CONFCOPY statement under FDRFLASH.

Remote FlashCopy is invoked to establish a FlashCopy relationship between the Remote Metro Mirror / PPRC secondary unit and a remote tertiary device. The Remote Tertiary device is specified by using either the FLASHUNIT= or LSSCCA= parameters.

vMetro Mirror / PPRC secondary units must be in duplex status and tertiary remote units must be in simplex state.

vIf the source volume is not the primary volume in a duplexed Metro Mirror relationship, the REMOTEINSTANT= operand is ignored.

vREMOTEINSTANT=INBAND is supported in FlashCopy / Metro Mirror environments only.

Used in conjunction with the REMOTEINSTANT=INBAND operand to specify the remote units.

uuuu

The remote tertiary device number.

lsca

Used in conjunction with the REMOTEINSTANT=INBAND operand when addressability is not available to the remote units. In this case, FDRFLASH must be used with the LSSCCA= operand to specify the remote units.

vls is the Logical Subsystem (LSS).

vca is the Channel Connector Address (CCA).

FDRCOPY Between PPRC / MetroMirror primary volumes retaining HyperSwap capability example

FDRCOPY can copy or move data sets between PPRC/MM primary volumes retaining the HyperSwap capability of the MetroMirror relationship. HyperSwap is disabled when a PPRC/MM relationship enters the duplex pending state.

FDRINSTANT FDRCOPY supports the use of Remote Pair FlashCopy (Preserve Mirror), which invokes FlashCopy at the remote site to copy/move the data between the PPRC/MM Secondary volumes. The use of the REMOTEINSTANT= operand provides FDRCOPY with the Remote Pair / Preserve Mirror control options.

This example copies a data set between two PPRC/MM Primary volumes and renames the prefix to “PLOUS”.

Environment

Output

FDRINSTANT FDR Examples

These are examples of FDRINSTANT FDR, FDRDSF, and FDRCOPY usage with FlashCopy.

A STEPLIB DD statement may be required in FDRINSTANT steps if you have installed the product in a library other than your standard FDR program library.

If you are also licensed for FDRCRYPT, these backups can be encrypted. For more information, see FDRCRYPT-Backup-Encryption for details of the job changes required.

FDR full volume backup example

The FlashCopy target volume at address 01FA has been permanently assigned to online volume “PROD01”. The step FCOPY starts a FlashCopy session from online volume PROD01 to offline target 01FA. VERIFYVOLSER=YES verifies that 01FA already contains VOLSER PROD01; you may need to omit this the first time that you FCOPY to that target. Step BACKUP backs up the offline copy of volume PROD01. After the backup is complete, FDR terminates the FlashCopy session.

The output from the backup step looks something like this (the FDR219 message confirms that the offline copy was actually backed up):

The backup created by this example is a normal FDR full-volume backup. There are no special considerations for restoring the entire DASD volume or individual data sets from it. For example:

FDR full volume restore from instant image example

The FlashCopy target volume at address 01FA has been permanently assigned to online volume “PROD01”. The step FCOPY starts a FlashCopy session from online volume PROD01 to offline target 01FA. VERIFYVOLSER=YES verifies that 01FA already contains VOLSER PROD01; you may need to omit this the first time that you FCOPY to that target. Step RESTORE initiates a disk to disk copy from the offline image created by the FCOPY step, to the online PROD01 volume.

FDR full volume backup with incremental FlashCopy example

This example is a variation of the FDR full volume backup example, but instead is used for incremental backup.

The output from the FCOPY step looks something like this:

The output from the backup step looks something like this (the FDR219 message confirms that the offline copy was actually backed up):

The backup created by this example is a normal FDR full-volume backup. There are no special considerations for restoring the entire DASD volume or individual data sets from it.

The Incremental backup is also retained, therefore, a FRR restore can be requested through PGM=FDRFLASH if both of the volumes are the same device size. For example:

The output from the FCOPY=FRR restore step looks something like this:

FDRDSF data set backup example

The FlashCopy target volumes at addresses 01F2 and 01F3 are assigned to online volumes CICS01 and CICS02. When ready to execute, updates to the original volumes may need to be quiesced. The step FCOPY starts FlashCopy sessions from the original volumes to the targets; when the step completes, updates to the original volumes can begin again. Step BACKUP backs up the FlashCopy copies of selected data sets on volumes CICS01 and CICS02, processing the two backups in parallel. After the backup is complete, FDR terminates the FlashCopy sessions.

The backups created by this example are normal FDRDSF data set backups. There are no special considerations for restoring data sets from them. For example:

FDRCOPY from a Point-in-Time image example 1

An SMS storage group consists of two volumes, SMS001 and SMS002, that have assigned targets at addresses 01F4 and 01FA. You want to make a copy of data sets on those volumes but you can only quiesce updates for a few moments. The step FCOPY starts FlashCopy sessions for the online volumes to the offline target volumes. Step COPY copies the selected data sets from the copied volumes, renaming the data sets during the copy; the data sets are copied to online volumes chosen by SMS as described in “Target Volume Selection” in Section 21.1. These copies might be used for parallel batch processing.

FDRCOPY from a Point-in-Time Image Example 2

This is the same as the previous example, except that SELECT CATDSN= instead of DISKx DD statements is used to select the input volumes for the cataloged data sets specified. If those selected data sets reside on the volumes that were flashed, FDRCOPY reads the point-in-time flashed copies of the data sets. If any data sets are on volumes that were not flashed, the online versions of the data sets are copied.

FDRCOPY between volumes example

FDRCOPY can copy or move data sets to new volumes, and can rename and/or re-catalog the output data sets. When FDRINSTANT is installed, FDRCOPY is enhanced to automatically recognize that the input and output volumes for a given data set are in the same FlashCopy capable subsystem and automatically invokes FlashCopy hardware to do an instantaneous copy. When the volumes for a given data set are not in the same subsystem, normal read/write is used. This function is automatic, requiring no special operands, so the samples below are normal FDRCOPY jobs. If FlashCopy was used for a given data set, its FDR311 message contains the text “INSTANT”. If the input data is on more than one volume, MAXTASKS=5 allows FDRCOPY to process up to five input volumes concurrently.

This example copies data sets to new names, inserting a second-level index of COPY.

This example moves data sets to new volumes, re-cataloging them to their new location. If the input data is on more than one volume, MAXTASKS=5 allows FDRCOPY to process up to five input volumes concurrently.

This is an example of an output from FDRCOPY when FlashCopy is used to copy the data sets. This example consists of two data sets totaling 45000 tracks (3000 cylinders). Notice that the FDR311 message says INSTANT (meaning that FlashCopy or another instant replication facility was used) and the elapsed time is three (3) seconds.

FDRCOPY flash timings

A test of FDRCOPY MOVE with FlashCopy at BMC on an IBM DS8700 subsystem yielded these results:

600 Linear Data Sets Totaling 2.1GB

Most of the elapsed and TCB time in the chart above, even with FlashCopy, is due to allocating and cataloging the 600 output clusters and deleting the input clusters. As you can see in the following table, when the number of data sets is small, the overhead is also small:

One Linear Data Set Totaling 2.1GB