FDRABR processing options and requirements

ABR operations

The first control statement in the ABR input must be a DUMP or RESTORE statement. It may be followed by SELECT and optionally EXCLUDE statements to specify data sets that must be backed up. It may also be followed by MOUNT statements to specify the DASD volumes or SMS storage groups to be processed in this execution of ABR (DISKxxxx DD Statements can also be used to specify volumes as described in DISKxxxx DD Statements in Archive-and-Superscratch-Job-Control-Requirements). ABR accepts up to 100 SELECT, EXCLUDE, and MOUNT statements in a single execution, unless that limit is overridden.

ABR archive and Superscratch options

The DUMP statement contains a TYPE= operand to specify the type of backup. In each case, volumes to be processed in the ABR step are identified by MOUNT statements and/or DISKxxxx DD Statements. These two values invoke ABR Archive Backup or Superscratch:

ABR Archive Backup is executed for every selected volume. Selected data sets are backed up, recorded in the Archive Control File, and scratched from DASD.

ABR Superscratch is executed for every selected volume. Selected data sets are scratched. No backup is taken. No recovery is possible unless you have ABR Volume Backups or other backups of the data sets.

ABR’s list of DASD volumes to be processed comes from several sources:

• If DISKxxxx DD Statements are present in the ABR step, the named volumes are added in the order they appear in the JCL.
• If MOUNT statements are present in the input, the named volumes are added in the order that ABR finds them while scanning system UCBs.
• If ONLVOL is specified on the DUMP statement, any volumes named on SELECT statements are included.
• If ONLINE is specified on the DUMP statement, all online volumes are included.

The volumes may be sorted to improve performance (see VOLSORT= in Archive-DUMP-and-SCRATCH-statements).

For Superscratch, the volumes are processed in their table order. A TAPEx DD DUMMY is required but is not used.

If the Archive step JCL contains a single TAPEx DD Statement, ABR selects the first DASD volume on its list and does the requested backup, creating file 1 on that output tape. When complete, it selects the next volume and creates file 2 on the tape, and so on, until all volumes are processed. If the amount of data selected from one volume exceeds a limit (4095 tracks by default), ABR creates multiple backup files for that volume, and each containing a subset of the data sets, to improve restore performance.

However, you may have up to nine TAPEx DD Statement in the Archive step. If you have more than one, ABR selects the first “n” volumes on its list and assigns them to the “n” tape drives, executing the backups in parallel with internal sub-tasking, and creating file 1 on each output tape. As each backup completes, ABR selects the next DASD volume and assigns it to the tape that just became idle, creating the next file number on that tape. Since the elapsed time of an Archive run is usually not important (these are inactive data sets, after all), a single TAPEx DD Statement is usually sufficient. See Memory Requirements in Processing-Options-and-Requirements for limitations on the use of multiple TAPEx DD Statement.

Memory requirements

See Memory Requirements in Processing-Options-and-Requirements.

Compress option

FDRABR can be instructed to compress the data on the sequential backup file using BMC's own proprietary software compression algorithm. The COMPRESS option should only be used: (1) for backups to DASD, (2) when the ZEDC=YES is specified, or (3) when using FDRCRYPT.

Duplicate tape option

ABR has an option to create a duplicate or second copy of the backup tape during dump processing. The primary copy is called COPY1 and the duplicate is called COPY2. The copy number becomes part of the name of the backup data set as described in Tape Format and Naming Conventions in Introduction-to-FDRABR-Archiving-and-Superscratch.

While dumping a DASD to a TAPEx DD Statement, the duplicate backup is written to the TAPEx DD Statement (same “x” value twice) if it is present. You may have TAPEx DD Statement for some TAPEx DD Statement and not for others in the same step but this is not recommended with ABR since you cannot predict which DASD volumes are written to which tapes.

Memory requirements do not increase with the use of the duplicate tape option.

E-mail notification

FDR has the ability to send e-mail messages indicating the failure (or optionally the success) of FDR operations. This is invoked by the presence of the FDREMAIL DD Statement in the FDR step, pointing to e-mail specification statements. E-mails may also be sent to text-enabled pagers and cell phones. E-mail statements and the instructions for enabling FDR e-mail are in FDR-E-mail-notification-facility.

Security

Complete details on the security options of the FDR system are found in Security.

For ABR Archive Backup and Superscratch ALLCALL results in these security checks:

• For Archive Backup and Superscratch, ABR checks to see if your user ID has at least ALTER authority to the entire input volume; under IBM RACF this means that you are authorized to the input volume serial under the DASDVOL security class (other security systems have similar ways of defining volume authority). If you do have this volume authority, no additional checks are done on that input volume. If you do not have volume authority or the input volume is not protected by your security system, then ABR checks if you have at least ALTER authority under the DATASET security class to every data set selected from the input volume. Any data sets to which you are not authorized are bypassed with an error message.
• For manual data set restores, ABR checks if you have at least UPDATE authority under the DATASET security class to every data set restored. Any data sets to which you are not authorized are bypassed with an error message. If an output data set must be allocated, the operating system checks if you have CREATE/ALLOCATE authority for the data set (this is done even if ALLCALL is not in effect). The user may need READ authority to the Archive Backup files on tape or DASD (even if ALLCALL is not in effect).
• For Auto-Recall of archived data sets, the above restore security checks may apply. However, it is possible to configure ABR so that no authority or only READ authority is required; this allows a job or TSO user to recall a data set that it uses as input. Details are in ABR-Auto-Recall-Security.

We recommend that volume security rules be established for the user IDs that execute ABR Archive Backups and Superscratch. This minimizes the security checking overhead as well as providing clear-cut control over who can execute the backups. Under IBM RACF, volume security is controlled by the DASDVOL security class, and other security systems have similar facilities (see their documentation). Under IBM RACF, it is also possible to execute under a user ID with OPERATIONS authority, which automatically grants DASDVOL and DATASET authority.

Data set enqueue option

You can request, via the DSNENQ= operand, that each data set being archived, scratched or restored be tested to see if it is in use. A data set is considered in use if any job or TSO user has a DD statement or dynamic allocation for that data set name.

In-use data sets are tested by doing an exclusive enqueue with a major name or SYSDSN and a minor name of the data set name itself, for each selected data set found in the VTOC of the input DASD; this resource is enqueued by any other task allocating the data set so our enqueue fails if it is in use.

Optionally you can request that inactive data sets be enqueued to ABR during the backup or Superscratch, to insure that no other job or TSO user can access the data set until ABR is done with the volume.

For Archive Backups and Superscratch, in-use data sets are bypassed. You receive the FDR158 message documenting the active data sets as a warning, but it is not considered an error; the step ends normally if no other errors occur.

For restores, ABR attempts to enqueue any data sets that it allocates on the output DASD volumes, to insure that no other task tries to use them until the restore is complete, but if the enqueue fails, the data set is still restored. But for existing data sets, if the enqueue fails, the restore is bypassed.

The DSNENQ= operand has three (3) possible values:

USE - Data sets are enqueued for the duration of the backup from this DASD volume or restore from this backup data set. For data sets that are active, an FDR158 warning message is issued and the data set is not enqueued. This is the most frequently used option. This is the default for TYPE=ARC restores.

TEST - Data sets are only tested to see if they are enqueued to another task at the time that the backup from this volume or restore from this backup data set starts. For data sets that are active, an FDR158 warning message is issued. The data set is not enqueued and other tasks may enqueue it and possibly update it while the operation is proceeding.

NONE - No data set enqueue is issued. This is the default for Archive Backup and Superscratch.

If you use CA MII (Multi-Image Integrity component of CA MIM) for enqueue processing, prior to release 11.6, see member FDRCONXT in the FDR Installation FDRSAMP for instructions on suppressing unnecessary MIM conflict messages due to FDR SYSDSN enqueues.

VTOC enqueue option

ABR also supports, via the ENQ= operand, an enqueue on the VTOC of every volume being dumped. For shared DASD, it can also invoke a hardware reserve on the volume during the FDR operation.

The VTOC is protected by an enqueue with major name SYSVTOC and a minor name of the volume serial. This enqueue is held by any task doing updates to the VTOC, including allocation of new data sets, extension of data sets to new extents, and scratching of existing data sets. This enqueue is normally of short duration, just for the few seconds necessary to update the VTOC, so if the enqueue is currently held by another task, ABR will wait for it to be released.

The SYSVTOC enqueue does not prevent access to existing data sets on the volume; it only insures that no other task is updating the VTOC while ABR is processing it. VTOC changes during a backup could result in an invalid backup.

For DASD shared with another z/OS system or LPAR, ENQ=RESERVE requests that, in addition to the enqueue described above, a hardware reserve is done on the volume. reserve will prevent any system from doing any I/O on the volume, except for the system that ABR is running on where only the enqueue protection applies. If you have a cross-CPU enqueue facility, such as GRS or MIM, you may be able to convert the reserve into a cross-CPU SYSVTOC enqueue and allow access to the volume during the operation (look up SYSVTOC in the documentation for your product).

Use ENQ= to prevent other tasks from making changes to the VTOC during the operation. ABR Archive Backups and Superscratch default to ENQ=ON (enqueue on same CPU). If you are executing ABR on shared DASD, specify ENQ=RESERVE. Member ENQ in the FDR Installation FDRSAMP has more information on VTOC enqueues.

Step termination

If no errors occur during the execution of ABR, the ABR job step ends with condition code 0 (zero).

If errors do occur, they are generally indicated by an error message; occasionally they are indicated only by a user abend (Uxxxx). Depending on the nature of the error, the step may end one of several ways:

