TimeFinder/Mirror for FDR / FDRDSF / FDRCOPY
FDRINSTANT for TimeFinder/Mirror (BCVs) uses standard FDR, FDRDSF, and FDRCOPY JCL with one modification. The FDR control statements used are standard except for a few considerations. For complete details on other JCL and control statement requirements of FDR, FDRDSF, and FDRCOPY, please see:
of the FDR manual, respectively.
FDRINSTANT uses a special convention for the DISKx DD statements that identify the DASD to be backed up or copied. As shown in the examples below, the DD statement points to the online volume but includes a special data set name which tells FDR the device address of the BCV that is to be read in place of that online volume. FDR verifies that the volume serial of the online volume is the same as that of the offline BCV.
These special DISKx DD statements can be used with:
- FDR full volume backup.
- FDRDSF data set backup.
- FDRCOPY input DASD for COPY operations only. Although FDRCOPY can copy data sets without the use of DISKx DD statements, DISKx DD statements are required to cause FDRCOPY to read the offline BCV. You can still select data sets normally, including selecting them from the catalog, but FDRINSTANT is used for any input volume identified on a special DISKx DD statement.
They can also be used 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. You should always move the live, online version of a data set.
Non-SMS volumes
For non-SMS volumes, a DISKx DD statement identifying the DASD to be backed up would look like this:
//DISKx DD DSN=FDR.USE.UNITuuuu,UNIT=3390, // VOL=SER=vol,DISP=OLD
The UNIT and VOLSER (vol) must identify the online DASD volume.
SMS-managed volumes
For SMS-managed volumes, a DISKx DD statement identifying the DASD to be backed up would look like this:
//DISKx DD DSN=FDR.USE.UNITuuuu,DISP=OLD
Because the operating system ignores a volume serial in the JCL if it points to a SMS-managed volume, the special FDR.USE.UNITuuuu name must be cataloged. This data set does not really have to exist on the original volume, but it must be cataloged to that volume! Just as for a non-SMS volume, its presence on the DD statement is very important. It is this name that directs FDR to access the BCV on the offline device located at device address “uuuu” instead of the original online volume. “uuuu” must be a 4-digit UCB device number; add a leading zero if necessary.
Here is one technique for creating the catalog entry required for FDRINSTANT. This step catalogs the special FDR.USE.UNITuuuu name to an SMS-managed volume. If you have permanently assigned BCVs, this is a one-time operation.
//DEFINE EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DELETE FDR.USE.UNITuuuu NOSCRATCH DEFINE NONVSAM(NAME(FDR.USE.UNITuuuu) – DEVICETYPE(33xx) VOLUME(vol)) /*
The DEVICETYPE and VOLUME parameters identify the SMS-managed online volume. The special FDR.USE.UNITuuuu name directs FDR to access the offline BCV device located at device address “uuuu” instead of the original online SMS-managed online volume.
FDR control statements
The control statements used with FDRINSTANT are the normal statements documented for FDR, FDRDSF, and FDRCOPY with these modifications:
- 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 BCV or the data sets on the BCV. To do so would unnecessarily prevent access to the live data on the online volume.
- For FDRCOPY, specify DSNENQ=NONE. In addition, the input volumes must be specified by DISKx DD statements (to identify the BCV addresses) so you should not select data sets with CATDSN= or VOL=.
- Do not use the FDRCOPY MOVE statement when the input is a BCV. If you do so, the live data sets on the online volume is deleted at the end of the move.
FDRINSTANT BCV operation
1.Execute a one-time EMCTF ESTABLISH for each online BCV pair. There is no need to wait for the synchronization to complete.
2.When ready to backup or copy data, quiesce system and/or application update activity on the online volumes, if required, and execute an EMCTF SPLIT with the WAIT operand for each associated BCV. Once the SPLIT ends, you can re-enable updates on the online volumes.
3.Execute FDR, FDRDSF, or FDRCOPY with the special DISKx DD statements described above to access the BCV.
Multiple systems
FDRINSTANT requires that both the original volume and its offline BCV copy be accessible from the operating system where the backup is run. If you execute the SPLIT 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, see Can I use FDRINSTANT with EMC’s SRDF?
FDRINSTANT for BCV examples
These are examples of FDRINSTANT FDR, FDRDSF, FDRCOPY, and FDRCPK usage with TimeFinder/Mirror BCVs. The examples include steps that execute EMCTF, the TimeFinder utility provided by EMC, but you should consult current EMCTF documentation from EMC to verify the JCL and control statement requirements for that product.
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. See FDRCRYPT-Backup-Encryption for details of the job changes required.
FDR Full Volume BCV Backup Example
The BCV at address 01FA has been assigned to online non-SMS volume “PROD01” at address 01E4; a previous one-time ESTABLISH has been issued to establish that pairing. The step SPLIT splits the BCV from its online volume and waits for the split to complete. Step BACKUP backs up the BCV copy of volume PROD01.
The output from the backup step looks something like this (the FDR219 message confirms that the offline BCV was actually backed up):
FDR219 FDR VOL=PROD01 IS BEING DUMPED FROM OFFLINE UNIT=01FA
FDR007 STARTING TIME OF ACTUAL DUMP -- 14.20.27 -- UNIT=3390-3 ,IN=DISK1 ,OUTPUT=TAPE1
FDR007 ENDING TIME OF ACTUAL DUMP -- 14.20.38 -- UNIT=3390-3 ,IN=DISK1 ,OUTPUT=TAPE1
FDR122 BYTES DSK TRK T BLKS RESTART STIMERS ERRS ACT DSK LOW HGH DEXCP NUMDS
FDR122N 0022053561 000618 000491 0000000 0000000 000 000618 000 000 00100 00010
FDR002 FDR DUMP SUCCESSFULLY COMPLETED FROM VOL=PROD01
FDR999 FDR SUCCESSFULLY COMPLETED
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:
FDRDSF data set BCV backup example
The BCVs at addresses 01F2 and 01F3 have been ESTABLISHED to online volumes CICS01 and CICS02. The step SPLIT splits the BCVs from their online volumes and waits for the split to complete; when it is complete, updates to the online volumes can resume. Step BACKUP backs up the BCV copies of selected data sets on volumes CICS01 and CICS02, processing the two backups in parallel.
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 BCV example
An SMS storage group consists of two volumes, SMS001 and SMS002, which have BCVs 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. Step DEFINE is a one-time operation to define the catalog entries that allow FDRINSTANT to access the BCVs. The step SPLIT splits the BCVs from their online volumes and waits for the split to complete. Step COPY copies the selected data sets from the BCVs, renaming the data sets during the copy; the data sets are copied to online volumes chosen by SMS as described in FDRCOPY-Copy-or-Move-Data-Sets. These copies might be used for parallel batch processing.