BMC AMI Recover data sets and BMC AMI Recover DD statements
Your recovery needs and the
BMC AMI Recover
strategy that you use determine the data sets needed for recovery. Some data sets are required; others are optional. Some data sets require DD statements in the JCL; others can be dynamically allocated by
BMC AMI Recover
.
DD statements common to all BMC AMI Recover executions
You can control the amount of output that you receive by specifying a value for the MSGLEVEL utility parameter. Valid values for MSGLEVEL are 0, 1, and 2. If you do not specify MSGLEVEL, BMC AMI Recover uses the default, MSGLEVEL(1).
For more information, see Using-MSGLEVEL-to-control-BMC-AMI-Recover-output.
The following table provides a list of BMC AMI Recover data sets along with specific information about each data set, including:
- Description of the data set
- Whether the data set is required or optional
- Whether a specific MSGLEVEL is required to produce the data set
- Whether the data set can be dynamically allocated or whether it requires a DD statement
Data set name | Required or optional | Dynamically allocated (yes or no) | Description | |
|---|---|---|---|---|
SYSIN | Required | No | Not applicable | Defines the input data set that contains the BMC AMI Recover commands and their options 3 This data set must be fixed blocked (RECFM=FB) with a record length of 80 (LRECL=80). Columns 73-80 are reserved for sequence numbers; any characters in these columns are ignored by BMC AMI Recover. For details of the BMC AMI Recover commands and options that you can specify, see Command-and-syntax-reference. Unicode is not supported in the SYSIN file. 4 |
AFRPRINT | Required | Yes | 1 or 2 | Contains a list of the phases executed for each object and the name of the AFRPRnnn data set where BMC AMI Recover put the output for the phase |
AFRPRnnn | Required | Yes | 0, 1, or 2 | Provides messages for each execution phase BMC AMI Recover allows up to (MAXKSORT + MAXLSORT + 1) AFRPRnnn files. BMC AMI Recover names the files AFRPR001, AFRPR002, AFRPR003, and so on. |
AFRSUMRY | Required | Yes | 0, 1, or 2 | Lists maintenance applied, phases completed, utility return codes |
AFRSTMT | Required | Yes | 0, 1, or 2 | Lists input statements, commands, and options as specified in SYSIN, installation option values, log file resources, and messages generated by analyze, planning, and termination stages |
AFROSUM 5 | Optional, based on MSGLEVEL | Yes | 1 or 2 | Lists all of the objects being recovered or rebuilt and their status, options, and resources |
AFRPLAN 5 | optional, based on MSGLEVEL | Yes | 2 | Records the execution plan When you use a Recovery Management for Db2 solution password, AFRPLAN includes values for recovery estimation. |
AFRERR | Not applicable | Yes | Not applicable | Records warnings or error messages |
AFRTIME | Optional | Yes, if needed | Not applicable | Available only with the Recovery Management for Db2 solution For the recovery estimation feature, reports the ten table spaces for which the longest elapsed time was recorded to recover each table space and all of its indexes |
AFRTRACE | Not applicable | Yes | Not applicable | Provides trace information when errors occur during execution |
SYSERR or AFRDUMP | Not applicable | Yes | Not applicable | Captures snap dumps issued during error processing If SYSERR is not coded in the JCL, BMC AMI Recover looks for AFRDUMP. If DD names are not coded for either SYSERR or AFRDUMP, BMC AMI Recover attempts to dynamically allocate SYSERR. We do not recommend the suppression of dump output because it is used as a troubleshooting aid. |
SYSOUnnn | Required | Yes | Not applicable | Used for BMCSORT message output |
SYSUDUMP | Not applicable | Yes | Not applicable | Captures system abend dumps If SYSUDUMP is not in the JCL, it is dynamically allocated to SYSOUT. We recommend the use of SYSUDUMP as a troubleshooting aid. |
SYSSCAN | Optional | No | Not applicable | Contains the output from the LOGSCAN command If the SYSSCAN DD is not specified, the LOGSCAN output is in AFRPRINT. |
AFRGDG | Optional | No | Not applicable | Used with dynamic allocation to provide a GDG base if one does not exist This data set contains the control cards needed to perform an IDCAMS DEFINE operation and the symbolic variable &BASE. For more information about the use of GDGs, see GDGs-and-symbolic-variables-in-data-set-name-construction. |
SYSPICK | Optional | No | Not applicable | Lists all of the input tape and cartridge volumes that are allocated during recovery, including those implicated because of a need to recall archived data sets to disk prior to recovery SYSPICK output consists of two reports. Both reports contain volume serial numbers, device types, data set names, and sequence numbers. One report orders the data by volume serial number and the other report orders data based on the order in which BMC AMI Recover uses the data sets. Allocation of the SYSPICK data set DCB should be RECFM=VB,LRECL=137. |
AFRDBG | Optional | No | Not applicable | Used to help with performance and problem diagnosis associated with Instant Snapshots, if you have EXTENDED BUFFER MANAGER (XBM) version 5.6 or later and you use Instant Snapshots for recovery |
AFRMIGR (SPE2005) | Optional | Yes | 0,1, or 2 | Provides migration summary Reports objects to be migrated, their status, and data size Records high level errors when source and target object definitions do not match Provides information about data migration activity performed through the IMPORT or MIGRATE commands The report contains the following sections:
The AFRMIGR report is created during ANALYZE phase processing, so if OPTIONS ANALYZE ONLY is specified with the IMPORT or MIGRATE commands, BMC AMI Recover produces a detailed analysis of the data migration activity that occurs without performing the data migration. |
1 The values shown are the required values of MSGLEVEL to produce the output file. The default value of MSGLEVEL is 1.
2 When 'not applicable' is shown, BMC AMI Recover produces the data set regardless of the value of MSGLEVEL. In some cases the files are dynamically allocated and in other cases they are not.
3 For descriptions of the BMC AMI Recover commands and options, see Command-and-syntax-reference. Sections are included with information on the use of Long Names and Unicode.
4 However, BMC AMI Recover can process spaces that contain tables, indexes, or storage groups with Unicode names. (Spaces cannot contain Unicode names). BMC AMI Recover commands that use wild cards do not include objects that match the pattern but contain Unicode characters that are not translatable to EBCDIC in the wild card position. This is because SYSIN is EBCDIC and wild card processing is done in EBCDIC.
5 BMC AMI Recover produces these data sets regardless of the value of MSGLEVEL when you specify OPTIONS ANALYZE ONLY.
Data sets and DD statements for RECOVER TABLESPACE, RECOVER INDEXSPACE, or RECOVER INDEX
The options specified, or for which defaults are accepted, in a RECOVER TABLESPACE, RECOVER INDEXSPACE, or RECOVER INDEX command statement may require that you specify DD statements in the JCL in addition to those common to all BMC AMI Recover executions.
See .
Use DD statements to specify the following data sets:
- Any requested output image copy data sets that are not dynamically allocated
- Log sort work data sets
For examples that use dynamic allocation and DD statement construction for output copy DD statements, see Examples-of-BMC-AMI-Recover-jobs.
Input image copy data sets
Normally dynamically allocated, input image copy data sets are needed for recovery unless recovery is possible by using only the log (for example, with LOGAPPLY ONLY or through a point-in-time recovery with BACKOUT).
DD statements are allowed, but we do not recommend their use for input image copy data sets. Use a DD statement for an input copy only to override a dynamic allocation. If you use a DD statement, it must contain a unit and a VOL=SER for uncataloged data sets. BMC AMI Recover matches the information in the DD statement to the data set that BMC AMI Recover would otherwise dynamically allocate by data set name and VOL=SER if uncataloged. Any DDNAME can be specified.
You do not need to code DD statements to control tape mounts for stacked tapes. BMC AMI Recover automatically selects the proper order and handling to accommodate this.
Output image copy data sets
Output image copy data sets are required only when you are requesting one or more output copies. Either ddnames or ddname prefixes are given in the syntax (or defaults are used), and these names or prefixes correspond to the JCL. Another option is to use dynamic allocation of output image copy data sets (see Dynamic-allocation-output-image-copy-data-sets).
The ddnames are constructed differently for partitioned and nonpartitioned spaces:
DDname Construction for Partitioned Spaces
If you have coded OPTIONS OUTCOPY BYPART, or if the OUTCOPY installation option is set to BYPART, and you have coded DSNUM on the RECOVER TABLESPACE, RECOVER INDEXSPACE, or RECOVER INDEX command statement, you specify the ddname as follows:
DDNamenn or DDNamennn
DDName is the prefix that you specified, and nn (for spaces with fewer than 100 partitions) or nnn (for spaces with 100 or more partitions) is the partition number. For spaces with fewer than 100 partitions, DDName is limited six characters. For spaces with 100 or more partitions, DDName is limited to five characters.
The following table lists the default ddname prefixes.
Prefix defaults for partitioned spaces
Type of copy
Less than 100 partitions
Equal to or greater than 100 partitions
Local primary copy
BMCCPY
BMCCY
Local backup copy
BMCCPZ
BMCCZ
Remote primary copy
BMCRCY
BMCRY
Remote backup copy
BMCRCZ
BMCRZ
The copies are made for the space as a whole if OPTIONS OUTCOPY ASCODED is coded, or if the OUTCOPY installation option is defaulted to ASCODED, and you have not coded DSNUM on the RECOVER TABLESPACE, RECOVER INDEXSPACE, or RECOVER INDEX command statement.
For these copies, you specify a ddname of up to eight characters. The default ddnames are the same as those shown in the preceding table in the Less Than 100 Partitions column.
DDname Construction for Nonpartitioned Spaces
When you are recovering a nonpartitioned space, the construction of the ddname depends on how the recovery is requested. If the request is made for DSNUM ALL (the default), the ddname is the ddname for the copy data set, up to eight characters. The default ddnames are the same as those shown in the preceding table in the Less Than 100 Partitions column.
If the request is to recover a specific data set of the space, for example DSNUM 2, the ddname becomes a prefix.
The default ddname prefixes depend on the highest DSNUM that you specified in the input commands. If DSNUM is less than 100, the default ddname prefixes are the same as those shown in the preceding table in the Less than 100 partitions column.
If the highest DSNUM specified is greater than or equal to 100, a maximum of five characters may be specified for the prefix, and the default values are the same as those shown in the preceding table in the Equal to or greater than 100 Partitions column.
Log data sets
Log data sets are used when RECOVER TABLESPACE, RECOVER INDEXSPACE, or RECOVER INDEX command processing involves applying log records. The data sets are dynamically allocated by BMC AMI Recover. No DD statements are allowed for log data sets. To control whether the utility uses archive or active log data sets and which copy is used, refer to OPTIONS RESOURCE SELECTION (see RESOURCE-SELECTION).
Log sort work data sets
Log sort work data sets are used when log records are to be applied. For more information, see Defining-sort-work-data-sets.
DD statements for REBUILD INDEX jobs
The options specified, or for which defaults are accepted, with the REBUILD INDEX command may require that you specify DD statements in the JCL in addition to those common to all BMC AMI Recover executions.
See DD statements common to all BMC AMI Recover executions.
Use DD statements to specify the following types of data sets:
- Sort work data sets for keys
- Parallel sorts
- Non-parallel sorts
- Sort message data sets for parallel sorts
- Work data sets for extracted keys
If RECOVER UNLOADKEYS command statements exist for the same space in the recovery, see DD statements for RECOVER UNLOADKEYS jobs.
Data sets needed for parallel index sorts and rebuilds
When you use the MAXKSORT option to specify that multiple key sorts (and index rebuilds) are to run in parallel subtasks, the following data sets are dynamically allocated by BMC AMI Recover, unless you provide DD statements for them:
SxxxWKnn: key sort work files for multiple key sorts running in parallel
xxx is a number between 1 and the value that you specified for the MAXKSORT installation option or the OPTIONS MAXKSORT parameter. nn is a number between 1 and the value that you specified for SORTNUM installation option or the OPTIONS SORTNUM parameter.
SYSOUnnn: sort message data sets
nnn is a number between 1 and the value that you specified for the MAXKSORT installation option or the OPTIONS MAXKSORT parameter.
For more information about MAXKSORT, see MAXKSORT-integer, MAXKSORT, MAXKSORT option, and UNLOADKEYS-and-BUILDINDEX-strategy.
Sort work data sets for keys for non-parallel sorts
BMC AMI Recover uses the following sort work data sets for non-parallel sorting of the index keys (when MAXKSORT=1):
- S001WK01 through S001WKnn for key sorts
- SYSOU001 for the sort message data set
For more information, see Defining-sort-work-data-sets..
Work data sets needed for extracted keys (WORKDDN)
If you code NOWORKDDN, no work data set is used for extracted keys.
If you code WORKDDN, you need to include a DD statement with the same name to specify the work data set. The default ddname is SYSUT1.
The work data set can be shared with other REBUILD INDEX command statements for other spaces. You must use the same work data set for all of the indexes on a single table space or code NOWORKDDN for all of them.
If you code neither WORKDDN nor NOWORKDDN, the use of a key work data set depends on whether you have included a SYSUT1 DD statement in the JCL. If you have included a SYSUT1 DD, it will specify the work data set. If you have not included a SYSUT1 DD, no work data set is used.
DD statements for RECOVER UNLOADKEYS jobs
You must include DD statements in the JCL when you specify a RECOVER UNLOADKEYS command statement.
These DD statements are included in addition to those common to all BMC AMI Recover executions. Use DD statements to specify the following data sets:
- Work data sets for extracted keys (SKEYDDN)
- (Optional) Sort work data sets for keys
For examples of DD statements used in a combined RECOVER UNLOADKEYS and REBUILD INDEX job, see Example-6-Extracting-nonpartitioned-index-keys.
Work data set needed for extracted keys (SKEYDDN)
This data set holds keys for subsequent RECOVER BUILDINDEX jobs. A sort for this file is done by RECOVER UNLOADKEYS. For the sorted extracted keys, one output data set exists per table space, regardless of how many partitions (or keys) are unloaded in one job.
The ddname is specified by the SKEYDDN option of a RECOVER UNLOADKEYS command. The default is SKEY.
When multiple RECOVER UNLOADKEYS commands are specified for a table space, the same SKEYDDN must be specified in all command statements.
The work data set for a specified table space cannot be shared with other RECOVER UNLOADKEYS commands for other table spaces or other REBUILD INDEX commands for other table spaces.
When you specify REBUILD INDEX and a RECOVER UNLOADKEYS for a table space, NOWORKDDN, which is the default value on the REBUILD INDEX command, sends keys for the partitioned index directly into the sort, bypassing the file held for the subsequent RECOVER BUILDINDEX job.
Sort work data sets for keys
These data sets are used for sorting the index keys. Sort work data sets are generally needed if the REBUILD INDEX command is included for the partitioned index. For more information, see Defining-sort-work-data-sets.
DD statements for RECOVER BUILDINDEX jobs
In addition to those common to all BMC AMI Recover executions, DD statements must be included in the JCL when you specify a RECOVER BUILDINDEX command statement. Use DD statements for work data sets for extracted keys (SKEYDDN).
For examples of the DD statements used in a RECOVER BUILDINDEX job, see Example-7-Building-a-nonpartitioned-index. For DD statements common to all BMC AMI Recover executions, see DD statements common to all BMC AMI Recover executions.
Data sets containing extracted keys (SKEYDDN)
BMC AMI Recover expects at least one DD statement that refers to a data set used to collect the sorted keys for nonpartitioned indexes in a prior RECOVER UNLOADKEYS run. If multiple files of sorted keys exist (because the RECOVER UNLOADKEYS command was run in multiple executions to get all of the partitions unloaded and sorted), each file needs a DD statement.
The ddname prefix is specified by the SKEYDDN option of a RECOVER BUILDINDEX command. The default prefix is SKEY. Any ddname within the JCL that begins with the specified prefix is recognized as an unload work data set.
Related topics