BMC AMI Recover data sets and BMC AMI Recover DD statements
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
(yes or no)
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
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
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.
0, 1, or 2
Lists maintenance applied, phases completed, utility return codes
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
Optional, based on MSGLEVEL
1 or 2
Lists all of the objects being recovered or rebuilt and their status, options, and resources
optional, based on MSGLEVEL
Records the execution plan
When you use a BMC Recovery Management for Db2 solution password, AFRPLAN includes values for recovery estimation.
Records warnings or error messages
Yes, if needed
Available only with the BMC 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
Provides trace information when errors occur during execution
SYSERR or AFRDUMP
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.
BMC does not recommend the suppression of dump output because it is used as a troubleshooting aid.
Used for BMCSORT message output
Captures system abend dumps
If SYSUDUMP is not in the JCL, it is dynamically allocated to SYSOUT.
BMC recommends the use of SYSUDUMP as a troubleshooting aid.
Contains the output from the LOGSCAN command
If the SYSSCAN DD is not specified, the LOGSCAN output is in AFRPRINT.
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.
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.
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 (PTF BQU2873 applied)||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.
( ) Because the AFRMIGR report is created during ANALYZE phase processing, BMC AMI Recover might report the intent to migrate an object in AFRMIGR. However, a subsequent error at runtime might prevent that object from being migrated.
1 The values shown are the required values of MSGLEVEL to produce the output file. The default value of MSGLEVEL is 1.
2When '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.
3Command and syntax reference. Sections are included with information on the use of Long Names and Unicode.For descriptions of the BMC AMI Recover commands and options, see
4However, 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.
5BMC 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.
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 BMC does 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.
Tape stacks with more than 255 volumes are not supported. You must split the recovery into two or more steps when using such a tape stack.
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).
Dynamic allocation of output copies is required for spaces with more than 254 partitions.
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
Local backup copy
Remote primary copy
Remote backup copy
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.
Because REBUILD INDEX and RECOVER INDEX are synonyms when you specify INDEXLOG=NO, the information in this section applies to RECOVER INDEX INDEXLOG=NO jobs. It could also apply to RECOVER INDEX INDEXLOG=AUTO jobs if no index image copies are found. (For more information about INDEXLOG, which is an installation option and which can also be set on the OPTIONS statement, see INDEXLOG=NO and INDEXLOG.) SIMRBLD and SIMRCVR may also require these DD statements.
Use DD statements to specify the following types of data sets:
Sort work data sets for keys
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.
When you use dynamic allocation for these files, BMC AMI Recover determines the optimal number of files to use.
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.
WORKDDN is valid only if MAXKSORT=1. If MAXKSORT is a value greater than 1, processing occurs as if NOWORKDDN is coded.
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.