DISCLAIMER - By entering and using this site, you accept the conditions and limitations of use
Click here to see the Full Site Index Click here to see the Cookie Policy Click here to see the Privacy Policy ©2019 and later, A.J.Armstrong
It is easy to recover a full volume using FDRABR. The JCL you need is
//STEP1 EXEC PGM=FDRABR
//DISK1 DD UNIT=3390,DISP=OLD,VOL=SER=oldvol
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSIN DD *
RESTORE TYPE=FDR,CONFMESS=YES,DYNTAPE
SELECT VOL=restvol,GEN=CURRENT
The oldvol in the DISK DD statement is the volser of the volume that you are going to overwrite. This must be offline to all systems except the one you are restoring from.
RESTORE TYPE=FDR means this is a full volume restore.
CONFMESS=YES puts a message on the system console, which must be replied to, to confirm that this restore can happen. It is not essential, but gives you an extra safety check. If you are recovering a lot of volumes after a disaster, you may want to change this to CONFMESS=NO
DYNTAPE means that ABR will dynamically allocate all the tapes it needs, you do not need to supply TAPE DD statements.
SELECT VOL=restvol is the volser of the disk you want to restore. This can be the same as the oldvol above, of course.
GEN=CURRENT means rebuild the disk from the most recent backups
ABR uses the newest incremental and restores all the files that were backed up on that incremental, including the VTOC. It then reads back through the incrementals to the full backup, and restores the newest version of each dataset, until it has rebuilt the disk exactly as it looked at the last incremental backup.
Contrast this with DFDSS, where you restore the latest full backup, then apply the incrementals yourself, in the correct order. You will end up recovering some files several times, and the end result will not reflect the latest state of the disk, as some files which were deleted will now be present.
If you are going to recover a lot of volumes with FDRABR, maybe in a disaster recovery situation, then you should consider purchasing FDRDRP. Every modern high-capacity tape will typically hold several volume dumps and if you use the TYPE=AUTO option on your backups, then these dupms may be a mix of full and incemental backups. If you recover the volumes using traditional FDRABR, then it will mount and dismount each volume every time it needs to access a dump, and this will be very time consuming. FDRDRP will restore multiple disk volumes that have been backed up onto high-capacity tapes in one pass of each tape. InnovationDP claims that this will slash recovery times by up to 80%.
For the ABR reconstruction to work, its essential that the files are not moved around on the disk. If you use IBM's DEFRAG to consolidate free space, then ABR recoveries from incrementals will not work. The answer is to either use Innovation's COMPAKTOR product to consolidate free space, or to force a full disk backup after a DEFRAG.
Dataset restores are usually very simple too. Sample JCL is
//STEP1 EXEC PGM=FDRABR
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSIN DD *
RESTORE TYPE=ABR,DYNTAPE,DSNENQ=USE
SELECT DSN=dataset.to.be.restored
RESTORE TYPE=ABR means that this is a dataset restore
DSNENQ=USE means check to see if the file is in use before overwriting it. You can use DSNENQ=NONE, in which case ABR will just ignore file-in-use indicators, but this is rarely a good idea as you do not want to overwrite a file which is in use.
SELECT DSN= picks out the file you want. You can have several select statements in one job. ABR will use the ABR catalog locate mechanism is discussed in the previous page, to find the backups of the datasets, and will mount tapes as required. This restore will overwrite the original, if it exists.
ABR has lots of extra recovery options, some of the ones I have found to be useful are
DSN-INXP.MASTER.FDRJCL
LAST REF--2018.005 DSORG----POE
****** BACKUP INFORMATION ******
BKD(00)-2018.003 SFX-C1004800 FN-0025 VOLS-A00975
BKD(01)-2017.360 SFX-C1004702 FN-0023 VOLS-A03697
BKD(02)-2017.358 SFX-C1004700 FN-0021 VOLS-A01125
The BKD(nn) entries are relative backup numbers, and next to them is the Julian data of the backup. So if you wanted a copy of this file from 2017.358 (December 22nd) then the relative backup is 02, so you specify OLDBACKUP=02. ABR then goes away and get the correct tape for you. ABR can track up to 13 old backups, but for this to work, the disks must be ABR initialised with the OLDBACKUP option set. See the ABR initialisation section for details.
VSAM dataset recovery can be a bit more complicated, but will usually work as long as you remember a few simple rules
Simple VSAM restores
Always select the CLUSTER name for the file you want restored, do not select the individual data and index components
RESTORE TYPE=ABR,DYNTAPE,DSNENQ=USE
SELECT DSN=vsam.cluster.name
Use the NEWI parameter to give the cluster a new name.
RESTORE TYPE=ABR,DYNTAPE,DSNENQ=USE
SELECT DSN=vsam.cluster.name,
NEWI=new.cluster.name
If your original VSAM cluster had three levels and you specify a new two level name then only the first two levels will be changed
For example a restore of DWP.BILLING.RUN1 using parameters
SELECT DSN=DWP.BILLING.RUN1, NEWI=DAT.TESTING
Would restore a file called DAT.TESTING.RUN1
Recovery of large, multi-volume VSAM files can sometimes be problematical. If a file had five data components on five volumes, and one index component on its own volume, then it must be restored to six different volumes. FDRABR would select a volume with enough space for the first part of the VSAM file, but subsequent volumes selected may not have enough space. DFSMS will also get involved in picking out volumes. A release of FDRABR that came out in 2002 helped, because if it did not find the space on a volume it automatically retried the allocation a few times, but it is still possible to get errors.
If you know how many VSAM components, and therefore how many volumes you need, and if you can check manually to see that the space is available, then you can override all the automation and force the file to go where you want it to.
You will need one SELECT statement for every volume component of the multi-volume VSAM file. Each SELECT should specify the file by the cluster name, not DATA or INDEX component. If the DATASET is spread over three volumes, then three select statements are required.
RESTORE TYPE=ABR,DYNTAPE,DSNENQ=NONE,
SELECT BYPASSSMS,BYPASSACS
SELECT DSN=DWP.BILLING.RUN04,
NEWI=DWT.TESTING,VOL=RX2208,
NVOL=DX2016
SELECT DSN=DWP.BILLING.RUN04,
NEWI=DWT.TESTING,VOL=RX2200,
NVOL=DX2019
SELECT DSN=DWP.BILLING.RUN04,
NEWI=DWT.TESTING,VOL=RX2204,
NVOL=DX2000
SELECT DSN=DWP.BILLING.RUN04,
NEWI=DWT.TESTING,VOL=RX2200,
NVOL=DX2019
Each NVOL must have enough contiguous free space to cope with the space used by the corresponding VOL.
FDRABR will try to restore each component individually. If one or two components fail, then you can rerun the job, but you must retain the SELECT statements that worked, and they must still point to the new volumes that worked. The SELECTS for the failing components can point to any other volume that has sufficient space, the error log in the failing job will tell you how much space is needed.
If you want to start again from scratch then you must clean up any restored components before trying again. The cluster will be allocated to a volume name like ####VK+, use ISPF line command DELETE / NOSCRATCH to get rid of it. The restore job will tell you if it managed to get any components back. These will be orphans, and need a 'DELETE / dsname VVR VOLUME(volser) DEVT(3390)' command from ISPF to get rid of them. If you don't do this, the next restore will probably fail with FDR157 9096-58 previous restore incomplete.
FDR cannot restore a multi-volume AIX. It must be rebuilt using IDCAMS
The most common restore error message is an FDR321. This message has lots of reason codes, and the most common are explained below.