ABR and Tape Management Systems
Tape management systems
In most cases, ABR is used with no explicit interface to any tape management system, so ABR does not directly control the retention and expiration of tapes created by ABR. However, ABR can indirectly influence the actions of tape management systems on ABR tapes by the expiration dates passed to the tape management systems when the tape files are originally opened by ABR, and by uncataloging tapes. This section describes the options that are available.
The tape management systems commonly used by ABR customers are:
- CA 1 (also known as TMS and CA ONE), from Broadcom.
- CA TLMS (usually called just TLMS), also from Broadcom.
- DFSMSrmm (Removable Media Manager, often called just RMM) from IBM.
- CONTROL-M/Tape (formerly known as CONTROL-T) from BMC.
- ASG-ZARA (sometimes called AutoMedia) from ASG Software Solutions.
With these tape management systems, it is possible to define ABR Archive as an EDM (External Data Manager), where ABR calls a tape management interface to cause tapes to be expired. This is described later in this section (see External Data Manager (EDM)).
ABR can be used successfully with these systems, with other tape management systems, or with no tape management software at all.
In this section, when we refer to TMS, we mean all tape management systems, not just CA 1.
There is information on Backup Retention and Tape Management in each of the three ABR sections of this manual:
ABR Volume Backups (Backup Retention and Tape Management in FDRABR-Volume-Backups-introduction)
ABR Archive Backups (Backup Retention and Tape Management in Introduction-to-FDRABR-Archiving-and-Superscratch)
ABR Application Backups (Backup Retention and Tape Management in FDRAPPL-introduction).
You should read these when you are designing the backup retention rules for a particular type of backup. This section provides additional information and relevant ABR options.
TMS option
If you have any vendor’s tape management system and also use ABR, you must let ABR know by activating the TMS option in the FDR Global Options. The TMS option has absolutely no effect unless you have ABR; ABR needs to know if there is tape management in the operating system.
With the TMS option enabled, ABR changes the techniques it uses to create LASTAPE files on tape (the LASTAPE option of ABR) and to call for a fresh scratch tape when the maximum file number on tape (MAXFILE=) is exceeded.
In the FDRARCH utility, the TMS option causes a REORG to uncatalog expired Archive Backups only if they are recorded as having an expiration date off 1999.000 (99000) that indicates catalog control in many tape management systems. However, if you want to uncatalog all expired Archive Backups, you can temporarily override the TMS option on an FDRARCH statement (DISABLE=TMS).
Retention techniques
There are two techniques generally used by tape management systems for ABR tapes. The first is “date control”, where an explicit expiration date is assigned to the tape data set. The other is “catalog control”, where the data set is retained as long as it is still in a system catalog such as the ABR catalog.
Some other retention techniques supported by tape management may work with ABR, but another common tape management technique, “cycle control”, does not work for ABR tapes. Cycle control only works for data sets that have the same name every time they are created; ABR backups are usually assigned unique data set names.
In all tape management systems, the assignment of an expiration date or retention technique to tape data sets can be controlled in several ways:
1.The common technique (supported since the early days of tape management) is to use the JCL keywords RETPD= (retention by number of days) and EXPDT= (for explicit expiration dates) to invoke date control. EXPDT= is also used to assign special retention techniques (for example, EXPDT=99000 for catalog control) but this function may be disabled in some tape management systems.
2.Some tape management systems now use other JCL keywords (such as ACCODE= for CA 1) to indicate retention techniques.
3.A “rules” data set can assign expiration information to a data set. This allows installations to implement tape management without having to update all of their JCL. The “rules” data set might even be able to override expirations set in JCL or by the program.
The details of these vary by tape management system. Please consult your vendor's documentation for details.
Methods (1) and (2) are usually used by ABR. They have the advantage that ABR knows the actual expiration date or retention method used to manage each backup file. In many cases, ABR saves and does processing based on that information.
Method (3) has the disadvantage that ABR does not know the actual expiration date or retention technique. If you use this method, you may need to manually update ABR with the equivalent information, so it is not recommended.
Date control
When ABR creates a tape data set, an expiration date is passed to OPEN, where it is intercepted by your tape management system. Expiration dates may come from several sources:
- The user may specify a retention period via the RETPD= operand on an ABR DUMP statement. ABR adds that value to today's date to calculate the expiration date.
- The RETPD= (retention period) or EXPDT= (explicit expiration date) operands may be specified on the TAPEx and TAPExx DD statements. For RETPD=, IBM adds the value to today’s date to calculate the expiration date.
- If neither of the above, ABR uses a default RETPD= value to calculate the expiration date.
For all tape management systems, the tape is retained until that expiration date is reached.
Date control can also be used on systems with no tape management software, since OPEN writes the specified expiration date in the header labels of each tape data. When no tape management system is involved, OPEN does not let a tape containing an unexpired data set as the first file to be used for output unless the system operator replies to a console message.
Date control can be used with all ABR backup types, but remember that ABR only records the date if it is specified on the ABR DUMP statement or the TAPE DD statements.
Permanent retention
You may occasionally want to create an ABR backup which is to be kept permanently (at least until someone manually expires it). To do so, specify EXPDT=99365 or 99366 on the TAPEx or TAPExx DD statement. All tape management systems treat this as permanent retention, as does ABR itself.
Catalog control
Catalog control retains an ABR tape data set as long as the data set is still in a system catalog (such as the ABR catalog). Working-with-FDRABR-Volume-Backups, FDRABR Archiving and Superscratch, and FDRAPPL - Application Backup explain the rules for cataloging each type of ABR backup.
For most tape management systems, catalog control is specified by EXPDT=99000 on the TAPEx or TAPExx DD statement. Check your vendor’s documentation for the setup necessary to make your tape management system accept EXPDT=99000.
When ABR has recorded the expiration of a backup as 99000, it takes special action for that backup. For example, when you do an FDRARCH REORG on the Archive Control File, it uncatalogs backups that no longer have any references in the ACF, but only if the recorded expiration is 99000. So, even if you are invoking catalog control by another means (such as ACCODE= or a “rules” data set), you should also specify EXPDT=99000 so that ABR knows about it.
Uncataloging by tape management systems
When you use date control with your tape management system, the TMS may uncatalog tape data sets when the tapes expire. This is usually an option, so you should consult the vendor's documentation. If possible, this option should be enabled so that obsolete ABR backups are uncataloged.
As explained in FDRABR Volume Backups, FDRABR Archiving and Superscratch, and Working-with-FDRAPPL , ABR also includes code to uncatalog backup tapes when they expire. Whichever system attempts first to uncatalog a given tape data set succeeds, and the other system fails. Neither system considers this a problem.
In some cases, ABR does not attempt to uncatalog a backup tape until long after it expired. For example, if you keep five (5) generations of an ABR full-volume backup, but assign RETPD=14 to the daily incremental backups, the incremental backups expire in two (2) weeks but ABR does not uncatalog them until three (3) more generations have been created (five (5) weeks total). These cataloged but expired incremental backups continue to appear on ABR reports, but any attempt to restore from them fails. The solution is to enable the option allowing your TMS to uncatalog them.
Multi-file tapes
ABR usually puts more than one file onto each tape volume; it creates one tape file for each DASD volume that is backed up in a given ABR step. In some cases, the tape files on one tape may have varying expiration dates.
The LASTAPE feature of ABR provides a method of improving tape utilization by allowing you to add tape files onto tapes that were created in a previous ABR step or job. LASTAPE is most useful if each ABR run uses a relatively small amount of tape, so it is most often used for Archiving. If you do not use LASTAPE, then each run of ABR calls for fresh scratch tapes. However, LASTAPE is likely to create tape files with varying expirations.
CA 1 handles multi-expiration tapes automatically; it does not expire any tape volume until all files on that tape have reached their expirations (including catalog control).
CA TLMS V5.5 introduced new retention types (A, B, and C) that causes tapes to be retained until all files on the tape have reached their expiration, similar to the way that CA 1 operates. These retention types are recommended for ABR-created tapes. If these retention types are not used, see member TLMSXTRS in the FDR Installation FDRSAMP for information on an exit you may need to install.
DFSMSrmm handles expiration of multi-file tapes individually by file, so it retains each file until it reaches its expiration. A tape volume becomes scratch when all files on it have expired.
Multi-volume multi-file aggregates
ABR may also create multi-volume multi-file aggregates (sometimes called “tape sets”) on tape. An ABR aggregate may have up to 65534 files and may occupy an indefinite number of tape volumes, although the number of tape volumes used for an individual backup file is limited to 19.
CA 1 CA TLMS, and CONTROL-M/Tape handle such aggregates automatically. All of the volumes in an aggregate are retained or expired as a unit, all at once.
DFSMSrmm, since it expires individual files, may return a tape to scratch status when all files on it have expired, even though it is part of a multi-volume aggregate. In z/OS, DFSMSrmm has an option to retain and expire multi-volume aggregates as a unit; you should enable this option for proper retention of tapes created by ABR.
Varying expirations
Many installations wish to create monthly, quarterly, or yearly Volume Backups that are to be kept for a longer period than the normal ABR backup or to keep the full-volume backups for a longer period than their associated incremental backups. With a tape management system, this is easy.
Each DASD volume should be initialized to retain a number of ABR generations equivalent to the longest backup you plan to keep; this prevents ABR from uncataloging any backup that is still available for restores. For example, if you create weekly full-volume backups, and you plan to keep certain backups for one year, set each volume to keep 52 or 53 generations.
Specify the proper retention on each ABR backup job. To expire daily incremental backups early, specify the proper RETPD=nn in the daily job, either on the DUMP statement or the TAPE DD statement (we recommend a minimum retention of 14 days or two generations). Your normal full-volume backup job can specify the usual retention (for example, 35 days for monthly retention), but special full-volume backup jobs can replace the normal job when you want to create long-term retention backups, specifying the proper RETPD= value. Alternately, you can use a tape management utility to extend the retention of certain backups. ABR does not care when they expire as long as they are still cataloged; the tape management system uncatalogs backups that reach their expiration.
ABR can restore data sets from any backup that is still in the ABR catalog. However, the OLDBACKUP= operand of ABR only tracks the most recently created backups of a data set (up to 14), even if they have expired. So recovery from older backup tapes may require reviewing the ABR dump listings, or FDRABRM PRINT BACKUP reports (see FDRABRP-Data-Set-Backup-Report) to find the required backup of a specific data set, and specifying the VOL=, GEN=, and CYCLE= operands on the SELECT statement or on the ABR ISPF panels.
Vaulting
How do you tell the Tape Management System to select ABR backup tapes for off-site vaulting? ABR backups always have a specific naming convention. It is described in detail in Tape Format and Naming Conventions in Section FDRABR-Volume-Backups-introduction, Introduction-to-FDRABR-Archiving-and-Superscratch, and FDRAPPL-introduction, but briefly it is:
FDRABR.Vvolser.Bnyyyyyx for Archive Backups (“B” can also be “D” through “J”)
userindx.Vvolser.Bnyyyyyx for Application Backups
The FDRABR high-level index can be changed during the installation of ABR. Application Backups use an application-specified index in place of FDRABR. “volser” is the volume serial of the input DASD, and “n” is the copy number (1 through 9).
In general, you want to send COPY2 of most backups to the off-site vault. The details of how to do this vary by tape management system; consult the vendor's documentation.
Most tape management systems allow you to specify a data set name prefix for vaulting selection. For ABR backups, you may need to define a rule for backups from each DASD volume, for example,
FDRABR.VPROD01.C2 FDRABR.VPROD02.C2
Change C2 to B2 to select Archive Backups.
If your TMS supports masking for vault selection, you may be able to specify something like
to select COPY2 of any Volume Backup (full and incremental) for any volume. Check your TMS documentation for details.
Only full-volume backups off-site
Many installations decide not to devote the resources that it takes to keep off-site copies of all ABR backups. They may decide that if a disaster happens, it is acceptable to recover to the status as of the beginning of the current week. A simple way to set this up is to make duplicate copies of only the full-volume backups, and not the incremental backups, so the vaulting controls shown above select only the full-volume backups. Since some tape management systems allow selection based on creating job name (job name qualification), another option is to run the full-volume backups under a different job name than the incremental backups.
COPY1=COPY2
An installation may want to create just one copy of all of the backups, both incremental and full-volume, but send off-site only the full-volume backups. To do this, they can specify the operand COPY1=COPY2 on the DUMP Command for only the full-volume backups: DUMP TYPE=FDR,COPY1=COPY2 …
COPY1=COPY2 tells ABR that even though the run is creating only one copy, the backup data set names should be in the form FDRABR.Vvolser.C2ggggcc instead of FDRABR.Vvolser.C1ggggcc. The vaulting system would still vault all COPY2 tapes created by ABR backups, but these tapes would only include the full-volume backups (and there would not be any COPY1 for these backups).
External Data Manager
For ABR Archive backups, it is possible to make ABR an External Data Manager (EDM). An External Data Manager takes responsibility for retention of its tapes and notifies the tape management system when a tape can be released (scratched).
For CA 1, CA TLMS, and CONTROL-M/Tape, the main advantage to being an EDM is that the tape management system no longer records information about secondary data sets (beyond the first data set) on the EDM-managed volumes. Because ABR usually creates secondary data sets, and ABR Archive tapes are usually kept for a long time (a year or more), many of these data set records are needed if the Archive backups are not EDM.
There are two steps to the EDM process:
1.The tape data sets to be EDM-controlled must be identified. In the Broadcom products and CONTROL-M/Tape you must update parameters that identify the ABR Archive backups (by data set name, job name, etc.) and assign a EDM name. In DFSMSrmm, there is no special preparation, except that you may need to create a VRS to assign long-term retention to the Archive backups.
2.You must reorganize your Archive Control File periodically with the REORG function of FDRARCH. REORG deletes obsolete entries in the ACF. It maintains a table of tape volume serials referenced by entries in the ACF; when it detects that the last entry for a given serial has been deleted, it calls a tape management exit to scratch the tape.
Identifying the EDM to CA 1 and CA TLMS
You must assign a unique 4-character EDM name to ABR Archive (we suggest “ABRA”) and update a member in the PPOPTION data set so that the ABR Archive job and the FDRARCH REORG job are assigned that EDM. For CA 1, the member name is TMOEDMxx, and for CA TLMS it is CTOEDMxx but the syntax is the same for both (consult the appropriate Broadcom manual for complete details).
Although you can assign EDM status by data set name, the names used by Archive may have a third index starting with B or D-J, but not C. Since there is no exclude ability, this is difficult to do, so we recommend that you do the assignment by job name, or job name plus program name. For example,
EDM=ABRA,JOB=ARCH*,PGM=FDRABR ABR ARCHIVE JOB NAME
EDM=ABRA,JOB=REORG*,PGM=FDRARCH,DD=TMSEDMSC FDRARCH REORG JOB NAME
defines them by job name, and just to be sure that job names do not accidentally match, by program name. Then, in the REORG* jobs specifying FDRARCH, add a DD statement matching the name specified:
Identifying the EDM to CONTROL-M/Tape
You must include a rule so that CONTROL-M/Tape marks the ABR Archive backups as EDM-managed.
Although you can assign EDM status by data set name, the names used by Archive may have a third index starting with B or D-J, but not C. This may be difficult to do, so we recommend that you do the assignment by job name, or job name plus program name. For example,
ON JOBANME=ARCH*
DO RETENTION=EDM
ON PROGRAM=FDRARCH AND
ON JOBNAME=REORG*
DO RETENTION=EDM
defines them by job name, and just to be sure that job names do not accidentally match, by program name.
Setting up DFSMSrmm
No special setup is required for DFSMSrmm, but you should be sure that the tapes created by ABR have a long term or permanent retention by creating a vital record specification (VRS) to assign retention to the ABR Archive tapes, for example,
RMM ADDVRS DSN('**') JOBNAME(job) LOCATION(CURRENT) DAYS COUNT(99999)
The FDRARCH REORG job must be RACF-authorized for READ to these FACILITY-class resources:
STGADMIN.EDG.RELEASE
STGADMIN.EDG.MASTER
EDM use with ASG-ZARA
Contact BMC Corporation or ASG Software Solutions for guidance on setting up ASG-ZARA as an EDM for ABR Archive.
Running ABR ARCHIVE
Run your normal ABR Archive jobs; assignment of the EDM status or VRS retention is automatic. You should assign retention of the ABR Archive tapes by normal means, such as RETPD= on the TAPEx DD statements or the ABR DUMP statement, or EXPDT= on the TAPEx DD statements for special retention such as catalog control (EXPDT=99000). These values are recorded in the Archive Control File but are ignored by the tape management system.
Running FDRARCH REORG
The FDRARCH REORG function selects archived data sets to be deleted based on the parameters you specify, such as those that are past their expiration date or those that are no longer cataloged for auto-recall (see Working-with-FDRABR-Archiving-and-Superscratch for details). As it processes, it maintains a table of Archive tape volume serials, and when it finds that the last entry for a given volume serial number is being deleted, it uncatalogs and scratches the volume.
To enable EDM processing, you must insert a DEFAULT statement before the REORG statement, for example,
DEFAULT EDMEXITNAME=exitname REORG …
The “exitname” must be:
TMSARCTV
for CA 1
ARCTVEXT
for CA TLMS
CTTFDR
for CONTROL-M/Tape (you need to assemble it; contact BMC if you do not have it)
EDGTVEXT
for DFSMSrmm
If the exit module is not in the link list (LNKLST), you must include a STEPLIB DD statement for the library where it resides. For each tape to be scratched, REORG invokes the exit, which scratches the tapes or marks them for release processing the next time that tape management maintenance is done.
Summary
EDM has the most benefit for the CA 1, CA TLMS, and CONTROL-M/Tape tape management systems, where it reduces the number of secondary data set records in the tape management database, for ABR Archive backups. EDM can only be used for Archive backups.
Archives are recorded in the Archive Control File with an expiration date, specified by normal means (usually RETPD=). When all of the backups pointing to a given tape have been expired and deleted from the ACF, FDRARCH REORG invokes a tape management exit to expire the tape.
Tape allocation software
Your installation may have software that influences tape drive allocation. This software is often used when you have a mixture of tape types in your installation, some native tape drives, some in an Automated Tape Library (ATL), or some in a Virtual Tape System (VTS). The tape allocation software can be used to automatically direct output tapes and especially input tapes to the right type of tape drive. Examples of such software include:
- IBM BTLS (Basic Tape Library Support).
- IBM SMS-managed tape.
- Oracle StorageTek HSC (Host Software Component).
However, there may be others as well.
For output tapes, these products may use rules to control which type of tape is used to satisfy a scratch tape request. This allows you to direct certain types of tape data sets to an ATL or VTS and others to native tapes.
If the rules are based on the tape data set name, they work with FDR and FDRDSF backups, but may not work with FDRABR backups. For ABR, the data set name in the TAPEx DD statement is an arbitrary “dummy” name; ABR uses OPEN TYPE=J to override the tape data set name for each data set name processed (as documented in Tape Format and Naming Conventions in Section FDRABR-Volume-Backups-introduction, Introduction-to-FDRABR-Archiving-and-Superscratch, and FDRAPPL-introduction).
In order to get the proper type of output tape allocated, you have several choices:
- On the TAPEx DD statement, code DSN= with a value that causes the allocation rules to select the proper type of tape for this backup
- Code rules that are not based on the data set name. For example, the rules may selected based on the job name, or the program name (PGM=FDRABR)
- You may be able to allocate the proper type of tape drive by specifying an appropriate UNIT=esoteric value, such as UNIT=VTS. Esoteric names are unique to each installation
For ABR restores, when the recommended DYNTAPE option is used, ABR dynamically allocates the actual backup data set name and volume serial, and the tape allocation software should be able to allocate the proper tape drive to read that tape volume.