SMS ABR Support

ABR support

ABR can be run against SMS-managed volumes, as well as non-SMS volumes, even in the same ABR step.

ABR supports those attributes of the SMS management class and storage group that apply to the ABR architecture. However, the SMS attributes were designed by IBM to support the architecture of DFSMShsm; since ABR has a different architecture, some of those attributes do not apply to ABR and are not used. For example, ABR manages retention of backups on a volume level, based on the number of generations or retention assigned for that volume, so the attributes relating to retention of backups are not used. A complete list of the SMS attributes NOT used by ABR appears later in this section.

ABR volume selection

The SMS-managed volumes to be included in an ABR Volume Backup, Archive Backup or Superscratch step can be specified by the normal ABR volume selection (DISKxxxx DD statements, the ONLINE or ONLVOL operands, or MOUNT statements), or all the volumes defined to a SMS storage group can be included using a MOUNT statement with the STORGRP= operand. For example,

MOUNT STORGRP=PRODDB MOUNT STORGRP=TSO

includes all SMS-managed volumes defined in those two storage groups. Both SMS-managed and non-SMS volumes may be selected in the same ABR step.

Regardless of how the SMS-managed volume was selected, it must be properly initialized for ABR processing. The FDRABRM utility (Volume-DUMP-Job-Control-Requirements) or the ABR ISPF dialog (option A.I.8; Set-ABR-Disk-Volume-Processing-Options and FDRABRM-ISPF-Interface) must be used to place an ABR Model DSCB in the VTOC of the SMS-managed volume. On SMS-managed volumes, the ABR Model DSCB is a cataloged data set.

A valid SMS storage class must be assigned to the ABR Model DSCB but it is not used for volume selection since ABR forces the model to the designated volume being initialized. Any valid storage class may be used; management and data classes are not used for ABR Model DSCBs. In your Storage Class ACS routine, you might include code such as:

IF &DSN=’FDRABR.V*’ THEN DO SET &STORCLAS=ABRMODEL (or whatever name you want to assign) EXIT END

This assigns that storage class to all ABR Model DSCBs. You can also change the SET to:

which simply honors whatever storage class the caller specified. This requires that the STORCLAS= operand be specified on the FDRABRM ABRINIT or REMODEL statements. Also, see ““SMS Considerations” in VTOC-Maintenance-Utility-FDRABRM.

ABR uses the ABR Model DSCB and the SMS storage group definition of an SMS-managed volume to determine eligibility for ABR processing. The storage group definition includes flags that indicate if the volumes in the group are eligible for “Auto Migrate”, “Auto Backup”, and/or “Auto Dump”. The definition also includes system names and dump classes, which are not used by ABR.

For full and incremental Volume Backup processing (DUMP TYPE=FDR/ABR/AUTO), the SMS-managed volume must have an ABR Model DSCB and its storage group must indicate that it is enabled for “Auto Backup” and “Auto Dump”. If it is enabled for only “Auto Dump” without “Auto Backup” then the volume is processed only for explicit full-volume backups (DUMP TYPE=FDR) and is bypassed for other ABR backup operations.

For Archive Backup (DUMP TYPE=ARC) and Superscratch (DUMP TYPE=SCR) processing, the ABR Model DSCB must indicate that it is enabled for Archive Backup or Superscratch (as appropriate) and the storage group must indicate that it is enabled for “Auto Migrate”.

Neither the ABR Model DSCB nor the SMS options are used for FDRAPPL Application Backups (DUMP TYPE=APPL). No volume eligibility checks are done for application backups.

Since the options in the ABR Model DSCB essentially duplicate those in the SMS storage group, you can bypass the checks on the storage group and use only the ABR options for eligibility checking by coding the operand SMSCONSTRUCT=NO on the DUMP statement.

ABR management class usage

By default, ABR does not use management class attributes of SMS-managed data sets for data set selection and processing; data sets are selected by normal ABR options and operands as described in FDRABR-Volume-Backups and FDRABR-Archiving-and-Superscratch. If you desire, you can run your normal ABR jobs against SMS-managed volumes and select data sets by normal ABR rules, without using SMS management classes at all.

