FDRAPPL introduction

ABR

Program FDRABR (Automatic Backup & Recovery (ABR®)) automates the execution of FDR full-volume and data set backups and restores for the purposes of:

• Data Availability - Creating backup copies of DASD data sets to protect against physical loss or logical damage.
• Space Management - Identifying data sets that do not need to be on DASD (usually based on the last date they were used) and moving them to backups (called “archiving”), from which they can be automatically recalled if needed. Data sets that are never needed again can be scratched without creating a backup.
• Disaster Recovery - Creating backups from which all or part of your DASD data can be quickly recreated at a disaster recovery site.
• Tape Mount Management (TMM) - Maximizing tape volume usage by staging small tape data sets to a DASD buffer, then moving many of them to a tape volume.

These objectives are accomplished by the use of several ABR functions:

• This section describes Application Backup, also known as FDRAPPL, used for “data availability” and “disaster recovery” at the application level. FDRAPPL is automatically included if you are licensed for ABR, but it can also be licensed as an option to FDR.
• ABR Volume Backups (DUMP TYPE=FDR/ABR/AUTO/DSF) are found in Working-with-FDRABR-Volume-Backups.
• ABR Archive (DUMP TYPE=ARC) and Superscratch (DUMP TYPE=SCR) are in Working-with-FDRABR-Archiving-and-Superscratch.

ABR backups

All the backup functions of ABR share these common characteristics:

• The backups are in standard full-volume (FDR) or data set (DSF) backup format, described in FDR-and-FDRDSF-overview. If necessary, data can be restored from ABR backups with FDR or FDRDSF, but ABR automates the restore process.
• Although ABR backups require a separate backup data set for each DASD volume processed, ABR automatically stacks multiple backup data sets on tape, creating multi-file tapes, to make best use of today's high-capacity tape volumes. If necessary, multiple output tape volumes are used. No special JCL is required since ABR handles the file creation internally.
• ABR backups to DASD are also supported. ABR automatically allocates the backup data sets on the backup volumes you specify. DASD backups are usually not used with Application Backup.
• The output devices (tape and/or DASD) are specified in the ABR batch JCL. However, you only need to identify the output device; ABR automatically names and creates every backup data set and catalogs it if required.
• You can specify in the JCL that two copies of each backup are to be created, even though the input DASD is read only once. In ABR, these are known as COPY1 and COPY2 (see FDRAPPL-Backup-Job-Control-Requirements for details). The ABR utilities FDRTCOPY and FDRTSEL (Working-with-FDR-and-ABR-backup-maintenance) can be used to create COPY2 from COPY1, but there are some limitations for Application Backup.
• If multiple output devices are specified in the JCL, ABR automatically uses internal sub-tasking to process more than one DASD volume concurrently.

FDRAPPL application backup

FDRAPPL Application Backup, as its name implies, is designed to backup all the data sets that relate to a given application, from whatever DASD volumes they reside. Since application data sets are usually cataloged, you can have FDRAPPL search the z/OS catalogs for data sets matching one or more name masks, quickly and easily selecting the data sets and their cataloged volumes to be processed.

FDRAPPL processes all of the data sets selected on the volumes selected. Since FDRAPPL always creates one backup data set per DASD volume, it automatically stacks multiple backup files on the output tape, depending on how many DASD volumes are read. Usually a single tape is used for output, creating one tape with all the selected data (a duplicate backup can be created).

FDRAPPL does use a database to record the data sets that were backed up. This database is called an Application Control File (ACF); it has the same format as the Archive Control File described in Working-with-FDRABR-Archiving-and-Superscratch. The ACF is very compact, recording several hundred data sets in a single track. A separate ACF is used for each application.

If data sets must be restored from an Application Backup, the information on their location is read from the ACF to build a list of backup data sets to be dynamically allocated and read. You can select the data sets to be restored, or simply restore the most recent copy of every data set in the ACF. Obviously, access to the ACF is a critical requirement for automated restore from FDRAPPL. It is possible to do manual FDRDSF restores, but it requires a TAPEx DD statement for every backup file on the backup tape.

There are several ways of managing the ACF. Details are found in Managing-the-Application-Control-File.

Many application job streams contain a series of specialized backup steps in order to create backups of application-oriented data sets to provide restart and recovery capabilities just for that application. These backups (often IEBGENER or IDCAMS REPRO steps) may be time-consuming and may use many tapes. FDRAPPL may be used as a single-step high-speed replacement for those specialized backups. If copies of Application Backup tapes are sent to off site storage, they may also be used to recover application data sets at a disaster recovery site.

