HCL Workload Automation, Version 9.4

Defining job rerun and recovery actions

About this task

You have several options when defining recovery actions for your jobs, both when creating the job definition in the database and when monitoring the job execution in the plan.

When you create a job definition, either in the composer command line or in the Workload Designer, you can specify the type of recovery you want performed by HCL Workload Automation if the job fails. The predefined recovery options are:
stop
If the job ends abnormally, do not continue with the next job.

You can also stop the processing sequence after a prompt is issued which requires a response from the operator.

continue
If the job ends abnormally, continue with the next job.

You can also continue with the next job after a prompt is issued which requires a response from the operator.

rerun
If the job ends abnormally, rerun the job.
You can add flexibility to the rerun option by defining a rerun sequence with specific properties. The options described below are mutually exclusive.
repeatevery hhmm for number attempts
You can specify how often you want HCL Workload Automation to rerun the failed job and the maximum number of rerun attempts to be performed. If any rerun in the sequence completes successfully, the remaining rerun sequence is ignored and any job dependencies are released.
rerun after prompt
HCL Workload Automation reruns the failed job after the operator has replied to a prompt.
same_workstation
If the parent job ran on a workstation that is part of a pool or a dynamic pool, you can decide whether it must rerun on the same workstation or on a different one. This is because the workload on pools and dynamic pools is assigned dynamically based on a number of criteria and the job might be rerun on a different workstation.

You can also decide to rerun the job in the HCL Workload Automation plan. In this case, you have the option of rerunning the job, or rerunning the job with its successors, either all successors in the same job stream, or all successors overall, both in the same job stream and in other job streams, if any. From the conman command line, use the Listsucc command to identify the job's successors and the Rerunsucc command to rerun them.

The rerun option is especially useful when managing long and complex job streams. In case of a job completing in error, you can rerun the job with all its successors. You can easily identify the job successors, both in the same job stream and in any external job streams from the conman Listsucc and Rerunsucc commands or the Dynamic Workload Console. From the Dynamic Workload Console, you can easily view the list of all job successors before rerunning them from the Monitor Workload view, by selecting the job and clicking More Actions> Rerun with successors. You can also choose whether you want to run all successors of the parent job or only the successors in the same job stream as the parent job. To manage the rerun option for parent job successors, see Rerunsucc and Listsucc.

Start of changeWhen you decide to rerun the job in the HCL Workload Automation plan, you have the option to modify the previous job definition. From the conman rerun command, you can specify that the job is rerun under a new user name in place of the original user name. Also, you can specify the new command or script that the rerun job must run in place of the original command or script. From the Dynamic Workload Console, this is done from the Monitor Workload view, by selecting the job and clicking Rerun>Edit Definition. End of change

recovery job
If the job ends abnormally, run a recovery job you have previously defined to try and solve the error condition. For example, you know that a job which requires a database connection might fail because the database happens to be unreachable. To solve this error condition, you might define a recovery job which restarts the database.

You can combine the rerun sequence with the recovery job, so that if the parent job fails, a recovery job is started. When the recovery job completes successfully, the parent job is restarted after the specified interval, if any, for a specific number of times, with or without its successors.

For example, if you define a rerun sequence in which a parent job is associated with a recovery job and the parent job is scheduled to be rerun for three times after waiting for one minute for the recovery job to complete, the rerun sequence unfolds as follows:
  1. The parent job runs and ends abnormally.
  2. The recovery job starts and completes successfully.
  3. The parent job waits for the specified interval after the recovery job completion before restarting, then restarts.
  4. If it completes successfully, the remaining rerun sequence is ignored and any job dependencies are released. If the parent job completes in error again, steps 2 and 3 are repeated for three times, unless one of the reruns completes successfully.
  5. If all reruns end abnormally, the job stream fails or remains in STUCK state.

For more information, refer to Job definition.