If the operand SMSMANAGE=YES is specified on the DUMP statement, then ABR uses management class attributes for the selection of data sets from SMS-managed volumes while still using normal selection on non SMS volumes. If you plan to process SMS-managed and non SMS volumes in the same ABR step, you may need to specify ABR selection operands for the non-SMS volumes (they are ignored for SMS-managed volumes with the exceptions noted in the following text).

As each data set is read from the VTOC of an SMS-managed volume, its associated management class name is determined. Data sets with no management class are managed according to the default management class associated with the SMS configuration (if there is no default management class, data sets with no management class are not selected, nor are data sets with invalid (not currently defined) classes).

Normally, ABR examines all SMS-managed data sets on the selected SMS-managed volumes and makes decisions based on their management classes. However, you may wish to limit ABR to processing only data sets with specified management classes in a particular ABR step. For example, you may wish to limit an Archive backup step to selecting only management classes that retain Archived data sets for a certain period such as 30 days. As long as SMSMANAGE=YES is specified, you can do so by specifying the management class names on the DUMP statement with the MGMTCLAS= operand (one or more class names can be given). Data sets that do not have one of the specified management class names are bypassed, and data sets that do match go through the selection process described in this section.

However, if a data set is not selected by SMS rules, it is possible to select it anyway by use of a SELECT statement. The PROTECT list applies to data sets selected by a SELECT.

The following sections detail the use of management class attributes during three types of ABR operations (Backup, Superscratch, and Archive Backup).

ABR backup

For full-volume and incremental ABR Volume Backups, if SMSMANAGE=YES, the management class is used only to exclude certain data sets from incremental backups. Management class attributes are NOT used to manage retention of data sets in full and incremental backups.

SMS management class attributes have no effect on ABR full-volume backups (DUMP TYPE=FDR or full-volume dumps forced during DUMP TYPE=ABR/AUTO/DSF). As usual, all data sets are dumped during a full-volume backup.

For TYPE=DSF backups, the data sets selected by SELECT and EXCLUDE statements are dumped unless their management class attribute “ADMIN OR USER COMMAND BACKUP” is set to NONE, which effectively protects the data set from data set backups.

For TYPE=ABR or TYPE=AUTO backups, data sets are selected by the normal ABR rules (FDRABR-Volume-Backups) or by SELECT and EXCLUDE statements, but they are not dumped if the management class attribute “ADMIN OR USER COMMAND BACKUP” is set to NONE or if the attribute “AUTO BACKUP” is set to “NO”.

Because of its limited value, you may decide not to use SMSMANAGE=YES with ABR volume backups.

Some attributes of the SMS storage group and management class are designed for use by IBM's DFSMShsm and have no meaning for the ABR system since its architecture is considerably different. In particular, the attributes relating to retention of backups are not used; retention of ABR backups follow the normal ABR rules documented elsewhere. The attributes are listed below relate to backup processing, but are ignored when ABR is used to manage SMS-managed volumes.

Management Class attributes:

ABR Superscratch

Superscratch (DUMP TYPE=SCR) scratches data sets that are not needed, for which no backup is required. When SMSMANAGE=YES is specified on the DUMP statement, then on SMS-managed volumes Superscratch scratches data sets that are “expired” according to management class rules.

Here is a brief summary of the scratch rules explained in detail below. ABR scratches SMS-managed data sets based on the expiration attributes of each data set's management class, as documented by IBM. In addition, if you specify EXPIRED on the DUMP TYPE=SCR statement, data sets with an explicit expiration date assigned by its creator or by SMS are scratched if that date is past.

If the EXPIRED operand is specified on the DUMP TYPE=SCR statement, then Superscratch scratches data sets that have reached their expiration date. Data sets have an expiration date recorded in their Format 1 DSCB if the creator of the data set specified an expiration date (EXPDT) or retention period (RETPD) or if the associated SMS data class specified an expiration/retention. If the expiration date in the DSCB is non-zero, and is less than or equal to today’s date, the data set is considered expired and is scratched if EXPIRED was specified.

If EXPIRED is not specified, then data sets with non-zero expiration dates are not scratched (with the exception of rolled-off GDGs as described below).

For SMS-managed data sets that have zero for the DSCB expiration date (not specified), then the management class attributes “EXPIRE AFTER DAYS NON-USAGE” and “EXPIRE AFTER DAYS/DATE” are used to determine if the data set is scratched (the EXPIRED operand is not required):

