ABR Auto-Recall – DFSMShsm Compatibility

ABR Auto-Recall is designed to be compatible with DFSMShsm (the Hierarchal Storage Manager component of z/OS). In addition, if both FDRABR and DFSMShsm are active on a system, FDRABR coexists with DFSMShsm, with each product performing recalls for only the data sets that have been archived/migrated by that product.

DFSMShsm compatibility

If the ABR option MIGRAT=YES is used for Archive Backups, then data sets archived for recall are recataloged to a volume serial number of MIGRAT, just as DFSMShsm does, as well as having the normal FDRABR Archive indicators in the catalog entry. The ABR Catalog Locate exit properly recalls data sets cataloged to MIGRAT in most cases, but some software products test for a volume serial number of MIGRAT and issue a direct DFSMShsm request for the recall (the HRECALL command, or the DFSMShsm ARCHRCAL macro, or the DFSMShsm SVC); such products include:

DB2
Network File System Server (NFSS)
JES2 (for archived JCLLIBs (user procedure libraries))
and others.

ABR provides two modules to handle these requests:

FDR00024

a front-end to the DFSMShsm SVC. When it is entered, it tests to see if the requested data set was really archived by FDRABR and invokes FDRABR to recall it. Other requests are passed to DFSMShsm if it is active.

FDRGIVER

an alternative to the IBM ARCGIVER module. ARCGIVER is an DFSMShsm module invoked by the ARCHRCAL macro and other DFSMShsm macros; when invoked it issues the DFSMShsm SVC to request DFSMShsm services. FDRGIVER does the same except that it only handles recall and delete requests, allowing FDRABR to handle DFSMShsm requests issued by other programs.

If the ABR Catalog Locate exit is being dynamically installed (as described in Dynamic-Installation-of-the-FDR-Exits), FDRABR also dynamically installs the DFSMShsm SVC front-end, FDR00024. If there is no other module called ARCGIVER in the system, FDRABR also installs FDRGIVER in place of ARCGIVER. With these modules in place, archived data sets are recalled even for programs which issue direct DFSMShsm requests.

These modules also handle DFSMShsm delete requests (for example, the HDELETE command) for ABR archived data sets by uncataloging them.

Other DFSMShsm requests (migrate, restore, and so on) are passed to DFSMShsm, if it is active.

DFSMShsm coexistence

The DFSMShsm SVC front-end, plus code in the ABR Catalog Locate exit, allows ABR to coexist with DFSMShsm when both products are active, even when the ABR MIGRAT=YES option is used (so that both DFSMShsm and ABR catalog archived and migrated data sets to volume serial number MIGRAT).

When DFSMShsm is installed (even if it is not active), the DFSMShsm version of the ARCGIVER module is used. Since all requests to ARCGIVER are translated into the DFSMShsm SVC, the DFSMShsm SVC front-end identifies which system archived a given data set and passes the recall or delete request to FDRABR or DFSMShsm.

The result is that data sets archived by FDRABR are recalled by FDRABR, and those migrated by DFSMShsm are recalled by DFSMShsm.

Message ARC1020I

TSO users may receive an annoying DFSMShsm message when they reference a data set that has been archived for recall by FDRABR:

ARC1020I DFSMShsm IS RECALLING FROM DASD DSN=dsname

Even though FDRABR is actually performing the recall. This message causes no harm, but it often confuses users.

This message is produced by the DFSMShsm Locate exit, which is included in all operating systems whether or not the installation has ordered or is using DFSMShsm. Member ASM026DU in the Installation Control Library (ICL) is a job stream that replaces this IBM-provided exit with a dummy exit.

Warning

You must not install the dummy exit if you are using DFSMShsm to migrate and recall data sets, or have plans to do so.

Incompatibility considerations

On any one volume, only one DASD management system that performs incremental backup can be used, either FDRABR or DFSMShsm. Both FDRABR and DFSMShsm depend on the UPDATE bit, and the two systems interfere with each other if both are used on the same volume. In addition, DFSMShsm does not maintain the reserved bytes in the DSCB that FDRABR uses (nor does DFSMSdss), so if you do DFSMShsm recall to a given volume (or DFSMShsm recover, or DFSMSdss RESTORE or COPY, or DFSMSdss DEFRAG), it destroys the validity of FDRABR full-volume RESTORE.