Volume DUMP Job Control Requirements


The following Job Control Statements are necessary to perform dump functions:

STEPLIB or JOBLIB DD statement

If FDR is not in the system link list (LNKLST), specifies the program library in which FDRABR resides. The library must be APF authorized.

EXEC statement

Specifies the program name (PGM=FDRABR), region requirement (REGION=, see Memory Requirements in Processing-Options-and-Requirements), and optional PARM= operand.

If a PARM field is specified, ABR uses data specified as the first control statement, which must be a valid DUMP statement; if the PARM data contains a slash “/”, the data after the slash is used as the second control statement (usually a SELECT). For example,

//FDR EXEC PGM=FDRABR,PARM='DUMP TYPE=FDR,DSNENQ=USE' //FDR EXEC PGM=FDRABR,PARM='DUMP TYPE=DSF/ SELECT DSN=A.B.C'

If FDRABR is invoked from a user program, Register 1 must follow IBM's convention for passing data from the PARM field.

$RPTSUT2 DD statement

If PRINT=RPT is specified on the DUMP statement, this DD specifies a sequential data set where FDREPORT records information about the data sets backed up by ABR in this step. See PRINT= in Volume-DUMP-w-FDRINSTANT-Variations-Statement for details.

ABRBKDQ DD statement

Specifies the remote queue data set for BACKUP operations. This DD statement is optional. If specified, ABR reads the control statements contained within, if any, and append these statements to the SYSIN data set. The SYSIN data set must contain at least a DUMP TYPE=ABR, DSF, or AUTO statement. After reading the control statements, ABR resets the file to null (empty) data set except on SIM. Specify DISP=SHR since ABR internally serializes this data set.

Important

This ABR execution must process all of the volumes that contain the data sets specified in the remote queue. This can easily be done by use of the ONLVOL operand on the DUMP statement.

ABRMAP DD statement

Specifies the output report data set if SIM or PRINT=ABR is specified. It is optional; if not specified the SIM report is printed on the SYSPRINx DD statement. See notes on SYSPRINT DD Statement in Volume DUMP Job Control Requirements.

FDREMAIL DD statement

Specifies input control statements for the FDR e-mail facility. If present, e-mail messages can be sent for unsuccessful or successful FDR operations. See FDR-E-mail-Notification-Facility for requirements and details.

FDRSUMM DD statement

(Optional) if present, ABR writes one-line messages for each volume dumped, giving result codes, elapsed time, and byte counts. See notes on SYSPRINT DD Statement in Volume DUMP Job Control Requirements. FDRSUMM is used only if RTC=YES is specified on the DUMP statement.

SYSIN DD statement

Specifies a data set containing the control statements for ABR. Usually a DD * data set. It is required, but if control statements were provided on the EXEC statement by PARM=, it can be DUMMY.

SYSPRINT DD statement

Specifies the primary output message data set; it is required. It is usually a SYSOUT data set but if it is assigned to a data set on tape or DASD, this DD statement must specify DISP=MOD. DCB characteristics are RECFM=FBA and LRECL=121; the block size defaults to 1210 on DASD or tape.

Warning

If directing any SYSOUT data (SYSPRINT, SYSPRINx, FDRSUMM, and so on) to DASD, ensure that the DASD volume being written to is not a DASD volume being dumped by the same step, otherwise, the SYSVTOC enqueue can cause a lockout if an update to the VTOC is needed.

SYSPRINx DD statement

Specifies the secondary output data set for messages related to the matching TAPEx DD statement. A SYSPRINx is required for each TAPEx present in the step. See notes on SYSPRINT DD Statement in Volume DUMP Job Control Requirements.

DISKxxxx DD statements

Optionally specifies DASD volumes to be processed by ABR. The format is:

//DISKxxxx DD UNIT=unit,VOL=SER=vol,DISP=OLD

xxxx