• If “EXPIRE AFTER DAYS NON-USAGE” is set to a value, the data set may be scratched if it is “nnn” days since the date it was last referenced (stored in the Format 1 DSCB). This is equivalent to the ABR operand ADAYS=nnn.
• If “EXPIRE AFTER DAYS/DATE” is set to a “days” value, it may be scratched if it is “nnn” days since the data set was created (also stored in the Format 1 DSCB). This is equivalent to the ABR operand CRDAYS=nnn.
• If “EXPIRE AFTER DAYS/DATE” is set to a Julian date, it may be scratched if that date is less than or equal to today’s date. This has no ABR equivalent.
• If both of these attributes are set to NOLIMIT then data sets with zero expiration dates are not scratched. If one of them is set to NOLIMIT then only the other test is done, but if both of them are set to values, then both of the tests must be satisfied for the data set to be scratched.

If the data set is a GDG generation that is in ROLLED-OFF status (fallen off the GDG limit but not deleted from DASD because the GDG does not have the SCRATCH attribute or the generation was not expired), the management class attribute “ROLLED-OFF GDS ACTION” controls additional tests:

• If “ROLLED-OFF GDS ACTION” is blank or MIGRATE, the above rules are used to determine if it is scratched. If it is not scratched, MIGRATE causes it to be Archived during a subsequent TYPE=ARC run.
• If “ROLLED-OFF GDS ACTION” is EXPIRE, the generation is scratched unless its expiration date in the Format 1 DSCB is greater than today's date. No other tests are done.

On SMS-managed volumes when SMSMANAGE=YES is specified, only the preceding rules are used to select data sets for scratching; SELECT/EXCLUDE statements and any GENERAL ARCHIVE SELECTION CRITERIA are not used, and SCREXCL statements (the SCRATCH PROTECT LIST) do not protect SMS-managed data sets. If you need to scratch data sets based on other criteria, or need to use SELECT/EXCLUDE, you need to make a separate TYPE=SCR run with SMSMANAGE=NO. However, temporary data sets are selected by a SELECT TEMP statement even if SMSMANAGE=YES.

You can select or exclude volumes for Superscratch processing based on allocation thresholds, as described in  , but it is not recommended. Superscratch takes little time, so there is little reason to bypass volumes simply because their allocation percentage is low.

ABR archive backup

Archive backup (DUMP TYPE=ARC) moves inactive data sets to less expensive media such as tape or Virtual Tape System (VTS) or compressed DASD. IBM SMS and DFSMShsm documentation call this MIGRATION, but it is the same thing.

If SMSMANAGE=NO is specified or defaulted on the DUMP statement, then ABR treats SMS-managed volumes like non-SMS volumes. Management class attributes do not apply, and all of the normal ABR Archive selection detailed in SELECT-EXCLUDE-and-MOUNT-Statements apply.

If SMSMANAGE=YES is specified, then during TYPE=ARC processing of SMS-managed volumes ABR checks the “COMMAND OR AUTO MIGRATE” attribute of the management class of each data set:

• If it is set to BOTH then the last reference date in the Format 1 DSCB of the data set is tested to see if the data set has been opened within the interval specified by “PRIMARY DAYS NON-USAGE”. If not, it is archived. If so, ABR tests for SMSCOMMAND=YES as described below.
• If it is set to COMMAND, and SMSCOMMAND=YES was specified on the DUMP statement, then the data set is passed through the normal ABR SELECT and EXCLUDE statements (if any) to see if it is selected based on normal Archive selection process as detailed in SELECT-EXCLUDE-and-MOUNT-Statements (except that if there is no SELECT or EXCLUDE that matches it, it is not tested against the GENERAL ARCHIVE SELECTION CRITERIA (if any) on the DUMP statement). If SMSCOMMAND=NO (the default), the data set is excluded from archiving.
• If it is set to NONE, the data set is excluded from archiving (similar to the ABR archive protect list).

If SMSMANAGE=ONLY is specified, and “COMMAND OR AUTO MIGRATE” is set to COMMAND or BOTH in the management class, then the data set is compared only to the ABR SELECT/EXCLUDE statements for selection; management class criteria are not used. This is intended to be used with the MGMTCLAS= operand to filter based on SMS management class name but select based on ABR criteria.

