
|
As with all modules in the FDR DASD Management Family, the JCL and Control
Statements required to execute FDRAPPL are very straight-forward and easy
to use. This section contains basic examples of a backup job and a restore
job, just to illustrate how simple it is to use FDRAPPL to secure your applications.
Here is a simple example of an FDRAPPL job to backup an entire “payroll” application.
//BACKUP EXEC PGM=FDRABR,REGION=0M
//SYSPRINT DD SYSOUT=*
//ARCHIVE DD DSN=PAYROLL.APPL.BACKUP,DISP=SHR
//TAPE1 DD DSN=PAYBKUP.APPL1,UNIT=3490,DISP=(,KEEP),VOL=(,,,255)
//SYSIN DD *
DUMP TYPE=APPL,ARCB1DSN=PAYROLL.APPL.ACFBKP1(+1),RETPD=14,ARCCAT=ALL
SELECT CATDSN=PAYROLL.**
|
- The SELECT CATDSN statement is telling FDRAPPL to locate (via the MVS catalogs)
all datasets with a high-level qualifier of “PAYROLL”.
- The ARCHIVE DD statement points to a control file (called PAYROLL.APPL.BACKUP)
where details of the backup will be recorded, such as the names of the datasets
that were backed up and the media they were backed up to.
- The backup will be written to 3490 tape, as directed by the TAPE1 DD statement.
- The DSN on the TAPE1 is a dummy name; another default has been taken so that
FDRAPPL will use the same name for the backup as was used for the control file,
with an additional suffix.
- The backup will be cataloged (ARCCAT=ALL) and retained for 14 days (RETPD=14).
- By default, a copy of the control file will be backed up as the last file on the tape.
- The ARCBnDSN operand on the main DUMP statement specifies the name that
will be used for the backup of the control file. In this example,
that backup filename has been previously set up as a GDG, allowing
multiple copies of the backup to be tracked.
Using this simple job, with a single control statement, you could backup an
entire application, which could consist of many thousands of datasets,
potentially spread across numerous disk volumes.
If additional datasets were added to the application at a later date,
assuming those datasets also had a high-level qualifier of “payroll”,
they would automatically be included in the backup job, without the
need to change the JCL or control statements.
Likewise, if datasets were removed from the application, the backup job
would not need to be updated to reflect this change, as the deleted and
uncataloged datasets would not get selected via the catalog-based search
criteria.
Here is a simple example of an FDRAPPL job to restore all the files belonging
to the PAYROLL application that we backed up in the previous example.
//RESTAPPL EXEC PGM=FDRABR,REGION=0M
//SYSPRINT DD SYSOUT=*
//ARCHIVE DD DSN=PAYROLL.APPL.BACKUP,DISP=SHR
//SYSIN DD *
RESTORE TYPE=APPL,RECAT,VRECAT,DYNTAPE
SELECT ALLDSN
|
- The ALLDSN on the select statement is requesting that all datasets
that were backup up should be restored – allowing the whole application
to be restored with just a single SELECT statement.
- In the event that the whole application is not required, FDRAPPL's
powerful select/exclude criteria allow individual (or groups) of datasets
to be selected or excluded from the restore.
- The ARCHIVE DD statement directs FDRAPPL to the disk-based copy of
the control file that was used to store details of the backup. If this
were a disaster recovery situation, a copy of the control file that
was placed on the end of the backup tape would first be restored to
disk, and then used as input to this job.
- The DYNTAPE operand on the RESTORE statement tells FDRAPPL to automatically
obtain details of the backup media from the control file. This means that the
restore job does not need to include information regarding the tape media or
volser(s) that were used in the backup.
- As a default, FDRAPPL will attempt to restore (and recatalog) each
dataset to its original disk volume, replacing the dataset if it already
exists on that volume. If this is not possible (e.g. the volume is full
or does it not exist on the restoring system), FDRAPPL can refer to a ‘Restore
Allocation List’ for alternate volumes.
- If the datasets fall under the control of DFSMS and they don't
already exist on the restoring system, DFSMS may have some influence
over where the datasets get restored to.
- By default, the most recent copy of each dataset will be restored.
However, if multiple backups have been recorded in the control file,
additional operands can be used on the SELECT statement to restore
older copies of a dataset.
Using this simple job, and with a single control statement, you could restore an
entire application, which may have consisted of many thousands of datasets,
potentially spread across numerous disk volumes.
The use of the ALLDSN operand means that there is no need to provide details
of each individual dataset to be restored.
The DYNTAPE operand removes the need to supply details of the media and
volser(s) that were used to hold the backup.
return to top
|
|
|
| Can we HELP you... |
|
Looking for more information?
|
|