• Some errors are critical. The job step ends immediately with a user abend (Uxxxx).
• Some errors are critical only to a particular operation. For example, during a backup, some errors cause the backup of a particular DASD volume to terminate immediately, but ABR may continue and attempt to backup other DASD volumes requested in the same step. A new tape is mounted on the drive associated with the failing backup, in case the failure was one that makes the tape unusable.
• Some errors are non-critical and the messages are warnings only. ABR completes the current operation.

For the last two conditions above, a flag is set indicating that a non-terminating error occurred. At step termination, it tests the flag; if it is on, the step terminates with return code 12 to call attention to the errors. Remember that RC=12 indicates that some or all of the functions requested did complete but the error messages must be examined to determine the impact of the errors.

If a different return code or a U0888 abend on a non-terminating error is preferred, the ABRCC option in the FDR Global Options can change it to a non-zero return code of your choice or abend (see ABR-Options).

Remote queue

ABR includes a facility, called “remote queue”, where users can request that certain data sets be included in the next Archive Backup, or that certain data sets be restored from Archive Backups. Requests can be added to the queue by TSO users using the ABR ISPF dialog; there is also a batch utility (FDRABRUT) for adding requests.

For backups, depending on installation options, a backup request to the remote queue can simply turn on a flag in the F1 DSCB of the data set, or it may add a statement to a remote queue data set requesting the backup. For restores, a remote queue data set is always updated. More information on the setup of the remote queue data sets is in Create-the-Remote-Queue-Files. They are honored only if you setup the data sets properly and include the proper DD statements in ABR jobs to process them.

If a remote queue data set is used for backups, a special DD statement must be included in the backup JCL (see ABRARDQ DD Statement in Archive-and-Superscratch-Job-Control-Requirements) pointing to the data set. ABR adds the requests (that act like SELECT statements) to the ABR control statement input.

If a remote queue is used for restores, you probably want to run a special ABR data set restore job at intervals (perhaps several times a day) just to process the remote requests so that the users do not have to wait an excessive time for their data sets to be restored. A special DD statement must be included in the restore JCL (see ABRARCH DD Statement in Archive-Restore-Job-Control-requirements) pointing to the data set. ABR adds the requests (that act like SELECT statements) to the ABR control statement input, which normally consists only of a RESTORE TYPE=ABR statement.

Dynamic allocation

ABR dynamically allocates DASD volumes as needed. There is no need to provide DISKxxxx DD Statements for volumes to be processed by ABR. As long as the required volumes are online, ABR can dump from and restore to any required DASD volumes.

For restore operations, ABR dynamically allocates each required backup tape if the DYNTAPE option is specified. If required backups are on mixed device types (such as 3490Es and 3590s), ABR automatically mounts each tape on the proper device type. For an Automated Tape Library (ATL) or Virtual Tape System (VTS), a drive in the proper library is allocated. If you have multiple tape libraries or several types of drives that emulate the same type of IBM drive, you may need to enable the DYNDEALC option in the FDR Global Options (ISPF panel A.I.4.4, see ABR-Options).

For data set restores, ABR sorts the list of backup files required and mounts the backup tapes in an order that minimizes the amount of tape movement required.

Volume thresholds

ABR can optionally process volumes for Archive and Superscratch based on allocation thresholds (percentage of the tracks on the volume allocated to data sets). For example, you may choose to process certain volumes only if they are more than 90% allocated, and bypass other volumes that are below this threshold. The purpose of this is to reduce ABR overhead and run time by processing only those volumes that need to have space freed up for the allocation of new data sets

For non-SMS volumes, a high and low threshold (as a percent from 0 to 100) can be stored in the ABR Model DSCB. The FDRABRM utility statements MAINT, REMODEL, and ABRINIT accept operands to set these thresholds (see VTOC Maintenance Utility (FDRABRM)), and the ISPF A.I.8 panel for maintaining ABR volume options can also display and set them (see FDRABRM-ISPF-Interface). For SMS-managed volumes, the SMS storage group associated with each volume contains the thresholds (although the thresholds in the ABR Model DSCB on those volumes can optionally be used instead).

With thresholding, ABR still builds a list of volumes by its usual techniques ( DISKxxxx DD Statements, MOUNT statements, and/or the ONLINE/ONLVOL operands), but it can be instructed to bypass any volumes under their high threshold, or under their low threshold, or under a threshold specified in the ABR run. By default, no threshold tests are done and ABR processes all volumes in its list.

Even with thresholding, once a volume is selected for processing, ABR scratches or archives all eligible data sets from the volume. This is different from the implementation of thresholds in DFSMShsm. DFSMShsm stops selecting data sets when the allocation percentage on the volume has been reduced below its low threshold, where ABR does not. ABR can afford to do this because our backup technique is efficient.