So, when Archiving, if SMSCOMMAND=NO is specified or defaulted, data sets are selected from SMS-managed volumes based only on the management class criteria, while non-SMS volumes are processed by normal ABR control statement options. Therefore, SMS and non-SMS volumes can be easily processed in one ABR run. If SMSCOMMAND=YES you can have SELECT and EXCLUDE statements that apply to SMS-managed volumes as well as non-SMS volumes; however, EXCLUDE statements and PROTECT statements (the ARCHIVE PROTECT LIST) does not prevent a data set from being selected from an SMS-managed volume by management class criteria.

If a data set is a rolled-off GDG generation, and “ROLLED-OFF GDS ACTION” is set to MIGRATE, it is archived. For all GDG generations, if “# GDG ELEMENTS ON PRIMARY” is not blank, then any generation that is not within the most recent “n” generations is archived (just like the ABR MAXGDG= operand). Other GDG generations may also be archived if they meet the tests above. However, GDG generations that are in a management class for which “# GDG ELEMENTS ON PRIMARY” is not blank are only selected based on management class criteria; even if SMSCOMMAND=YES is specified, they are not checked against SELECT commands.

Archive expiration

As data sets are archived, they are recorded in the Archive Control File; the location of their COPY1 backup and their COPY2 backup (if created) are recorded, as well as the expiration date of each copy. On non-SMS volumes, the expiration date of COPY1 and COPY2 is set from values specified in the TAPEx and TAPExx DD statements (or the DUMP statement) and the expiration is the same for all data sets Archived in the same ABR step. By default, the same is true for SMS-managed data sets. These expirations are referred to as the “normal ABR expirations” in this discussion.

However, if you specify SMSEXPIRE=YES or SMSEXPIRE=ALL as well as SMSMANAGE=YES on the DUMP TYPE=ARC statement, then ABR sets the expiration of COPY1 and COPY2 individually for each SMS-managed data set based on attributes of its associated SMS management class.

• SMSEXPIRE=YES applies only to data sets selected by SMS management class criteria; if SMSCOMMAND=YES is specified and some SMS-managed data sets are selected by SELECT commands, those data sets receive the normal ABR expirations.
• SMSEXPIRE=ALL applies to all data sets selected from a SMS-managed volume, including those selected by SELECT statement.

Most of the following discussion assumes that you are creating a COPY1 on DASD and a COPY2 on tape in one ABR step when archiving data sets from SMS-managed volumes. If this is not true, see the notes later in this subsection.

The intent of the following rules is to set the COPY1 DASD expiration of every data set so it can be recalled from DASD for the period that the management class specifies it remain on “LEVEL 1”, and so that it reaches its final expiration according to other management class attributes.

The COPY1 expiration is calculated from the attribute “LEVEL 1 DAYS NON-USAGE” plus the Last Reference Date stored in the Format 1 DSCB of the data set. If the calculated expiration date is already past, the expiration is set to today’s date. If “LEVEL 1 DAYS NON-USAGE” is set to “NOLIMIT”, the COPY1 expiration is set to the normal ABR COPY1 expiration.

If the data set has an explicit expiration date in its Format 1 DSCB (if the creator of the data set specified an expiration date (EXPDT) or retention period (RETPD) or if the associated SMS data class specified an expiration/retention), then that date is used for the COPY2 expiration.

If it does not have an explicit expiration, the COPY2 expiration is the higher of:

• The attribute “EXPIRE AFTER DAYS NON-USAGE” plus the Last Reference Date stored in the Format 1 DSCB of the data set
• The attribute “EXPIRE AFTER DAYS/DATE” (if it specifies a date, that date is used; if it specifies a “days” value, that value plus the Creation Date stored in the Format 1 DSCB is used).

If either of these attributes has a value of NOLIMIT, then it is not used. If both are NOLIMIT, then the expiration is set to the normal ABR COPY2 expiration.

There is a minimum COPY2 retention, to avoid the situation where the calculated retention results in a data set expiring almost immediately. It can be specified on the DUMP statement by the SMSMINRET= operand and defaults to 30 days. If the calculated COPY2 expiration is less than the minimum, it is set to the minimum.

