FDRABR Application Backups

These links lead to sections in the text below.

FDRAPPL Overview

The traditional way to backup z/OS data is to do it disk by disk. This tends to be efficient for a nightly system wide backup, but may not be appropriate for application data which is sharing a disk pool with other applications. You may want to do backup an application at the end of a batch run to get a consistent copy of the application data before the online day starts. It is not reasonable to do this as a system wide backup, as different applications may have differing availability requirements, and their associated batch may end at different times. A successful application backup will contain exactly all the files required, no more, no less. The key to a successful application backup is good dataset naming standards, so you can get the files you need with a dataset name mask. Of course, for this to work all the files must be catalogued. Innovation call their application backup system 'FDRAPPL' and it is broadly comparable to IBM's DFHSM ABARS.

FDRAPPL combines the disk based function of FDRABR backup, with the dataset copy management of FDRABR Archive. FDRABR Archive uses a catalog called the Archive Control File to record the location of migrated files. FDRAPPL uses a version of this, which it calls the Application Control File (ACF) to record all datasets backed up in an application, and the location of their backup datasets.
Say you want to to use FDRAPPL to backup all files called INPD.** at the end of your investments run. You would allocate an ACF called INDP.APPL.BACKUP for example, then run the backup job. FDRAPPL will search the z/OS catalog for all files with a high level qualifier of INDP.** and copy them to tape. It will create a tape file dataset for every volume which contains INDP.** data, but it automatically stacks these onto a single tape. It then records each backed up dataset, with the location of its dataset on tape, in the ACF for reference if a recovery is needed.

The process and components in a bit more detail are -

back to top

The Application Control File

You have three options for creating an ACF

  • You can create a unique named ACF every time you take an application backup. FDRABR will usually write a copy of the ACF to the backup tape, for disaster recovery use. The ACF will contain backup data for this backup only. The onus is on you to delete the ACF when the backup expires.
  • Same as above, but use a GDG instead of a flat file. You set the GDG base so the ACFs expire automatically with the backups
  • You create a fixed ACF for each application, and add extra data to it each time you take an application backup. The advantage is that you have a single file which contains records of all the backups for that application. You need to back the ACF up using normal FDRABR backups, and you will need to restore it first in a disaster, as you need it to find your application backups.

To use a fixed ACF, you need to use FDRARCH to format a permanent ACF before it can be used as shown below


The NODSNCK operand shown above prevents FDRARCH from insisting on an index level of 'ARCHIVE'. You also need to run regular maintenance against the file, as records for deleted backups are not deleted from the file automatically.


Which is best? It depends, as each method has its own advantages and disadvantages. A fixed ACF gives you a permanent record for all backups of the application, but needs maintenance. A temporary ACF is easier to manage, but you may need to search several ACFs to find the backup you want.

back to top

The Backup Tape Datasets

FDRPPL tapes use the following naming convention for its backup datasets


acfhlq is the same as the first level qualifier of the Application Control File as chosen by the user. It is usually the same as the HLQ of the the application which is being backed up.
vvvvvv is the volume serial of the disk volume from which the datasets were backed up. An application backup will normally consist of several backup files, one for each volume which contained data for that application.
n is the copy number, and will be 1 or 2. You always create a copy1, but you can also create a duplicate copy by adding an TAPE11 DD dataset in the JCL. You can direct that copy to a remote tape drive to create an automatic offsite disaster recovery copy.
yyddd is the 5 digit Julian date of the day that the backup ran.
b and x are changed if multiple Application Backups are created for the same disk volume on the same Julian date, and the backup datasets are catalogued. Their default values are B and A

The Backup datasets are not normally catalogued, though the ACF copy at the end of the tape will be. This can be a problem if you use TLMS for your tape management, and default to catalog control, as TLMS uses the retention policy of the first file on the tape to control the tape retention.
You can use RETPD=days and match that with the retention period set for the backups in the ACF, if the ACF is permanent. If you use CA1 for tape management, and use a GDG based ACF, then catalog control is very appropriate, as CA1 will expire the tape when the ACF GDG rolls off.

back to top


Backup JCL looks like this. It is using a permanent archive file, and is backing up all catalogued files with a high level qualifier of INDP. It is creating two backup copies, and keeping them for 30 days. The backup copies are tape GDGs as specified by the ARCBxDSN parameters, and one is held locally, while the other is going to remote drives as specified in the UNIT parameters. This, of course, assumes that these esoterics are defined in the IOCP and match real tape unit addresses.


Its possible to be a lot more specific in selecting datasets for backup. The above SELECT statement could be SELECT CATDSN=INDP.MF%%%%.**.SASBD, which means all cataloged files starting INDP.MF, with exactly 4 unspecified characters after the MF in the second qualifier, no restriction on subsequent qualifiers, except that the last one must be SASDB.

back to top


You can select the datasets to be restored, or simply restore the most recent copy of every dataset in the ACF. The example below restores all files from the latest backup GDG, using the remote copy tape.


The ALLDSN on the select statement means restore all datasets that were backed up and recorded in the archive control file - with a single SELECT statement. However if you did not want to restore the whole application then you can specify individual or groups of datasets with select/exclude statements. By default you will restore from the most recent backup, but those select statements can also be used to pick out older backups.

The ARCHIVE DD statement points FDRAPPL to the control file that was used to store details of the backup. In a disaster recovery situation, you would first need to restore this control file to disk. FDRAPPL will always place a copy of the control file on the end of the backup tape.

The DYNTAPE operand tells FDRAPPL to automatically obtain details of the backup media from the control file, so you do not need to work out which tapes, or types of tapes are needed for the restore.


The RECAT (for ordinary files) and VRECAT (for VSAM files) are needed to ensure that the cataloging of the restored files is correct. By default FDRAPPL will try to put each dataset back onto its original disk volume, but if it cannot do this then it will restore them to a different volume, often as directed by DFSMS.

The COPY=2 parameter means use the offsite DR tape for the restore.