ABR Auto-Recall – Introduction

ABR Auto-Recall – Introduction

As described in ABR Archive Backup in Introduction-to-FDRABR-Archiving-and-Superscratch, ABR Archive Backups can select data sets from DASD and move them to a less expensive medium such as tape or compressed DASD. The usual criteria for the selection of data sets to be archived is the Last Reference Date of each data set, selecting data sets that have not been used recently.

However, no matter what criteria you use for selection, some of those archived data sets will eventually be required by jobs or TSO users. This might be due to jobs that run at infrequent intervals, test data sets for applications that have not been tested recently, TSO libraries which are infrequently used, or TSO users who have not logged on recently.

It is possible to manually restore archived data sets as described in Archive Restore Procedure in Archive-RESTORE-statement, if you can predict which data sets are required. However, it is much more convenient if the required data sets are automatically restored when they are needed, transparent to the requesting task. This is the function of ABR Automatic Recall (Auto-Recall). When properly implemented, Auto-Recall dynamically recalls archived data sets referenced by:

• DD statements in JCL. This includes batch jobs, started task JCL, and TSO startup PROCs. Archived data sets are recalled at the beginning of each step, before the job step program gets control; all archived data sets in the step are usually recalled at one time. The step is delayed until the recall is complete, so when the program executes all required data sets have been placed back on DASD. Other than ABR recall messages in the job log, the job is unaware that they were ever archived.
• Dynamic allocation by a batch job, started task or TSO user. For a batch job, the data set being allocated is recalled immediately; the allocation will wait until the recall is complete. For a TSO user, the user is notified that an archived data set is requested, and given the choice of exiting, waiting for the recall to complete, or recalling the data set without waiting, allowing other work to be done while the recall is proceeding. You can customize ABR to limit or eliminate these choices.

Auto-Recall is performed by two Operating System exits that are supplied with the ABR system: the ABR Catalog Locate exit and the Data Set Not Found exit. See Operating-System-Exit-Options-for-FDRABR-and-FDRREORG and ISPF panel A.I.4.11 for installation and customization of these exits.

ABR catalog locate exit

The ABR Catalog Locate exit intercepts catalog requests (such as LOCATE SVCs) issued by system components (such as JCL allocation and dynamic allocation), TSO components and programs, third-party software and even user-written programs. If the requested data set is cataloged, and the catalog entry indicates that the data set has been archived with the RECALL option, then the ABR Catalog Locate exit arranges for FDRABR to restore the data set. The ABR Catalog Locate exit may invoke FDRABR directly within the address space requesting the data set, or may issue a START command to invoke FDRABR in a separate address space, or may place the restore request into the remote queue data set to be performed along with other archive restores. Details appear in the following sections.

Data set not found exit

The Data Set Not Found exit receives control when a program issues an OPEN for a DASD data set and OPEN cannot find that data set in the VTOC of the volume specified. Since the ABR Catalog Locate exit recalls data sets when a catalog LOCATE is done for them, they are normally recalled long before OPEN is done. So, this exit is usually invoked only when a volume serial is specified in batch JCL, since the catalog search is not done. For example:

The Data Set Not Found exit always invokes FDRABR in the address space of the job issuing OPEN to see if the data set has been archived (recorded in the Archive Control File as having been archived from the volume involved); the data set need not be cataloged for auto-recall. If it was archived, it is recalled to that volume and opened. If ABR does not find it, OPEN issues a normal S213-04 abend as if ABR was never involved. If FDRABR internally abends during the recall, OPEN issues an S213-2C abend.

Many users think that this means that an ABR error has occurred, but in fact, this simply means that the data set being opened has not been archived. The S213-04 abend means that the data set was truly not found on DASD. This could be due to a misspelling of the data set name or the wrong volume serial. This also occurs if a DD statement points to a VSAM cluster, but a non-VSAM OPEN is being done by the program.

Archive control file

Auto-Recall requires that all recallable data sets be recorded in a common Archive Control File, whose name is specified in the FDR Global Options. This Archive Control File is dynamically allocated and searched for all Auto-Recall requests.

Recall indicator

When a data set is archived with RECALL=NO, its catalog entry is deleted (for multi-volume data sets, this is done when all pieces of the data set have been archived).

But when a data set is archived for auto-recall (the RECALL=YES operand specified or defaulted), archived data sets remain cataloged, with a special indicator in the catalog entry that tells the ABR Catalog Locate exit (see below) that the data set is recallable. This indicator also includes an index into the Archive Control File so that recalls can begin reading the control file near the record for the data set, rather than scanning the entire file.

For single-volume data sets, this indicator is stored in a catalog field called DSCBTTR. For data sets on DASD, this field often points to the F1 DSCB of the data set, to speed up OPEN processing. Since there is no DSCB for archived data sets, ABR uses it to store the auto-recall information. DSCBTTR is not displayed by LISTCAT and similar catalog list programs, but FDREPORT Working-with-FDREPORT) can do so.

For multi-volume data sets, since each piece could be archived separately, the auto-recall indicator is stored in the File Sequence field of each volume in the catalog entry. The ABR Catalog Locate exit recalls only the pieces that are marked for auto-recall. LISTCAT displays the File Sequence field in decimal, so you may see some large values; this is normal.

For VSAM clusters, the VSAM catalog entry is deleted when the cluster is archived, and a non-VSAM catalog entry is built with the name of the cluster, the volumes it was archived from, and the auto-recall indicator. For DB2 files, the data component name is also cataloged for Auto-Recall, since DB2 may refer to the component name. For multi-volume VSAM, the cluster is not deleted until the cluster has been archived from every DASD volume on which it resides, so the non-VSAM entry is built when the cluster is finally deleted, with all the volumes and auto-recall indicators set. To properly archive multi-volume VSAM, all volumes containing pieces of the cluster must be processed in the same ABR run.

RECALL=YES can be made the default by setting ARCRECALL to “YES” in the FDR Global Options (see ABR-Options). This is recommended if you plan to archive all or most data sets for Auto-Recall. RECALL=NO can override it for specific jobs.

MIGRAT option

ABR has an option to change the first volume serial in the catalog entry for an archived data set to MIGRAT (except for multi-volume VSAM clusters); this is the indicator used by IBM to indicate that a data set has been migrated (archived) by DFSMShsm. ABR supports the MIGRAT volume serial number so that users can more easily identify archived data sets from a LISTCAT or other data set display. Because of checks in IBM code for the MIGRAT volume serial, it also avoids some errors that can occur since IBM does not recognize our auto-recall indicator.

When RECALL=YES is used, MIGRAT=YES can also be specified (or defaulted in the FDR Global Options with the MIGRAT option in ABR-Options) to change the first or only volume serial to MIGRAT. MIGRAT=YES is ignored when multi-volume VSAM clusters are archived.