If the calculated COPY1 expiration is higher than the COPY2 expiration, it is set to the COPY2 expiration. In addition, if COPY1 is on tape, it is set to the COPY2 expiration.

If you are creating a COPY1 on DASD and no COPY2, the COPY2 expiration is still stored in the Archive Control File for later use by FDRTSEL as follow. If COPY1 is on tape, it receives the COPY2 (“level 2”) expiration; the “LEVEL 1” expiration is only used for backups on DASD.

Even when SMSEXPIRE=YES or ALL is used, the normal ABR expiration dates for COPY1 and COPY2 are still placed in the labels of the Archive Backup data sets created on DASD and tape, so the backup data sets may be retained until those dates are reached.

For this reason, you may wish to divide your SMS Archive Backup into several jobs or steps, using the MGMTCLAS= operand on the DUMP statement to restrict processing to data sets with management classes whose expirations are within the normal ABR expirations assigned to the COPY1 and COPY2 backups. For example, for a step whose JCL specifies RETPD=10 on COPY1 and RETPD=60 on COPY2, select those management classes whose LEVEL 1 retention is no more than 10, and whose final expiration is no more than 60 days.

Another option would be to use tape management catalog control (usually specified by EXPDT=99000) on the COPY2 on tape; the FDRARCH REORG utility uncatalogs the tape when all files in it have expired, so that it is automatically released when there are no longer any active data sets stored on it.

The usage of SMSEXPIRE can be confusing, so here is an example to help clarify it. In this example, the COPY 1 backup on DASD is created with a normal ABR retention period of 30 days, and the COPY 2 on tape is scratched by tape management when all files on it are uncataloged (catalog control). However, the expiration dates of COPY 1 and COPY 2 for the individual data sets are set in the Archive Control File according to their specified management classes.

SMSEXPIRE=PRT is the same as SMSEXPIRE=YES except that a list of the SMS-managed data sets and the expirations assigned to them are printed (SMSEXPIRE=PRT is useful with SIM (simulate) to verify correct operation of the management classes). If you use SMSEXPIRE=ALL and want to print the expirations, specify both operands: SMSEXPIRE=ALL,SMSEXPIRE=PRT.

If the job is run on date 20.100, the COPY 1 backup data set expires on 20.130. If the SMS configuration contains management classes with these names and attributes:

Then here are some examples of individual data sets that are selected for archive based on PRIMARY DAYS NON-USAGE and the actual expiration dates that are recorded for them:

The FDRTSEL utility (see FDRTSEL-Introduction) has several features to help manage archive backups taken with SMSEXPIRE=YES:

• Since the archives within a given backup file have varying expiration dates, the ARCEDIT function can be used periodically to copy archive tapes and discard the data sets that have expired, reducing the size of the tape library.
• If you create COPY1 on DASD and later copy it to tape with FDRTSEL (specifying SMSEXPIRE=YES on the COPY/MOVE statement), it automatically assigns the COPY2 expiration (the final “level 2” expiration) calculated above to the new COPY1. This is true even if COPY2 was not created at backup time.

In addition, the FDRARCH utility (see FDRARCH-MODIFY-Statement) has been enhanced to support this. If a reorganization (REORG) of the Archive Control File is run with the ENABLE=SMSEXPIRE option specified, it scratches a COPY1 backup on DASD if all the entries that point to it are expired, even if the COPY2 entries are not yet expired. This allows REORG to automatically clean up the backup files on DASD when they are no longer required, even if the normal ABR expiration for that backup is not yet reached.

Volume threshold processing

If the THRESHOLD= operand is specified on the DUMP TYPE=ARC statement, the percentage of space allocated on a SMS-managed volume is compared to the high-allocation threshold in the SMS storage group associated with the volume (THRESHOLD=HIGH), or the low-allocation threshold (THRESHOLD=LOW) or a user-specified value (THRESHOLD=nn). If the allocation percentage is below the threshold, then Archiving is bypassed on the volume during this ABR step. This allows you to bypass Archiving on volumes with sufficient free space.

Thresholding is also supported on non-SMS volumes but the high and low thresholds are stored in the ABR Model DSCB on those volumes. On SMS-managed volumes, the thresholds in the ABR Model DSCB can be used instead of those in the storage group if the operand SMSTHRESHOLD=NO is specified.