Space announcement

   

This space provides the same content as before, but the organization of the home page has changed. The content is now organized based on logical branches instead of legacy book titles. We hope that the new structure will help you quickly find the content that you need.

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)

MSGLEVEL value required # 1 2

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.

BMC does 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.

BMC recommends 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
Yes0,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:

  • MIGRATION FILE INPUT— Specifies details about the migration files used for the data migration
  • MIGRATION SUMMARY— Summarizes the data migration activity
  • TABLE SPACE SUMMARY— Reports data migration activity for each table space, which includes information about table spaces that cannot be migrated (all MSGLEVELs). For MSGLEVEL 1 and 2, the report includes information about spaces that will be migrated or bypassed because they have not changed.
  • OBJECT DETAILS— (MSGLEVEL 2) Contains information about all objects involved in the migration, including table spaces, tables, indexes, source, and target object names.

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. 

Note

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

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 BMC AMI Recover data sets and BMC AMI Recover DD statements.

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.

Note

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

Note

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

    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.

Note

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

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

Note

When you use dynamic allocation for these files, BMC AMI Recover determines the optimal number of files to use.

For more information about MAXKSORT, see MAXKSORT integerMAXKSORTMAXKSORT 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.

Note

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.





Was this page helpful? Yes No Submitting... Thank you

Comments