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).

ABR backup 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 four values invoke ABR Volume Backups:

A full-volume ABR Volume Backup is taken for every selected volume. SELECT/EXCLUDE statements are ignored; all data sets on the volumes are backed up. However, an EXCLUDE ALLDSN with VOL= or VOLG= still excludes those volumes from ABR processing.

An incremental ABR Volume Backup is taken for every selected volume. All data sets that have been updated since the last Volume Backup of the volume, plus all newly created data sets and the VTOC, VTOCIX, and VVDS are backed up. SELECT statements may be used to include other data sets even if they do not otherwise qualify. EXCLUDE statements, the ABR PROTECT LIST and SMS management class may be used to exclude certain data sets.

Operates the same as TYPE=ABR except that it automatically does a full-volume backup instead of an incremental at intervals. When you initialize the volume for ABR processing, one of the values you can set in the ABR Model DSCB is a cycle limit. That limit is used only with TYPE=AUTO backups. Every time an incremental backup is executed, a cycle count in the ABR Model DSCB is incremented. If the cycle count exceeds the cycle limit, the full-volume backup is forced. This can be used in place of explicit TYPE=FDR full-volume backups. It is possible to arrange TYPE=AUTO backups so that some percentage of your DASD volumes take full-volume backups each day, with the rest doing incremental backups.

Operates the same as TYPE=ABR, except that only the data sets identified by SELECT and EXCLUDE statements (that are required) are backed up. The label track, VTOC, VTOCIX, and VVDS are not included in the backup. TYPE=DSF is a way of backing up only selected data sets in the Volume Backup system, but there is an important consideration: if you need to do an ABR full-volume recovery (RESTORE TYPE=FDR), and the most recent incremental is a TYPE=DSF backup it is bypassed. So TYPE=DSF backups are not recommended; if you need to backup specific data sets, see FDRAPPL-Application-Backup.

In all these options, ABR builds a list of the DASD volumes to be processed. If the ABR 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.

However, you may have up to nine TAPEx DD statements in the 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. Use of this feature usually reduces the overall execution time of the backup. See Memory Requirements in Processing Options and Requirements for limitations on the use of multiple TAPEx DD statements.

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 Volume-DUMP-w-FDRINSTANT-Variations-Statement).

ABR restore options

The RESTORE statement contains a TYPE= operand to specify the type of backup. These two values invoke restores from ABR Volume Backups:

A full-volume ABR volume recovery is performed for every selected volume. SELECT statements are used to identify the volumes to be recovered. The recovery normally begins with the most recent incremental backup of each volume and reads back through the incremental dumps in the current generation, reading the full-volume backup that began the generation last. As a result, the recovered volume is an exact copy of the volume at the time of the last incremental backup. If recovery of multiple volumes is requested in an ABR step, they are recovered serially (one at a time); submit multiple ABR jobs if you want to recover volumes in parallel, but beware of contention for the same backup tapes by those ABR jobs.

One or more individual data sets are restored from Volume Backups. ABR automatically identifies the backup containing each requested data set and mounts it. See Data-Set-Selection for more details on data set selection and backup location.

Memory requirements

For backups specifying RTC=YES ABR requires:

• About 500K of storage below the 16MB line for programs and control blocks.
• About 2MB (2048K) of above-the-line storage for each concurrent backup.

For backups not specifying RTC=YES ABR requires:

• About 500K of storage below the 16MB line for programs and control blocks.
• About 1MB (1024K) of below-the-16MB-line storage for each concurrent backup.
• If COMPRESS= is specified, an additional 1M of below-the-line storage for each concurrent backup (total 2MB per backup).
• ABR executes concurrent backups if multiple TAPEx DD statements have been provided, up to nine.
• ABR always uses the exact memory it requires for a given function, no matter what REGION= value is specified. So, if the region is too small, ABR fails (or some of the backups fail); if it is too large, ABR does not use the excess so a large region has no negative impact. For this reason, you may want to specify REGION=0M in ABR JCL to request the largest available region.

ABR full-volume recovery requires about 300MB of above-the-line storage. ABR data set restores require a below-the-line region of 512K plus about 512 bytes for each data set to be processed. VSAM clusters may add an additional 1K bytes per component processed.

Some logical RESTORE operations may require additional memory, so a region of 1024K or more is recommended.

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 Overview-of-FDRABR-Volume-Backups.

While dumping a DASD volume to a TAPEx DD statement, the duplicate backup is written to the TAPExx DD statement (same “x” value twice) if it is present. You may have TAPExx DD statements for some TAPEx DD statements 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 Volume Backup ALLCALL results in these security checks:

• For full-volume backups, ABR checks to see if your user id has at least READ 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 READ authority under the DATASET security class to every data set on the input volume. If you do not have volume authority or authority to every data set on the volume, the backup is terminated.
• For incremental backups, ABR always checks to see if your user id has at least READ authority to the entire input volume as defined above. If you do have this volume authority, no additional checks are done on that input volume. If you do not have volume authority, then ABR checks if you have at least READ authority under the DATASET security class to every data set being backed up. Any data sets to which you are not authorized are bypassed with an error message; this may impact the ability to do a proper ABR full-volume recovery.
• For full-volume recoveries, ABR checks to see if your user id has UPDATE authority to the entire output volume. If not, the restore is terminated. However, if the output volume is not protected by your security system, the restore is done with no additional security checks. For this reason, we recommend defining volume-level security rules to control full-volume restores.
• For 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 is bypassed with an error message. If an output data set must be allocated, the operating system checks if you have CREATE or ALLOCATE authority for the data set (this is done even if ALLCALL is not in effect).

We recommend that volume security rules be established for the user ids that are executing ABR Volume Backups and full-volume recoveries. 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 dumped 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 of 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.

If you have requested data set enqueues, any data set that is in use causes an FDR158 warning message to be printed; this sets the job error flag and causes a return code 12 when the step is complete (see Step Termination in Processing Options and Requirements). If you do not want in-use data sets to be considered an error, specify the ENQERR=NO operand; this prints the FDR158 message without setting the error flag.

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

For backups, in-use data sets are still dumped by default, but you must be aware that the backups of data sets that are being updated during the backup may be unusable, depending on the nature and format of the data. If you wish to bypass the backup of active data sets during an incremental backup, specify the ENQERR=BYPASS operand.

For restores, ABR attempts to enqueue any data sets that it allocates on the output DASD, 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. However, for existing data sets, if the enqueue fails, the restore is bypassed. Data sets are not enqueued during full-volume recovery.

The DSNENQ= operand has four possible values:

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=ABR restores.

Data sets are only tested to see if they are enqueued to another task at the time that the backup from this DASD 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.

The data sets are enqueued for the duration of the backup or restore. If a data set is in use, the z/OS operator must interact with ABR to decide how to proceed; a message FDRW27 is issued to the z/OS console, and the operator can respond:

Wait for the data set to become available; if it is not eventually dequeued, the ABR job may time out, so the operator must know which data sets are in use by long-running jobs or tasks.

Do not enqueue the data set. The FDR158 warning message is issued.

Try the enqueue again. If it fails again, the FDRW27 message is reissued.

No data set enqueue is issued. This is the default for backups.

Use DSNENQ= to prevent other tasks from updating (or reading) data sets being dumped or restored. Member ENQ in the FDR Installation Control Library (ICL) has more information on data set enqueues.

If HFS=QUIESCE or ZFS=QUIESCE is specified, special backup processing is done for Hierarchical File System (HFS) and zSeries File System (zFS) data sets, used by UNIX System Services (USS)). If the SYSDSN enqueue cannot be acquired, this may mean that the file system is mounted to UNIX, so FDR attempts to quiesce the file system during the backup. Details on the quiesce function are found in Hierarchical File System (HFS) and in zSeries File System (zFS) in FDR-Processing-by-Type-of-Data-Set. If you are executing FDRINSTANT (where the main control statement is SNAP, FCOPY, or PSPLIT instead of DUMP).

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 Control Library (ICL) 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 waits 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 prevents 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 backup. Since ABR must update the VTOC at the end of the backup, to record the backup just taken, and so must protect against unexpected changes in the VTOC, ABR Volume Backups 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 Control Library (ICL) 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 your attention to the errors. Remember that RC=12 indicates that some or all of the functions you requested did complete but you must examine the error messages to determine the impact of the errors.

If you prefer to get a different return code or a U0888 abend on a non-terminating error, the ABRCC option in the FDR Global Options can change it to a non-zero return code of your choice or abend (see ABRCC in Invoking-the-ABR-Install-ISPF-Dialog).

Remote queue

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

For backups, depending on installation options, a backup request to the remote queue can simply turn on the update 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. You can find more information on the setup of the remote queue data sets in Create-the-Remote-Queue-Files. They are honored only if you set up 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 ABRBKDQ DD Statement in Volume-DUMP-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 ABRREST DD Statement in FDRABR-Restore-Job-Control-Requirements) pointing to the data set. ABR adds the requests (which 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 a Virtual Tape System (VTS), a drive in the proper library is allocated. If you have multiple tape libraries or several types of drives which emulate the same type of IBM drive, you may need to enable the DYNDEALC option in the FDR Global Options (see DYNDEALC).

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.