Skip to Content
Information
Space announcement We are no longer updating this space, and you cannot comment on this space. The RECOVERY PLUS for IMS component is now documented in BMC AMI Backup and Recovery for IMS.

Requirements and considerations

The following requirements and considerations apply to use of the Automatic Restart feature:

  • The Automatic Restart feature supports all types of recoveries.
  • Log extract data sets, CA extract data sets, and checkpoint data sets can be allocated with dynamic allocation models or with DD statements in the JCL.
  • Dynamic allocation is required for input data sets. DBRC must be active; specify DBRC(Y). Specify ACCUM(*) for dynamic allocation of change accumulation data sets and automatic handling of CA extract data sets.
  • If you specify IDCAMS(*), the Recovery utility performs IDCAMS delete/define processing as needed for restarted recovery tasks. If IDCAMS performs delete/define processing in a step that is previous to the Recovery utility step, this IDCAMS step must be executed manually before the restarted recovery job step is executed. Therefore, for best automation, use the IDCAMS(*) keyword in the original Recovery utility job step.
  • Dynamic allocation is required for output image copies.
  • If the recovery task is also writing one or more output image copies, the Automatic Restart feature supports stacking of output image copy data sets through use of the STKIC keyword or STACK control statement. Stacking with DD statements in the job step JCL is not supported. If the output image copy fails, the database recovery task is marked as incomplete; at restart, the recovery and image copy are attempted again.
  • The EXEC statement in the job step JCL must specify PGM=RVPUMAIN. The use of PGM=DFSRRC00 is not supported.
  • The FLUSH(Y) option is ignored.
  • Do not change the utility control statements before you restart the job step. Do not add members to or remove members from a group that was being recovered during the original execution.
  • Job steps that include tasks to rebuild indexes are a special case. If a task to recover a database completes successfully but a task to rebuild an associated index fails, the completed database recovery task is performed again at restart so that the rebuild task can be attempted again. Therefore, you might notice conflicting messages about completed and uncompleted recoveries for the same database between the failed job and the restarted job. If the original completed database recovery task was writing an output image copy and this output image copy completed successfully, the utility uses the completed image copy to perform the database recovery at restart (instead of using the original input image copy, change accumulation, and log data). In this case, the utility creates a new image copy at restart only if the new image copy is allocated with a different name from the input image copy. To allocate the new image copy with a different name, set up the processing options to generate a unique name for every execution.

Related topic

Using-the-Automatic-Restart-feature

 

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

RECOVERY PLUS for IMS 5.1