Managing the Application Control File

The key to FDRAPPL is the Application Control File (ACF). When you execute FDRAPPL, each data set that is selected is recorded in the ACF. The records in the ACF are required to automate the restore of data sets from Application Backup. The format of the Application Control File is the same as the Archive Control File described in Working-with-FDRABR-Archiving-and-Superscratch.

FDRAPPL creates one backup file for every DASD volume processed; all selected data sets on that volume go into one backup file. Since many backup files may be produced in an FDRAPPL step if data sets are selected from more than one DASD volume, the Application Control File is required so that Application Restore can find the backup file containing each requested data set.

Each ACF record consists of:

  • The DASD data set name.
  • Some basic information about the data set, such as size and type.
  • Most important, the location of the backup file (backup data set name, tape volume serials, and file sequence number). If two backups were created (COPY1 and COPY2) both are recorded in the same record.
  • Expiration dates associated with each backup copy, assigned when the backup is created (see Introduction for details).

Whenever a restore is requested, the Application Control File that contains the records of the backup must be available. This includes off-site (disaster recovery) restores. Therefore, your plan for using FDRAPPL must include a scheme for managing the ACF and insuring that it is available when needed.

There are two techniques that can be used with the Application Control File:

  • A permanent ACF for each application. Records for each backup are appended to the data already in the ACF, so that it becomes a cumulative record of Application Backups done for this application. Backups are assigned an expiration date, usually calculated from a retention period (RETPD). Records for expired backups can be deleted by the FDRARCH utility. A restore selects the most recent backup of each data set, unless you request restore of older backups. This is described in Using-a-permanent-Application-Control-File.
  • A new ACF for each execution of FDRAPPL. Each ACF (usually a GDG) contains only records of data sets backed up in that execution. Expired backups are deleted when their ACF is uncataloged (exceeds the number of generations in the GDG), so you can easily specify or change the number of backups to be kept. This is described in Using-a-GDG-Application-Control-File.

By default, FDRAPPL backs up the Application Control File as the last file on your backup tape. The ACF in that backup contains all of the records required to restore the application data sets from the backup just created, making that tape self-contained.

At a disaster site, you may need to restore the ACF from the backup tape before doing any restores, unless it has already been recovered by some other means (such as ABR Volume Backups).

For on-site recovery, the current ACF is usually on DASD already, so you can simply point to it and restore the data sets. However, if that ACF on DASD has been lost (such as by a hardware failure), you may still need to restore it.

Important

Although tape output is usually used with FDRAPPL, and all of the examples that follow reflect this. But it is possible to direct FDRAPPL to DASD. When the output is on DASD, the ACF is not backed up. You can use the FDRTSEL utility (FDRTSEL-Introduction) to later move those DASD backups to tape; it will update the Application Control File with the new locations of the backups and it has an option (ARCBACKUP=DSF) to backup the ACF as the last file on the output tape, just like ABR.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*