Adding predecessor recovery occurrences to the current plan

When application occurrences are added to the current plan, as the result of the ADDAPPL automatic recovery statement, and RESTART=Y is specified for the failed occurrence, the failed occurrence is made a successor of the newly added application occurrences. This is to allow for the common situation in which, for example, a data set restore must take place before a job can be rerun. The rerun is dependent on the successful completion of the restore job.

Because external dependency relationships are between particular operations within occurrences, HCL Workload Automation for Z must work out which operation in the successor occurrence depends on which operation in the predecessor occurrence. The operation HCL Workload Automation for Z designates (in the failed occurrence) as the restart operation is either:
  • The failing operation itself.
  • The operation given by the RESJOB parameter, if RESJOB is specified.
The predecessor operation, in the application occurrences added by recovery, is chosen using the following rules:
  1. If the failed occurrence has a defined predecessor in the application added by recovery, this predefined predecessor-successor linkage is maintained.
  2. If no such dependency is defined, the default predecessor workstation is used to select the predecessor operation. The default predecessor workstation is defined in the PREDWS parameter of the AROPTS automatic recovery initialization statement. The last operation in the application on that workstation is selected as the predecessor operation.
  3. If no dependency is defined and no PREDWS name is defined, the last operation, is selected as the predecessor operation.

The last operation mentioned above is the last operation the user specifies when creating the application description, or when the application description was last updated via panels or the PIF.

However, it is recommended that the application description of the failing occurrence has a predecessor defined to the recovery application for the potential restart operation.

When you are defining applications, consider setting up any recovery applications that might be required. If you do not define run cycles for the recovery applications, the required recovery occurrences are included in the current plan only when the error condition is matched and the recovery action is invoked.

You require a recovery application for any operation in your main application that might cause a RESTART, and for which some cleaning up must be done before a rerun.