Navigation Bar

Large FDRinstant Advert

FDRinstant Theory

FDRinstant uses the 'instant copy' facility which all the major z/OS disk vendors provide. I've worked with an implementation based on Flashcopy from IBM, but the same principles apply to EMC Timefinder, StorageTek's Snapshot copy, HDS Shadowimage, and Amdahl's TDMF. The principle behind all these is that FDRinstant will create an image of a disk using the API provided by the hardware. That image is essentially another volume, with its own UCB. Depending on the implementation, this may be a real volume with all the data copied, it may be a virtual volume created by pointers, or it may be a mixture of the two. The off-line volume is then marked as a valid backup, and is recorded in the FDRABR catalog.

When a volume is in use by FDRinstant, the volume label is marked by FDR so it cannot be varied online. This prevents duplicate volume messages, and means the wrong volume cannot be brought on-line at IPL time, as that could be disastrous. You should still define these volumes as being offline in your IO configuration to prevent error messages. There is also no point in defining PAV aliases for these volumes as they will only be used by FDR.

Say you wish to backup a volume VOL001, with UCB B020. You would need an empty disk with the same capacity or more, and if you are using Flashcopy, it would have to be in the same logical DASD subsystem. Say you have a free disk at B035. You would then code FDRinstant statements, invoking PGM=FDRABR, like

FCOPY     TYPE=FDR,DSNENQ=USE
MOUNT    VOL=VOL001,FLASHUNIT=B035        

This would create an instant backup of all the data on VOL001, on the disk with UCB B035. TYPE=FDR means it will be a full backup. The backup will be recorded in the FDRABR catalog, with a volser of VOL001. The job will update all the archive bits in the VTOC on the online source disk, VOL001, and also update the special FDRABR bits in the F1DSCB in the VTOC entries for every dataset. The process takes a few seconds. Once the job completes, you should see a message

FDR231   FDRFLASH COMPLETED SUCCESSFULLY - VOL=VOL001 TO FLASHUNIT=B035

fdr backups

At this point, you can restore data from the off-line disk using standard FDRABR recovery techniques. Most people want to keep more than one backup for recovery purposes, and few can afford to keep all those backups on disk, so the next stage is to move the data off disk to tape. To do this, the following FDRABR job is required. In version 5.4.55 FDRinstant can freeze the IO over a group of disks using the consistency group facility of Flashcopy version 2. This ensures timestamp consistency between the datasets in an application and is especially important for DB2 databases as they will not start up if the timestamps are inconsistent.

 DUMP    TYPE=FDR,DSNENQ=NONE,FCOPY=(USE,REL) 
 MOUNT   VOL=VOL001                   

This tells the ABR dump to use an existing flashcopy dump, and then release the flashcopy relationship when it is complete. In the joblog, you would see statements like

FDR219  FDR VOL=VOL001 IS BEING DUMPED FROM OFFLINE UNIT=B035   

FDR232   FDRINST RELEASED OFFLINE FLASHUNT=B035            
FDR232   FDRINST DISBANDED PATHS FROM OFFLINE UNIT=B035    

The job then updates the FDRABR catalog to point to the tape as a backup, and not the flashcopy disk.
The next pageset provides tips on how to make this work.

The recovery process uses standard FDRABR restore JCL, no special parameters are needed if the backup has not been moved to tape and is still on disk. If you are recovering an entire volume and the backup is still on disk then all the data will be retrieved from the disk copy, even if the current backup is an incremental. This is because all the data is copied by the flashcopy process, so there is no need to build an image of the disk up from incrementals and the latest full backup.

Copying Files instantly with FDRCOPY

If you are licensed for Flashcopy version 2, then FDRinstant may be invoked by FDRCOPY. If you copy a file and both source and target disks are in the same disk subsystem, FDRCOPY will invoke Flashcopy and the copy will appear to be almost instantaneous. This happens automatically, you do not need to specify special parameters in your copy job. The initial target dataset is defined by using pointers to the source file. The actual data copying process is carried out in the background. If you try to access a track that has not been copied yet, you will read the data from the source files via the pointer. The Flashcopy section explains how this works.

An alternative is to create a frozen copy of a set of files at a consistent point in time, then copy them with FDRCOPY. To do this, you need to reserve a set of offline volumes, then run the FDRFLASH program with the FCOPY parameter as shown below. As this is copying at volume level FDRFLASH works with both FlashCopy version 1 and 2, provided FDRinstant is at v5.4 level 30 or above.

 //COPYVOLS EXEC PGM=FDRFLASH
 //SYSPRINT DD SYSOUT=*
 //TAPE1 DD DUMMY
 //SYSIN DD * 
   FCOPY TYPE=FDR
  MOUNT VOL=VOL001,FLASHUNIT=F002
  MOUNT VOL=VOL002,FLASHUNIT=B025

You use FDRFLASH for FDR, FDRDSF, or FDRCOPY processing and FDRABR for ABR processing.

If you run FDRFLASH to copy a volume, and a previous volume copy is active between the same two volumes, FDRFLASH will withdraw the previous FlashCopy relationship and start a new one. This means that you must make sure that all your copying process from one FDRFLASH is complete before starting a new one.

back to top


                           VENDOR SHOWCASE

Copyright © Lascon Storage Ltd. 2000 to present date. By entering and using this site, you accept the conditions and limitations of use