BMC AMI Recover options

Enables you to specify the resources and the order in which they will be used in a recovery, as follows:

Yes —select from alternate resources, such as recovery site image copies, local backup image copies, or DSNUTILB FlashCopy image copies

No—use only the normally available recovery resources

Auto— job optimization uses both archive copies one and two. This option enables BMC AMI Recover jobs to run two at a time.

You can specify which copies of the following to use:

• Image copies
• Logs
• Copies of the change accumulation files

For more information, see Alternate-recovery-resource-options.

Turns dynamic sizing for output image copies or change accumulation output files on or off:

• Yes—specifies dynamic sizing for output image copies or change accumulation output files allocated to DASD.
• No—specifies that output image copies or change accumulation output files are allocated to DASD using the primary and secondary quantities that are specified in the R+/CHANGE ACCUM repository.

Controls the overhead that is associated with taking checkpoints, as follows:

• No—causes no checkpoints to be taken, except those necessary to synchronize BMC AMI Recoverr execution with the execution of other BMC utilities and the MERGE checkpoints that are necessary to guarantee the integrity of output copy registration. This option is recommended for short BMC AMI Recover jobs in which you do not want to incur checkpoint overhead and which you do not mind rerunning if necessary.
• Sync—causes a checkpoint to be taken at the end of each processing phase and also at the completion of each log data set in the LOG APPLY phase. This allows either phase restart or sync restart in the LOG APPLY phase. Specify this option for recoveries that require the reading of many log data sets using the RESTORE/LOGAPPLY, LOGAPPLY ONLY, or LOGONLY strategies.
• Phase—causes a checkpoint to be taken at the end of each processing phase if a set amount of time has passed. Choose this option for longer jobs when it would be costly to rerun the entire job.

Specifies the early retrieval (during the ANALYZE phase) of any archived image copies and log data sets that are required during recovery.

Specifies if key sorts are shared among BMC AMI Recover table space recoveries (MERGE phases) running in parallel.

• YES—uses up to the value specified for MAXKSORT active key sorts at any given time. If sufficient key sorts are not available when a table space recovery begins execution, keys will be obtained later by an UNLOAD phase.
• NO—each MERGE phase has its own set of key sorts and up to MAXKSORT * MAXLSORT key sorts can be active at any given time. Since the number of sorts that can be active in a system is fairly small - usually no more than 30 - a value of NO for this option may severely limit the number of recovery operations that BMC AMI Recoverr can perform in parallel when index rebuilds are also requested.

Scans the log and provides a report on the number and size of log records required for recovery

This option includes only the BMC AMI Recover LOGSCAN JCL in the job. No recovery JCL is generated, and no STOP, DELETE/DEFINE, START, or REPAIR steps are included in the JCL. The generated jobs contains a comment message stating that the LOGSCAN option was selected and no other job steps were created.

Be aware of the following information:

• LOGSCAN Yes and the recovery simulation feature are mutually exclusive. Objects with LOGSCAN Yes are excluded from simulation.
• A recovery to a copy overrides the LOGSCAN option and creates a normal recover job.
• If you specify Yes, you cannot perform a Backout Auto recovery for the object set. BMC AMI Recovery Manager changes Backout Auto to Backout No and issues a warning message.

Specifies the maximum number of index key sorts that can be run concurrently

Valid values are from 1 to 999. The default is blank, which causes BMC AMI Recovery Manager to use the value set in the BMC AMI Recover options. The BMC AMI Recover default is two times the number of CPUs.

For each table space, index keys for all indexes being rebuilt are distributed over the number of sorts that you specify for this option and these sorts can then run in parallel. For a partitioned table space, if the partitioning index is being rebuilt, the rebuild of each partition is done at the completion of the MERGE or UNLOAD for each partition of the table space. (The rebuild can run concurrently with the MERGE or UNLOAD for the next partition if the MAXKSORT number is not exceeded). Running concurrent index key sorts can increase the speed of the recovery. See Maximizing-concurrency-of-key-sorts for more information.

Be aware of the following information:

• Maximum Key Sorts overrides the WORKDDN value that is specified in the Work File Options panel.
• Maximum Key Sorts and Unloadkeys/Buildindex are mutually exclusive.

Specifies the maximum number of log files that BMC AMI Recovery Manager allocates at the same time during a log input phase

MAXLOGS provides a way to limit the number of tape log files that are read at the same time.

The BMC AMI Recovery Manager default is 0 (zero), which causes the option to default to the BMC AMI Recover configuration option value.

Specifies the maximum number of log sorts that can run concurrently and also determines the number of MERGE/RESTORE/SNAP phases that can run in parallel, whether or not log records are processed. You use MAXLSORT to improve recovery performance.