Why FDRAPPL?

Why would you want to use FDRAPPL instead of relying on ABR Volume Backups?

• Volume Backups are usually taken at a fixed time each night. For many applications, this is the wrong time and does not provide the recovery and restartability they need. Application backups can be inserted into the application job streams, to provide backup at a point in processing chosen by the application developers.
• Frequency and retention of the application backups is under control of the application, instead of the data center.
• At a disaster recovery site, critical applications can be recovered first and less urgent applications at a later time.

Under SMS and other DASD pooling software, users often are unaware of the DASD volume serials of their data sets. FDRAPPL allows you to provide one TAPE1 DD (with optional duplicate backup TAPE11), and to select data sets from the system catalogs without being concerned about the volumes they reside on.

Application recovery uses data set (FDRDSF-type) restores, so the data sets may be directed to a different set of volumes than those they were dumped from, and may be spread out on fewer or more volumes than they originally occupied. Remember that multi-volume data sets must be restored to the same number of volumes they were dumped from, with the original amount of space on each.

For recovery at your own data center, FDRAPPL is useful if a critical application must have recovery, owns data sets that reside on multiple DASD volumes, and the backups cannot be scheduled as part of the normal Volume Backups. The Application Backup is usually done after the batch or online processing for the application has completed and updates to the data sets are quiesced. Since only data sets from this application are dumped, using all of the performance of an FDR backup, the down time for the application is reduced to a minimum. The application backup can executed as a step in the actual application job stream, so that it is executed at the point that is required by that application.

FDRAPPL is comparable to ABARS in IBM’s DFSMShsm product.

Compared to ABARS, FDRAPPL:

• Is significantly faster,.
• Offers more flexible selection criteria.

Implementation

There are several different ways that you can implement FDRAPPL, each with its own advantages. You must choose the one that best meets your needs; the choice may depend on whether you intend to use FDRAPPL to recover applications at a disaster site, or at your prime site, or both.

The differences in the techniques are primarily in the usage of the Application Control File. Remember that FDRAPPL records the Application Backups in an Application Control File, and that Application Control File is required to restore the data sets. The two major techniques are:

• One permanent Application Control File for each application.
• The Application Control File for each application is a GDG, creating a new generation for each backup step.

See Managing-the-Application-Control-File for more details on these techniques, including specific examples.

Simulation

All functions of FDRAPPL can be run in simulation mode, allowing you to verify that the correct data is selected when run for real.

ABR Utilities

ABR includes a utility program, FDRARCH, for maintaining the Application Control File. If you choose to maintain a permanent ACF for each application, you will need to periodically run the REORG function of FDRARCH to purge those obsolete entries and make room for new ones. FDRARCH is documented in Archive-Maintenance-Utility-FDRARCH.

FDRABRP (Working-with-FDRABRP) can be used for simple reporting on data sets recorded in an ACF, and FDREPORT (Working-with-FDREPORT) can be used for more sophisticated reporting. The ABR ISPF dialog called SRS (Search, Report, and Services) can also display information on Application Backup data; it is in Working-with-FDRSRS. In each case, you must point to the proper Application Control File to be used as input.

Tape format and naming conventions

As indicated earlier, the backup files created by FDRAPPL are in standard FDRDSF (data set backup) format. In this format, each backup file can contain data only from one DASD volume. Therefore, if multiple DASD volumes are to be processed, FDRAPPL must create multiple backup files on the output tape or DASD. Unless you select data sets from only a single DASD volume in an FDRAPPL step, FDRAPPL always creates multiple backup files.

Since FDRAPPL must be able to uniquely name each tape file, and must be able to record the backup file in a way that it can easily be retrieved, FDRAPPL uses a special naming convention for the Application Backup files. The name contains the DASD volume serial, the date of the backup and a uniqueness character in case data is archived multiple times per day, so each FDRAPPL Backup from a given DASD volume has a unique name. This is the same convention used by Archive Backups (see “Tape Format and Naming Conventions” in Introduction-to-FDRABR-Archiving-and-Superscratch), except for the hi-level index.

The format is userindx.Vvolser.bnyydddx where:

userindx

