Action parameters

These parameters specify the action that HCL Workload Automation for Z should take when the recovery statement is invoked.
RESTART
RESTART=Y causes the job or started task to be rerun, either from the failing operation or, if you specified RESJOB, from an earlier operation within the occurrence.

RESTART=N prevents the restart. It can be used with ADDAPPL when the recovery actions are to be done by a separate application. It can also be used to select cases for which no recovery should be performed or when testing the recovery procedure. The operation remains in ended-in-error status. JCL rebuild and other requested actions are performed, however. This includes also the cleanup actions that are performed according to the RESSTEP specified. If no value is specified for RESSTEP, the default (Restart from begin) is used and no JOB card tailoring is requested.

Default: RESTART=Y.

RESJOB
The RESJOB parameter handles failures at an occurrence level, not within the failing job or started task itself.

The occurrence of the application is rerun from the first preceding computer workstation operation, whose name matches the job name specified in the RESJOB parameter. If the job name specified cannot be found in a computer operation preceding the failed operation in the same occurrence, no automatic recovery occurs and the job or started task remains in the error handling list with an extended status code indicating an automatic recovery error.

The indicated operation must be a predecessor to the failed operation or be the failed operation itself.

Note: External successors cannot be handled automatically. Therefore the set of operations selected for rerun that can be completed at failure time must not have any external successors.

The rerun operation must be defined on an automatically reporting computer workstation.

The parameter is ignored if RESTART=N is specified.

Default: Rerun from the failed operation.

ADDAPPL
Here you specify a list of applications. Occurrences of these applications are added to the current plan if this RECOVER statement is invoked.
  • If RESTART=N is specified, the applications are independent of the failed occurrence.
  • If RESTART=Y is specified, the recovery applications are added to the current plan as predecessors to the failing operation or, if RESJOB is specified, to the operation where restart is being attempted. How a predecessor operation is selected is described in Adding predecessor recovery occurrences to the current plan.

Added applications are independent of each other. A maximum of 40 application occurrences can be added.

For example, suppose a database update fails. A rerun of the failed job is necessary but must be postponed to a later time. However, a database restore job must be run to repair the database before the online users require the database. This recovery situation can be specified as: 
//*%OPC RECOVER JOBCODE=SCHK,RESTART=N,ADDAPPL=A301RORG

This means that, on case code SCHK, do not rerun the failing operation. (For information on case codes, see Case code lists.) However, add an occurrence of the application A301RORG to the current plan, without a dependency to the failing operation and leave the failing operation in ended-in-error status.

Default: No application occurrences are added.

Note:
  1. When automatic recovery adds an occurrence to the current plan, input arrival and deadline times are not taken from the application description. Instead the occurrence is given an input arrival of the time the add is run, according to the time on the z/OS® system where the controller is started and the deadline is set for 8 hours after input arrival. If an occurrence of that application already exists with this input arrival time, then one minute is added to the time until a time is reached when the occurrence can be included. If the added occurrence includes time-dependent operations with specific input arrival times, then the operations are started at the specified time.
  2. An occurrence that has been added to the current plan by automatic job recovery does not become the predecessor to an occurrence that is added later by daily planning, even if normal dependency criteria are met.
RELSUCC
This parameter specifies which external successors to the failing operation are allowed to run even if their predecessor operation has ended in error.

The external successors to the failing operation are checked, and the dependencies between the failed operation and the specified successors are deleted at recovery time.

The effect is that this predecessor (the failed operation) is reported as complete to the external successor, and the successor-predecessor chaining is removed. The external successor becomes ready if its other predecessors are completed. The dependency does not exist when the failed occurrence is rerun.

Even if one successor is released, other successors might be waiting for the failed occurrence to complete. These might be successors not yet in the current plan. Assume that W is a weekly application and D is a daily application that is dependent on W. If W fails and there is a RECOVER statement causing the release of that day's D, the occurrence of D the next day also waits for W to complete, but without any automatic release.

You can specify a maximum of 40 application IDs.

Default: None.

ALTWS
Specifies the name of an alternate workstation on which to run the operation. The ALTWS parameter overrides the alternate workstation defined in the workstation description. You can use this parameter, for example, with the TIME parameter to specify alternate workstations for an operation, depending on the time of day. This parameter is not supported for automatic recovery of jobs using a centralized script.

Default: None.

ALTJOB
Specifies an alternate job or started-task name to use when the job is restarted. The name applies only to this particular occurrence. This parameter is not supported for automatic recovery of jobs using a centralized script.

Default: The job or started-task name is not changed.