may be 1 to 4 alphanumeric (A-Z,0-9) or national (@ # $ in the US) characters

unit

is either a generic name, such as 3390, or an esoteric name assigned during your I/O configuration, such as DISK or SYSALLDA

vol

is the volume serial of the DASD volume (if an esoteric unit name is used, the volume serial must be mounted on a DASD volume that is part of that esoteric). You may use either DISP=OLD or DISP=SHR; it makes no difference.

The DISKxxxx DD statement may also specify multiple volume serials, up to 255, in the format:

//DISKxxxx DD UNIT=unit,DISP=OLD,VOL=SER=(vol1,vol2,…)

All the volumes must be of the same type (for example, 3390) and have the same capacity (for example, 3390-3) and the same SMS status (either all SMS-managed or all non SMS-managed).

ABR builds a list of the volume serials from all of the DISKxxxx DD statements found in the ABR step JCL; these volumes are processed in the order that the DISKxxxx DD statements appear in the JCL. A maximum of 256 DASD volumes can be processed in one execution of ABR; if more DASD volumes are required, MAXDD= must be specified on the DUMP statement.

However, DISKxxxx DD statements are not required. The ONLINE and ONLVOL operands of the DUMP statement and the MOUNT statement are easier ways of specifying volumes or groups of volumes (including SMS storage groups).

Important

If ABR encounters multiple DISKxxxx DD statements pointing to the same DASD volume serial, ABR processes the volume once using the first ddname encountered. DISKONLx is a reserved ddname, used by ABR for allocation of volumes that do not have DISKxxxx DD statements.

If you are using FDRINSTANT with ABR to backup offline point-in-time copies of online DASD volumes, the DISKxxxx DD statements allocate the online volumes. However, the PPRC=, SNAP=, FCOPY=, or BCV= operands on the DUMP statement instruct ABR to access the offline copy instead.

SYSUDUMP DD statement

Specifies the abend dump data set. Usually specifies a SYSOUT data set. Although not required, we strongly urge you to always include this DD statement, so that we can help you diagnose error conditions. If you have a debugging aid product on your system that would prevent the desired dump, please add the appropriate one of these statements to the JCL so that a fully-formatted dump is produced.

//ABNLDUMP DD DUMMY Print normal IBM dump in addition to the Abend-AID Report //CAOESTOP DD DUMMY Turn off CA OPT II & CA SYMDUMP //DMBENAN DD DUMMY Turn off DumpMaster //ESPYIBM DD DUMMY Turn off Eye-Spy //IDIOFF DD DUMMY Turn off IBM Fault Analyzer

TAPEx DD statement

Specifies the output device on which backup files are to be created. “x” may be any single alphanumeric (A-Z, 0-9) or national (@, #, and $ in the US) character. A maximum of nine such TAPEx DD statements may be present in the ABR step JCL. ABR starts an internal dump subtask for each TAPEx DD statement present, each subtask processing one DASD volume from ABR’s list of DASD volumes. If only one TAPEx DD statement is provided, ABR processes DASD volumes one at a time; if multiple TAPEx DD statements are present, ABR processes up to nine DASD volumes in parallel (however, region size limitations may limit the number of concurrent subtasks; see Memory Requirements” in Section 50.3). TAPEx DD statements that specify DUMMY or DSN=NULLFILE are ignored except for simulation.

Tape output

If outputting to tape or cartridge, the TAPEx DD statement must specify:

DSN=

A data set name is required by z/OS, but it is overridden by ABR at OPEN time, so any non-temporary name is acceptable. The name you specify is not used by ABR, but z/OS does an exclusive enqueue on this name at job initiation so each ABR job should use unique names.

UNIT=

Specify a generic (for example, 3590) or esoteric (for example, CART) name to allocate the type of tape drive desired.

VOL=

Specify a volume count, for example, VOL=(,,,255), to prevent ABR from abending if more than five tape volumes are required. If high-capacity cartridges are used, VOL= can be omitted. Do not use VOL=REF= to refer-back to a previous ABR step; use the LAST TAPE option (below) to add files to a tape.

LABEL=
RETPD=
EXPDT=

You may want to specify RETPD= or EXPDT= to identify the expiration date of the backups. See FDRABR-Volume-Backups for details on retention of ABR Volume Backups.

DISP=(NEW,KEEP)

Is required; do not specify CATLG since ABR handles cataloging of output files internally.

Do not specify FREE=CLOSE since it causes ABR to fail when it tries to create a second file on the tape.

If multiple DASD volumes are dumped to a given TAPEx DD statement, ABR creates multiple files on the tape, one file for each DASD volume, using the naming convention in Tape Format and Naming Conventions in Overview-of-FDRABR-Volume-Backups. If a tape volume is filled, ABR mounts a new tape, creating a multi-volume, multi-file tape aggregate. For example:

//TAPE1 DD DSN=ABR1,UNIT=3590-1,DISP=(NEW,KEEP), // EXPDT=99000

DCB parameters are not required and should be omitted. Tape hardware compaction may be the default depending on local z/OS options. For tapes attached by ESCON or FICON channels, we recommend use of tape hardware compaction instead of FDR software compression (the COMPRESS= operand) if this is available.

The hardware Virtual Tape System (VTS) from EMC, IBM, and Oracle StorageTek and software VTS such as CopyCross from Dell are supported. In a VTS, data written to “tape” is really written to DASD internal to the VTS and is later moved to high-capacity tapes such as Magstar tapes, resulting in much better physical tape utilization. When a tape is required for input, the data is staged back to the internal DASD.

LAST TAPE option

The LAST TAPE option of ABR allows you to add backup files to a tape created by a previous ABR step (even if that step is in another job and even if it was run on a previous day). This option is controlled entirely through JCL. To request LAST TAPE, the TAPEx DD statement is similar to that described above except that you specify:

DSN=FDRABR.LASTAPE.xxxxxxxx

The last index is 1 to 8 characters of your choice; you may have multiple LASTAPE files for various purposes. This name is cataloged in the ABR catalog to record the tape volume serial and file number where ABR is to start its output on the next run.

DISP=(MOD,KEEP)

This tells ABR to locate the FDRABR.LASTAPE.xxxxxxxx file in the catalog, verify that the file exists on the output tape, and begin outputting to the tape at that point. If the name is not cataloged, ABR calls for a scratch tape and begins at file 1, so you can force ABR to start on a new tape simply by uncataloging the LASTAPE name. In addition, if you specify NEW instead of MOD, ABR ignores any existing LASTAPE file and uses scratch tapes (but it still records the new LASTAPE file for future use).

VOL=

Volume serials should not be specified, but the volume count should be given, for example, VOL=(,,,255).

Example:

//TAPE1 DD DSN=FDRABR.LASTAPE.ABR1, // UNIT=3590,DISP=(MOD,KEEP), // VOL=(,,,255),EXPDT=99000

On cartridge tape drives, ABR records the location of the LASTAPE file and uses hardware high-speed positioning when positioning to add files to the backup tape.

Warning

Tapes created by ABR cannot be copied using normal copy programs. Use the BMC provided programs, FDRTCOPY and FDRTSEL, to copy ABR tapes. See FDR-Tape-Copy-FDRTCOPY and FDRTSEL-Introduction.

DASD output

ABR Volume Backups are not usually directed to DASD files, but DASD output is supported. See DASD Output in Archive-and-Superscratch-Job-Control-Requirements for details on specifying DASD volumes for ABR output files.

For DUMP operations to cloud storage

You may request that ABR create Volume backup files in the cloud. This is appropriate when the backups have a long retention and will probably not need to be restored.

For Transparent Cloud Tiering (TCT), TAPEx points to one or more DASD volumes on which ABR will create backup control files. All of the input volumes processed in this jobstep must reside in a single DASD control unit (or in other control units that are connected to the same cloud and are able to access the same containers), and the backup control file volumes (TAPEx) must also reside in that DASD control unit (or in other control units that are connected to the same cloud and are able to access the same containers).

The actual backup files are written to the cloud, but the backup control file contains information that is needed in order to do the restore. The cloud name and container name are recorded in the backup control file, and do not need to be specified at restore time.

Most of the considerations discussed under DASD Output in Archive-and-Superscratch-Job-Control-Requirements apply to the TAPEx for cloud storage. ABR internally handles naming, allocating, and cataloging the backup control files; see Tape Format and Naming Conventions in Overview-of-FDRABR-Volume-Backups for the file names that ABR creates. One difference is that backup control files are usually small; they only need to be a few tracks, unless a large number of data sets are being dumped. The backup control file cannot be multi-volume, but it can have multiple extents. We recommend starting with SPACE=(TRK,(15,15),RLSE), and increasing the allocation for backups that run out of space. The backup control file can be SMS-managed. For backup control files on SMS, since a backup control file cannot be multi-volume, the considerations above under DASD Output in Archive-and-Superscratch-Job-Control-Requirements for volume count and dynamic volume count do not apply. It is desirable that the backup control file remain on disk for as long as the backup is retained. However, the backup control file is also backed up to the cloud; if it is deleted from disk, then it can be restored from the cloud in order to be able to restore the data sets in the backup. Details are in Restoring-a-TCT-Backup-Control-File-From-the-Cloud. The backup control files should be managed using FDRABRM MAINT in the same way as regular backup files on disk. The backups in the cloud can then be cleaned up by FDRTCTUT with the DELETEBACKUPS command, as shown in FDRTCTUT-FDR-Transparent-Cloud-Tiering-Batch-Utility.

Examples showing TAPEx definition to create the backup control file:

Non-SMS:

//TAPE1 DD UNIT=SYSALLDA,DISP=OLD,SPACE=(TRK,(15,15),RLSE), // VOL=SER=BCF001

SMS:

//TAPE1 DD UNIT=SYSALLDA,DISP=OLD,SPACE=(TRK,(15,15),RLSE), // VOL=SER=TECH01,STORCLAS=SCARCH

SNAP, PSPLIT, or FCOPY

If you are using FDRINSTANT for your ABR volume backups, the ABR job consists of two steps. The first executes a SNAP, CONSNAP, PSPLIT, CONPSPLIT, FCOPY, or CONFCOPY statement, and the second executes the DUMP statement with a SNAP=, PPRC=, or FCOPY= operand. If the DUMP step has only TAPEx DD statements (creating only COPY1) then the SNAP, PSPLIT, or FCOPY step must also have only TAPEx DD statements. If the DUMP has both TAPEx and TAPExx DD statements, then the SNAP, PSPLIT, or FCOPY step must also have both. The DD statements in the SNAP, PSPLIT, or FCOPY step are DUMMY, for example:

//TAPE1 DD DUMMY //TAPE11 DD DUMMY

If you specify the EXPDT= or RETPD= operands on the TAPEx/TAPExx DD statements in the actual DUMP step, you must specify the same operands on the TAPEx/TAPExx DUMMY statements in the SNAP, PSPLIT, or FCOPY step, for example,

//TAPE1 DD DUMMY,RETPD=250

However, you do not have to have the same number of TAPEx and TAPExx DD statements in both steps. If you are processing a large number of volumes, we recommend that you include up to nine TAPEx DD statements in the SNAP, PSPLIT, or FCOPY step to invoke concurrent processing and minimize the elapsed time of that step.

Simulation

If simulation of ABR Volume backups is requested by the SIM statement, you must specify:

//TAPE1 DD DUMMY

TAPExx DD statement

Specifies that ABR is to create a duplicate backup (COPY2). “xx” must specify the same character twice with “xx” corresponding to the “x” of the TAPEx statement For example:

//TAPE11 DD DSN=FDR11,DISP=(,KEEP),UNIT=TAPE

produces a tape that contains the same backups as:

//TAPE1 DD DSN=FDR1,DISP=(,KEEP),UNIT=TAPE

Important

TAPExx may specify any of the options as documented for TAPEx, including LASTAPE. However, a unique LASTAPE name must be used for each TAPE DD statement in the job step.

ABR reads the DASD volume once and writes the same data to TAPEx and TAPExx concurrently. These are known to ABR as COPY1 (TAPEx) and COPY2 (TAPExx).

TAPExx must be omitted for backups to cloud storage.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*