Is the same as the hi-level index of the Application Control File, so it is a hi-level index chosen by the user. It is usually an index belonging to the application owning the backup.

volser

Is the volume serial of the DASD volume from which the data sets were backed up. FDRAPPL creates one backup file for each DASD volume processed in a given ABR run.

n

Is the copy number. FDRAPPL always creates COPY1 and can optionally create COPY2.

yyddd

Is the Julian date of the backup job (5 digits).

b

x

Are qualifiers added to make the name unique if multiple Application Backups are created for the same DASD volume on the same Julian date. However, they are used only if the name FDRAPPL is trying to create is already cataloged. Since FDRAPPL data sets are usually not cataloged, “b” and “x” usually have their default values of B and A (see “Tape Format and Naming Conventions” in Introduction-to-FDRABR-Archiving-and-Superscratch for details).

Example:

The backup files created by FDRAPPL are usually not cataloged. For most such backups, all the information required is stored in the data set records in the Application Control File. When restoring, information about the backup file to be read is obtained from the ACF so no entry in the catalog is required. If you like, you can override this: ARCCAT=ALL forces FDRAPPL to catalog all backup files, while ARCCAT=NORMAL follows the rules for Archive Backups in “ABR Archive Backup” in Introduction-to-FDRABR-Archiving-and-Superscratch.

By default, FDRAPPL backs up the Application Control File itself as the last file on the backup tape created on both TAPEx and TAPExx using an FDRDSF-type backup of just that one data set. If your step included more than one TAPEx DD statement, the ACF is backed up to the last tape that was active. This makes the tape self-contained, with all of the requested data plus a copy of the ACF required to restore from the tape. By default, the data set name of the backup file itself is the same as the name of the ACF, except that the index level of ARCHIVE is replaced by ARCBKUP (on TAPEx) and ARCBKU2 (on TAPExx). However, you can control the backup data set names with the ARCB1DSN= and ARCB2DSN= operands; this is recommended.

Backup retention and tape management

Depending on the requirements for retention of backups established by each application, you may choose to control the retention of Application Backups in several ways:

• You can let your tape management system expire backups based on a retention period (RETPD=). This is known as “date control”. Both your tape management system and the Application Control File will have the same expiration date for the data created by a given backup. The tape management system scratches the tapes on that day. This is usually used with a permanent Application Control File (see Using-a-permanent-Application-Control-File).

If you are doing Application Backups to cloud storage, then each volume that is processed in a backup run has a backup control file on DASD. The retention/expiration is stored in the F1 DSCB of the backup control file, but the backup control file may not be deleted unless you run ABR Superscratch with the SELECT ABRBKUP statement against those volumes. FDRARCH can also delete expired DASD backup control files during Application Control File reorganization. When these backups expire, and are deleted by SELECT ABRBKUP or by FDRARCH REORG, only the backup control files are deleted. You must periodically run FDRTCTUT with the DELETEBACKUPS command, as shown in FDRTCTUT-FDR-Transparent-Cloud-Tiering-Batch-Utility, to clean up the actual backups in the cloud.

• You can retain backups based on the number of times the backups have been run. To do this the Application Control File (or at least the backup of the ACF) must be setup as a GDG (see Using-a-GDG-Application-Control-File). You must specify that your tape management system is to use “catalog control” for these tapes (specified by EXPDT=99000 for many tape management systems). Since the ACF backup is the only cataloged file on the tape (or multi-volume tape set), the entire tape set is retained until that file is uncataloged. It is eventually uncataloged as new generations are created (new backup runs) and the tape management system scratches the tapes.

If you are doing Application Backups to cloud storage, you can use the GDG technique to manage the Application Control Files and their backups, but not the backups of the user data sets. For each volume that is processed in a backup run, FDRAPPL creates a backup control file on DASD; the backup control files are cataloged; the backup control files are named according to the naming conventions above, and cannot be GDGs; so there is no way for the operating system to delete them automatically. Instead, use date control with RETPD= as discussed above, and run ABR Superscratch with the SELECT ABRBKUP statement against the volumes containing the backup control files. In addition, you must periodically run FDRTCTUT with the DELETEBACKUPS command, as shown in FDRTCTUT-FDR-Transparent-Cloud-Tiering-Batch-Utility, to clean up the actual backups in the cloud.

• If you have no tape management system, you must establish the necessary manual procedures for identifying and expiring FDRAPPL backups.