Valid values are 0 to 999. When MAXLSORT=0, the default value is determined by BMC AMI Recover.

BMC suggests values from 10 to 12 for MAXLSORT.

When you specify MAXLSORT, the following files are dynamically allocated if you do not code them in JCL:

LOGOU nnn: sort message files

nnn is the number of the log sort and is a number between 1 and the value that is specified for MAXLSORT.

L xxxWK nn: sort work files

xxx is the number of the log sort and is a number between 1 and the value that is specified for MAXLSORT. nn is the number of the work data set. For example, if MAXLSORT=3 and two sort work files are required for each sort, the DDs would be specified as follows:

L001WK01 DD...

L001WK02 DD...

L002WK01 DD...

L002WK02 DD...

L003WK01 DD...

L003WK02 DD...

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

Specifies the output files and messages BMC AMI Recover returns, as follows:

• 2— Plan Summary
  • AFRPRINT - execution messages
  • AFRSUMRY - maintenance applied, phases completed, utility return codes
  • AFRSTMT - input statements and options as specified in SYSIN, configuration option values, and log file resources
  • AFRTIME - reports the ten table spaces that took the longest amount of elapsed time to recover (available only with the Recovery Management for Db2 solution)
  • AFROSUM - object summary for objects being recovered
  • AFRPLAN - execution plan

• 1— Object Summary
  • AFRPRINT
  • AFRSUMRY
  • AFRSTMT
  • AFRTIME
  • AFROSUM
• 0— Standard
  • AFRPRINT
  • AFRSUMRY
  • AFRSTMT
  • AFRTIME

Use this option to determine how BMC AMI Recover is to proceed when errors are encountered. The default value is 10. The valid range is 0 to 2,147,483,646.

ON ERROR CONTINUE nnnnnnnnnn allows nnnnnnnnnn + 1 errors before BMC AMI Recover terminates. If nnnnnnnnnn is 0, BMC AMI Recover stops processing immediately when the first recognized severe error occurs. If you specify ON ERROR CONTINUE 0, the subtask to preallocate VSAM data sets is disabled, which could increase the execution time by several seconds for each object recovered.

Uses the BMC AMI Recover OUTCOPY function to make updated image copies from existing recovery resources such as prior image copies, change accumulation files, and Db2 logs

OUTCOPY writes the output to a sequential image copy data set instead of a Db2 space, which enables you to make copies without accessing the Db2 space or interfering with normal Db2 access in any way.

Specify how to make the output copies for partitioned table spaces after a successful recovery, as follows:

• ASCODED—makes copies with the same DSNUM designation that is used for the recovery. For example, if DSNUM ALL is used for recovery, the copies are made by table space. If DSNUM n is used for recovery (n>0), the copy is for partition n.
• BYPART—makes all copies of partitioned table spaces by partition whether or not the recovery is by table space (DSNUM ALL).
• NO— uses the specified copy utility instead of OUTCOPY. Copies are made with the same DSNUM designation as is used for recovery.

OUTCOPY is invalid in the following situations:

• If you specify LOGSORT No (see Preparing-recovery-jobs)
• If you specify BACKOUT AUTO (see BACKOUT-recovery)
• If you specify SIMULATE YES (Recovery-simulation-for-application-spaces). The syntax is generated for OUTCOPY, but the steps are bypassed and no copies are made.
• If you use compressed indexes

Facilitates the rebuild of large nonpartitioned indexes on partitioned table spaces by providing concurrency in the extraction of keys from multiple partitions

Using this option can dramatically reduce the elapsed time required to rebuild a nonpartitioned index.

Be aware of the following information:

• Unloadkeys/Buildindex should be used in conjunction with Max concurrent jobs, which should have a setting greater than 1. If you choose INDEX ALL in the general recovery options, then BMC AMI Recovery Manager does not generate the Unloadkeys/Buildindex syntax.
• Unloadkeys/Buildindex Yes and the recovery simulation feature are mutually exclusive. Objects using Unloadkeys/Buildindex Yes are excluded from simulation.
• Unloadkeys/Buildindex and Maximum Keys Sorts (MAXKSORT) option are mutually exclusive. MAXKSORT is available with BMC AMI Recover version 4.1 or later and enables multiple key sorts to run concurrently. For more information, see Maximizing-concurrency-of-key-sorts for more information.
• Unloadkeys/Buildindex cannot be used with compressed indexes.

Specifies the 1-8 character ID of the EXTENDED BUFFER MANAGER (XBM) subsystem that is required for use with Instant Snapshot copies