Limited supportBMC provides limited support for this version of the product. As a result, BMC no longer accepts comments in this space. If you encounter problems with the product version or the space, contact BMC Support.BMC recommends upgrading to the latest version of the product. To see documentation for that version, see BMC AMI Copy for Db2 13.1.

Restarting from the point of failure


If you plan always to restart failed 

BMC AMI Copy

 utilities from the point of failure, use the NEW/RESTART restart parameter in the original job whether you use dynamic allocation of the copy data sets or allocate them in the JCL.

This restart parameter specifies that if the utility ID does not exist, treat it as new. If the utility ID does exist, restart from the point of failure, which minimizes unnecessary processing.

When you are making copies using multitasking, several copies might have been in progress at the time of termination. BMC AMI Copy detects which objects were in progress, what phase each was in at the time the initial execution ended, and then restart as needed.

Important

When you restart copy jobs that are making SHRLEVEL CONCURRENT copies with GROUP YES, the entire group will be reprocessed if all objects in the group had not completed successfully on the initial execution unless you have enabled restartable Snapshot Copies with XBMRSTRT=YES. Copies that do not specify SHRLEVEL CONCURRENT will restart at the point of failure.

Dynamic allocation of image copies

If you use dynamic allocation for your output data set, no modification to the job stream is required. 

Allocation of image copies in the JCL

Important

If you allocated your data sets in the JCL and a media failure on an output copy occurred, the easiest and safest method is to start the utility over. Refer to Restarting-from-the-beginning for more information.

If you allocate data sets in the JCL, you must also do the following things:

  • Use DISP=(MOD,CATLG,CATLG) or DISP=(NEW,KEEP,KEEP)
  • Perform the following additional steps at restart:
    • For stacked tape copies using GDGs, modify the data set names to indicate the generation relative to the restart by modifying the (+ n) value to (+ n- m), where m is the relative generation number for the last cataloged generation in the original execution.
    • For cataloged stacked tape copies, remove VOL=REF= from the copy data set DD statements for the COPY command that failed in the COPY phase. This tells the system to use the catalog for volume information.

      Failure to remove VOL=REF= causes the restarted data set to get a 'not cataloged' message and causes a multiple volume data set to be on a different set of volumes than the original, cataloged data set. If the restarted copy data sets expand to more volumes than were cataloged at the time of the original execution, any attempt to stack further data sets using VOL=REF= results in another abend since the reference uses the catalog information from the beginning of the job step. The system will catalog the expanded data sets again at the end of the job step. However, submitting the job a third time should result in the utility executing with the volumes resolved correctly.

    • For uncataloged stacked tape copies, you must include the VOL=SER information of completed copies in the DD statements before restarting, and you must change the NEW disposition to OLD.


 

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