When an Application Backup is taken, an expiration date is assigned to each backup file. It can come from several sources, in this order of priority:

• If the RETPD= operand is specified on the FDRAPPL DUMP statement, FDRAPPL uses that to calculate an expiration date that is assigned to all COPY1 (TAPEx) backups created in that FDRAPPL step. If the RETPD2= operand is not specified but COPY2 (TAPExx) backups are also created, the same expiration is assigned to those backups.
• If the RETPD2= operand is specified on the DUMP statement, FDRAPPL uses that retention period to calculate an expiration date that is assigned to all COPY2 (TAPExx) backups created in that FDRAPPL step.
• If the TAPEx or TAPExx DD statement pointing to the backup tape contains the EXPDT= operand, the date specified is assigned to all backups written to that DD statement. For some tape management systems this value can also be a keyword; for example, EXPDT=99000 indicates “catalog control” to many tape management systems.
• If the DD statement contains the RETPD= operand, z/OS uses that to calculate an expiration date, which FDRAPPL assigns to each backup written to that DD statement.
• If none of the above RETPD or EXPDT operands are given, the default retention period of 365 days (1 year) is used to calculate an expiration date that is assigned to each backup.

By whatever means it is calculated, the expiration date is recorded in the Application Control File record for each data set included in that Application Backup file. If both COPY1 and COPY2 of a backup are being created, the expiration of each copy is recorded separately in case they are different.

The expiration date is recorded in the tape labels of the backup file and is also recorded by your tape management system, if you have one. If the expiration date is a real date (not a keyword such as 99000) then your tape management system probably returns the tape to scratch status on that date.

If you create both COPY1 and COPY2 of your backups, you can use one copy for on site restores and the other copy for off site restores at a disaster recovery site. Most tape management systems include vaulting support, allowing you to select tapes to be sent off site and returned when no longer required. Most users send COPY2 off site. Since the data set name used by FDRAPPL includes the copy number, you should be able to easily send COPY2 backups off site while retaining COPY1 on site.

FDRAPPL execution

To perform Application Backups, you must create FDRAPPL steps and insert them into appropriate application job streams. You may want to create standard FDRAPPL steps or cataloged procedures (PROCs) that can be invoked by application programmers. Using-a-permanent-Application-Control-File and Using-a-GDG-Application-Control-File contain examples of such steps that you can customize for your installation. All of the examples shown in this manual are also in the JCL library loaded as part of FDR's installation (see Installing).

Recommended techniques for executing application backups are found starting in Managing-the-Application-Control-File.

You will probably also want to establish procedures to allow application programmer to create jobs to restore all (o a subset) of the data sets in a given Application Backup. Restore techniques are also detailed starting in Managing-the-Application-Control-File.

Converting to FDRAPPL from other backups

You may be currently using other techniques to do an application-type backup. The following is a quick reference and examples of converting from various types of backups to FDRAPPL.

Details of FDRAPPL operation are explained in the rest of Working-with-FDRAPPL. Please read the appropriate sections for more details on the setup and operation of FDRAPPL.

Convert from IDCAMS example

IDCAMS REPRO (or EXPORT) or other utilities may be used to backup files for application backups. These utilities are awkward because they generally process only one data set at a time, requiring complex JCL when multiple application data sets must be backed up.

Here is a typical IDCAMS REPRO step, backing up three data sets to three files on a tape. The data sets may be VSAM or sequential non-VSAM.

An equivalent FDRAPPL backup step is shown below. Additional application files could be added to it just by adding their data set names, or by using a generic data set name filter

Convert from DFSMSdss example

You might be using DFSMSdss to backup data sets with catalog filtering, using a step such as:

You could replace it with an FDRAPPL step such as:

In many cases, an FDRAPPL backup is faster than the equivalent DFSMSdss backup. This example records all the backups done for this application in the permanent control file named “APPL1.CONTROL.FILE”. You can easily report on this to see all the backups that exist and select data sets to be restored. Since the control file records several versions of the backup, you can easily restore from older backups.

Convert from FDRDSF example

FDRDSF can be used to backup application data sets, but FDRDSF does not allow for selection of data sets from the catalog.

This FDRDSF step is coded to specify the volumes from which to select data sets. Since there are three volumes involved, there must be three backup files.

An FDRAPPL backup can be used to select the data sets from the catalog, without having to be concerned about what volumes they are on or how many volumes are involved.