Disk based FDRINC backup and recovery

These links lead to sections in the text below.

Backup Scheduling

FDRINC was previously called FDRABR and both terms will be used here. FDRINC backups run as batch jobs, but FDRINC does not have its own built in scheduler. You need to schedule the jobs with your own scheduling utility such as CA7 or OPC. Scheduling is outwith the scope of a storage site, but in general, you need to use automation to stop, or at least quiesce any affected online systems, use the scheduler to run the backups, trap the end of the backups, and then use automation to restart the online systems. If you can not afford to have your online systems down for an length of time, then consider using FDRinstant, which can backup terabytes of data in a few minutes, using snapshot copy techniques.

FDRINC has two types of backup, full and incremental. You select these by using the TYPE keyword as detailed in the backup section below.
You may want to schedule a full backup at the weekend when you have more time available, and incrementals through the week. An alternative approach is to use TYPE=AUTO and let FDRABR decide what to dump. This works in conjunction with the ABR initialisation dataset. You specify the number of generations (full backups) and cycles (incremental backups) in the FDRABR model dataset. Say you specify GEN=3 and CYCLE=6. This means that FDRABR will take one full backup, then six incrementals. If you specify TYPE=AUTO on the dump, it will then automatically take a full backup on the next dump, then the next six backups will be incrementals, so you get a weekly cycle of one full dump and 6 incrementals.


  • Only one set of JCL required
  • Full backups are spread over the week


  • Recovering multiple disks takes more time, as the disk backups are split over several tapes. You will get tape contention between recovery jobs, but you can avoid this by using FDRDRP - see the FDR TAPE section for details

In terms of disk recovery, recovering from a full backup is fast, as all you need to do is read one tape. However, if you have to recover from incrementals then you start with the newest incremental, and work back to the full disk backup, so you could be reading seven tapes. My ownpreference is to use TYPE=AUTO and let FDRINC decide what type of backup to take, but ensure the initialisation parameters get you one full backup per week. If you combine this with FDRDRP you should not get tape drive contention issues in a disaster recovery situation.

Watch out for your storage pool settings in SMS, as ABR will check them. If AUTO-DUMP is set to NO, FDRABR will bypass the backup of that pool. If AUTO-BACKUP is set to NO, but AUTO-DUMP is set to YES, you will get full backups, but incremental dumps will be bypassed. You can tell FDRABR to ignore SMS settings by coding SMSCONSTRUCT=NO in the dump jobs, or by setting this as a global option.

back to top

Backup Parameters

During a full-volume ABR backup, everything on a volume is backed up, including the label track, VTOC, VTOCIX and VVDS. You cannot exclude any files from a full backup.
An incremental backup will backup all files that have changed since the last backup as indicated by the changed bit being set on. However, temporary datasets, and datasets in the ABR protect list will not be backed up. An incremental backup always includes the label track, the VTOC, VTOC INDEX and VVDS. FDRINC will always backup any multi-volume components of VSAM files, and ICF catalogs.
It is possible to manually exclude datasets from an incremental backup by using an EXCLUDE statement. You can also do this using SMS. If you specify SMSMANAGE=YES on the ABR DUMP statement, and the management class specifies that a data set is not eligible for 'auto-backup'. it will not be backed up. Be aware that either of these excludes will prevent a complete full volume restore.

You can specify individual disks for volume backups, but if you use SMS, then it is easiest to backup by storagepool. Example JCL is

//SYSIN    DD *
   MOUNT    VOL=volser
   MOUNT    STORGRP=poolname

DUMP TYPE=FDR means take a full volume dump. Other options are TYPE=ABR, incremental dump, TYPE=AUTO, let ABR decide what type of dump to take.
DSNENQ=USE means try to get exclusive use of all files for backup. If you can't get exclusive use, back the file up anyway. If its critical that you must get exclusive use of the files for a clean backup, then this is not appropriate, and you should use DSNENQ=HAVE. This will issue a message to the SYSLOG console if it finds a file in use and ask operations to decide what to do about it. Obviously, this parameter should be used with care or you will become very unpopular with the operators. DSNENQ=NONE is equivalent to WAIT(0,0) in DFDSS.

Another option is ENQ=. ENQ=ON will lock out the VTOC on a disk while a backup is in progress, and is useful if you have several LPAR systems sharing the same disks and do not have a cross system ENQ product like GRS or MIM. This can cause problems during backups when other products, specially monitoring products are trying to access the disks. ENQ=OFF is the default.
ENQERR=NO means don't fail the job if you get an ENQ failure.
MOUNT VOL=volser means backup this disk. You can have several mount statements in the same job, and then ABR stacks the backups onto one tape
MOUNT STORGRP=poolname means backup an entire SMS storagepool with one job. This means that volumes are backed up automatically when they are added to the storage pool, or not backed up if they are removed. This saves a lot of effort maintaining JCL.

If you are backing up a large storage pool, you can use multiple TAPE DD statements so you write to more than one tape drive concurrently. If you do this, then every TAPEx statement must have matching SYSPRINx statement


