Using a GDG Application Control File
All examples in this section are found in the JCL library installed with FDR. The member names are EX5212x.
This section describes use of FDRAPPL with a GDG Application Control File. Example job steps are provided. These examples are also found in the JCL library loaded during FDR's installation (see Installing).
In this technique, a new Application Control File is created every time the FDRAPPL job stream is run. The ACF is created as a generation of a Generation Data Group (GDG) so that multiple versions of it can be kept. A unique GDG must be created for every FDRAPPL but the name of the GDG can be any that meets your needs.
You must define the GDG base for the ACF with a LIMIT of 1 or more, reflecting the number of versions of that ACF that you want to retain on DASD. The GDG base should have the SCRATCH attribute so that old versions are scratched from DASD automatically when new versions are created.
If you use the default of ARCBACKUP=DSF to make a copy of the Application Control File on tape, those backup files will usually also be a GDG. You must also create the GDG bases for those backups, with LIMITs that reflect the number of backups to be kept for the application. If you define the Application Control File GDG with LIMIT(1) so that only the latest version is kept on DASD, it can be used for on-site restores from the latest backup. If you need to restore from an older backup or at a disaster site, you must restore the ACF from the backup tape before executing restores.
These GDG Application Control Files do not require any maintenance, since each contains only the records from one execution of FDRAPPL and are automatically deleted when obsolete.
The high-level index of the Application Control File data set name is also used as the high-level index of all backup files on tape created by FDRAPPL, making it easier to identify the owner of the backup tapes and easier to define tape management rules for those tapes.
If you are restoring the data sets at your home site, you can simply reference the proper generation of Application Control File (usually “(0)” to restore the latest backup) and Application Restore will restore every data set recorded in it. If you are restoring at a disaster site, you must first restore the latest copy of the Application Control File. You may also need to do so if you are restoring from other than the current backup, or if the copies of the ACF on DASD have been lost. You have two options for doing this:
1.You can back up and restore the Application Control File independently of the Application Backup process. One way to do this is to back up the Application Control Files for all applications using ABR Volume Backups, with full-volume and incremental backups. This means that the Application Control Files must be on volumes that are backed up by ABR Volume Backups, and which are recovered using ABR volume recovery or data set restore (see Working-with-FDRABR-Volume-Backups) before doing any Application Restore.
2.Unless you specify ARCBACKUP=NO during the Application Backup, FDRAPPL automatically backs up the Application Control File used as the last file on the backup tapes, and catalogs that backup file (the backup file should also be a GDG to make it easier to recover it from various levels). You can restore the Application Control File from that backup, and then use it to restore the application data sets
To successfully restore at a disaster site, you must first restore all system catalogs that are involved, including the catalogs for the application data sets, and the catalogs in which the Application Backups themselves are cataloged (based on the names of the Application Control File and the ARCB1DSN=/ARCB2DSN= operands).
Here are the steps required to implement FDRAPPL for a given application with a GDG ACF:
- Create the GDG bases for the Application Control File and the backups of the Application Control File.
Build job steps that execute backups for the application. Each step will create a new generation of the ACF. You may want to convert these into cataloged procedures (PROCs) that can be executed by many different applications, with symbolic parameters for data set names and other values. These steps can be inserted into application job streams, or can be run as separate jobs in the application cycle.
- Build job steps that can be used to restore data sets from the backups. These may also be converted into cataloged procedures. You may need separate job steps to restore the Application Control File from the backup on tape before you restore the application data sets. You may need separate procedures for on site and off site (disaster) restores.
Examples of all of these steps follow. In the sample JCL shown, you may need to modify data set names, unit names, and other parameters to meet local requirements.
Create GDG bases in catalog example
For each application, you must execute this IDCAMS step one time to create the GDG bases used by that application. Every application using FDRAPPL must have a unique set of GDG bases for each Application Control File it uses. This example creates the GDG bases required by the following examples. It creates the DASD Application Control File GDG with a limit of one generation, so that only the most recent version is kept on DASD, but the tape backup GDGs have a limit of five, to keep five generations of the backup of the ACF. Change these values to suit the application's backup and recovery requirements.
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DEFINE GDG(NAME(PAYROLL.APPL.BACKUP) LIMIT(1) SCRATCH)
DEFINE GDG(NAME(PAYROLL.APPL.ACFBKP1) LIMIT(5))
DEFINE GDG(NAME(PAYROLL.APPL.ACFBKP2) LIMIT(5))
/*
FDRAPPL with ARCBACKUP example
This is an example of an FDRAPPL job stream that includes a backup of the Application Control File GDG as the last file on the backup tape. ARCBACKUP=DSF is the default with TYPE=APPL and does not need to be specified.
The ARCHIVE DD statement creates the Application Control File for this backup step on DASD.
Since both TAPE1 and TAPE11 DD statements are present, two copies of the backup are created, so that one can be sent off site. The names of the backup tape files created start with the high-level index of the ACF (PAYROLL), but the rest of the name is controlled by FDRAPPL, as shown in “Tape Format and Naming Conventions” in FDRAPPL-introduction. These files are not cataloged even though the JCL specifies EXPDT=99000 (catalog control for many tape management systems).
The ARCB1DSN= and ARCB2DSN= operands are included to specify the name of the tape file which will contain the Application Control File backup; they are GDGs so that multiple copies of the backup can be tracked. FDRAPPL will create and catalog these files internally, as the last file on each of the output tapes. Since they are cataloged and under catalog control, your tape management system will retain the entire tape set until the ACF backup generation is deleted (rolls out of the GDG).
All cataloged data sets matching the SELECT statements are backed up.
//SYSPRINT DD SYSOUT=*
//SYSPRIN1 DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//ARCHIVE DD DSN=PAYROLL.APPL.BACKUP(+1),DISP=(NEW,CATLG),
// UNIT=SYSALLDA,SPACE=(TRK,(10,5),RLSE) (see "Note")
//TAPE1 DD DSN=PAYBKUP.APPL1,UNIT=CART,DISP=(,KEEP),
// VOL=(,,,255),EXPDT=99000
//TAPE11 DD DSN=PAYBKUP.APPL2,UNIT=CART,DISP=(,KEEP),
// VOL=(,,,255),EXPDT=99000
//SYSIN DD *
DUMP TYPE=APPL,ARCB1DSN=PAYROLL.APPL.ACFBKP1(+1),
ARCB2DSN=PAYROLL.APPL.ACFBKP2(+1),RTC=YES
SELECT CATDSN=PAYROLL.**
SELECT CATDSN=HOURLY.PAY*.**
/*
FDRAPPL without ARCBACKUP example
This is an example of an FDRAPPL job stream that does not backup the GDG Application Control File. If the Application Control File is required at a disaster site, it must be recovered by another means.
Since only TAPE1 is present, only one copy of the backup is created. The names of the backup tape files created start with the high-level index of the Application Control File, but the rest of the name is controlled by FDRAPPL, as shown in Tape Format and Naming Conventions. These files are cataloged (ARCCAT=ALL). They are retained for 30 days; the tape is expired by your tape management system at that time.
All cataloged data sets matching the SELECT are backed up. Because of CATLIMITGDG=1, for any GDGs that match the SELECT, only the current (0) generation is selected; the operand does not affect non-GDGs, they are all backed up.
//BACKUP EXEC PGM=FDRABR,REGION=0M //SYSPRINT DD SYSOUT=* //SYSPRIN1 DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //ARCHIVE DD DSN=PAYROLL.APPL.BACKUP(+1),DISP=(,CATLG), // UNIT=SYSALLDA,SPACE=(TRK,(10,5),RLSE) (see "Note") //TAPE1 DD DSN=PAYBKUP.APPL,UNIT=3590,DISP=(,KEEP), // VOL=(,,,255),RETPD=30 //SYSIN DD * DUMP TYPE=APPL,ARCBACKUP=NO,ARCCAT=ALL,RTC=YES SELECT CATDSN=HOURLY.PAY*.**,CATLIMITGDG=1 /*
Backup only allocation example
Sometimes you need to allocate certain application data sets at a disaster site, but plan to restore their contents by another means. For example, you might plan to recover some databases with a database recovery utility, but that utility needs to have the databases preallocated. FDRAPPL can do this with the DATA=NONE operand.
When DATA=NONE is specified on a SELECT statement, FDRAPPL backs up only the description of the data set, sufficient to allocate it, but does not back up any data tracks. When restoring the data sets, DATA=NONE must also be specified on the SELECT statement so that FDRAPPL does not attempt to restore the missing data tracks. For this reason, it is easiest to dump the DATA=NONE data sets into a separate Application Control File, as shown here.
Since this backup is normally required at a disaster site, COPY1=COPY2 is used to create only COPY2 using the TAPE1 DD statement; all COPY2s, including those for regular Application Backups, can be sent off site.
It is possible to include DATA=NONE allocation-only backups in the same backup as regular Application Backups. In this case be sure to put the SELECT statements with DATA=NONE before other SELECT statements, if they are a subset, and be sure to include similar SELECT statements in the restore jobs.
The Application Restore job streams shown in this section is used to restore these allocations, except that DATA=NONE must be added to the SELECT.
//SYSPRINT DD SYSOUT=*
//SYSPRIN1 DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//ARCHIVE DD DSN=PAYROLL.ALLOC.BACKUP(+1),DISP=(,CATLG),
// UNIT=SYSALLDA,SPACE=(TRK,(10,5),RLSE) (see "Note")
//TAPE1 DD DSN=PAYBKUP.ALLOC1,UNIT=3590,DISP=(,KEEP),
// VOL=(,,,255)
//SYSIN DD *
DUMP TYPE=APPL,ARCB1DSN=PAYROLL.ALLOC1.BACKUP2(+1),
RETPD=14,COPY1=COPY2,RTC=YES
SELECT CATDSN=PAYROLL.DB.**,DATA=NONE
/*
Restoring application data sets example
This is the job step necessary to restore all of the data sets that were backed up for an application. It can be used at your home site or with slight modifications at a disaster site. It assumes that the required Application Control File is on DASD; at a disaster site, you need to recover the ACF before running this restore step (see Restoring the ACF and Application Data Sets Example).
It restores the backup for every data set recorded in the most recent generation of the Application Control File. By default, it attempts to restore every data set to its original DASD volume. If it cannot be allocated there, the ABR Restore Allocation List, if enabled, can specify alternate volumes (see Panel A.I.6.1 Restore Allocation List). The data sets do not need to be deleted or reallocated; FDRAPPL simply restores over them if they exist.
If you are restoring at a disaster site, you may need to add COPY=2 to the RESTORE or SELECT statement if COPY2 is your off site copy. However, your installation may modify the FDR Global Options to make COPY2 the default for off site restores.
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//ARCHIVE DD DSN=PAYROLL.APPL.BACKUP(0),DISP=SHR
//SYSIN DD *
RESTORE TYPE=APPL,RECAT,VRECAT,DYNTAPE
SELECT ALLDSN
/*
Restoring the ACF and application data sets example
If the Application Control File required is not already on DASD, as it might be a disaster site, or when you need to restore from other than the most recent backup, this two-step procedure can be used to restore the ACF, and then to restore the application data sets recorded in it. The input tape is mounted only once unless the backup used multiple tape volumes.
This job stream assumes that you have already restored the catalogs into which the backup of the Application Control File was cataloged. (If not, it is possible to restore the Application Control File by specifying DSN=, and VOL=SER= and UNIT= and LABEL=, if that information is available at the recovery site).
This example restores the COPY2 backup of the ACF, plus the COPY2 backups of all the application files; this is usually used at a disaster site, since COPY2 is usually sent off site.
Since the Application Control File is backed up in FDRDSF format, FDRDSF is used to restore it. This example restores it to its original volume, and allocates it there if necessary. It is restored to generation +1 but it is referred to as generation 0 in the RESTAPPL step. If the original volume is not available, you may need to specify the NVOL= operand to specify a new target volume.
See the previous example for notes on the application restore step.
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//TAPE1 DD DSN=PAYROLL.APPL.ACFBKP2(0),DISP=(OLD,PASS)
//SYSIN DD *
RESTORE TYPE=DSF,RECAT
SELECT DSN=PAYROLL.APPL.**,CATNEWN=PAYROLL.APPL.BACKUP(+1)
/*
//RESTAPPL EXEC PGM=FDRABR,REGION=0M
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//ARCHIVE DD DSN=PAYROLL.APPL.BACKUP(0),DISP=SHR
//TAPE1 DD DSN=PAYROLL.APPL.ACFBKP2(0),DISP=(OLD,KEEP)
//SYSIN DD *
RESTORE TYPE=APPL,RECAT,VRECAT,COPY=2
SELECT ALLDSN
/*