FDRBAR will require extra memory storage for each TAPE DD statement. As the FDRABR program normally runs below 'The Line', this means your job can abend due to memory shortages. If this happens, add the parameter RTC=YES to your DUMP statement to force the program to run above the line.
z/OS syntax checking requires that a DSN must be supplied, and each DSN name must be unique for every active backup. FDRABR replaces this supplied name with its own generated name when the backup starts. DSN=&&TEMP is a simple way to get around this requirement.

FDRABR backups are optimised by default to chain the blocks from a whole cylinder into a single IO request. This is one reason why FDRABR is such a fast data mover. If you are backing up a large storage pool with a single job and your backup is taking too long, then your only realistic option is to add more tape DD statements to run more tasks in parallel.

Copying a disk with FDR

If you want to move a complete volume from one address to another, it is easier to do this with FDRPAS as this is a non-disruptive move. However it is possible to do this with PGM=FDR combined with the COPY STATEMENT. Sample JCL is

//SYSIN      DD   *

COPY is the only statement allowed on this job. This job will copy all the data from SOURCE, identified by the DISK1 DD statement to TARGET, identified by the TAPE1 DD statement. (Apart from being descriptive, SOURCE and TARGET are valid z/OS VOLSERS)
CPYVOLID=YES means that TARGET will be varied offline to this LPAR then labeled as SOURCE when the copy completes.
You should vary the target disk off line to any other LPARs before you submit the copy job, to prevent incorrect label errors. (I have seen someone forget to do this back in the OS/390 days and they required an IPL to sort out the addressing, but I believe z/OS is more resilient).
Once the copy completes, then vary the source disk off-line everywhere and vary the target disk on-line everywhere.
CONFMESS=NO means do not send a console WTOR message to the operator, who must then manually confirm before the copy will begin. The default is YES

You would normally copy to a target disk that is the same size as the source. You can copy to a larger disk that has the same track geometry as the source. If you want to copy a large disk to a smaller one, then either use COMPAKTOR, or do a dataset level copy with FDRCOPY.

Copying datasets with FDRCOPY

It is easiest to move datasets almost non-disruptively with FDRMOVE, but FDRCOPY can be used to copy and move files. PGM=FDRCOPY has two options, MOVE and COPY, which should be self explanatory.

To take a copy of a file called ISP.ACCTS.TSAD.INPUT run the following job


This job is selecting a specific dataset by its catalog entry, and copying it to another name. No volumes are specified, so if the dataset in non-SMS managed it will be copied to the same volume; SMS would pick its own volume. As we are using CATDSN, no input volume is necessary

To drain an SMS managed volume DA1245, change its SMS status to DISNEW, then run the following job

//SYSIN   DD *

This will move all datasets (except system files like the VTOC, VTOCIX, VVDS and ABR initialisation dataset) from volume DA1245 to volume DA4567. You need to specify an output volume, but if the data is SMS managed, SMS will intervene and pick its own target disks.

One or two things to consider:
You can move datasets between unlike device types, except that multi-volume VSAM which must be copied to the same device type
You can copy multi-volume datasets, but you have to specify the same number of output volumes as input volumes.
If you use DSN= then you need to specify an input VOLSER or group of VOLSERs so FDRCOPY knows where to look for the files. The volume(s) will be scanned for matching datasets.
If you use CATDSN= then FDRCOPY will find the input dataset in the ICF catalog system no input volume is required.
You can use very sophisticated filters to select files and rename files.

Some examples of filters are -

  • DSN=**TXT133
    (Select every dataset on this volume ending in 'TXT133')
    (Select every dataset on this volume starting 'IN' then two numeric characters, any number of intermediate index levels, then a final level of 'PROCLIB')
    (Select every catalogued dataset starting INP, any number of intermediate index levels, then a final level of PROCLIB)
    (Select the current generation for every catalogued GDG ending in OUTLIST. This will be very expensive to run in CPU terms as every catalog must be searched)

If you need to rename a large number of files to a different index, for example, FDRCOPY MOVE can be lot easier to set up than IDCAMS ALTER NEWNAME. FDRCOPY COPY can also be used to create development or test data.

You use NEWI= to replace some, or all of the indexes in an input dataset

In the simplest case, with an input dataset of SAP.ARXV.INPUT:

NEWI=SAT would create a file called SAT.ARXV.INPUT (first level replaced) and NEWI=SAD.TEST would create a file called SAD.TEST.INPUT (first 2 levels replaced)
NEWI=.TEST would create a file called SAP.TEST.INPUT (second level replaced, note the period before TEST, this means leave the first level intact and replace the second level. NEWI=..TEST would replace the third level)
NEWI=+EEV would create a file called EEV.SAP.ARXV.INPUT (The + means add the characters as an extra level.
NEWI=..+EEV would create a file called SAP.ARXV.EEV.INPUT (.. means leave first two levels alone, + means insert EEV here)
NEWI=.- would create a file called SAP.INPUT ( the . means leave the first level alone, the - means drop the second level)

These options can be combined to make up some very sophisticated changes


will select all catalogued datasets starting SAP that have an alphabetic first character in the second level, then a numeric character, then exactly AB, any third level, then exactly TEST as a fourth level.
These files will all be copied to files starting SAT, the second level will be deleted, the third levels will be retained as the new second level, and a final index of MAY05 added.