Job Status Tab

The Job Status tab lets you control restart behavior for Job and Workflow Definitions that use Advanced Schedules. Restart behavior controls what happens when a Job submitted as the result of an Advanced Schedule reaches the status Canceled, Completed, Error, Killed, and/or Unknown.

By default, if a Job that is using an Advanced Schedule reaches one of these statuses, the Advanced Schedule will simply ignore that particular Job instance and rerun the Job or Workflow Definition at the next time in the Advanced Schedule. By configuring this tab, you can change this behavior and potentially restart that Job instance.

Note: When a Job is restarted, a new instance of the Job is created and all values are set according to the original instance.

Tip: To restart a specific recurrence using its original submit time, navigate to the Monitor screen, then right-click any recurrence of the process in the choose Scheduling > Restart. In the pop-up window that displays, click Perform Restart on the recurrence.

The Job Status tab of the Job Definition editing screen includes the following controls.

Field Description Default Value
Returncode Map To Completed

Lets you specify a set of return codes that should be automatically mapped to Completed. You can use comma-separated values and ranges. For example, if you enter the following into this field, the Job is set to Completed for any return code that is less than or equal to 5, between 40 and 90 (inclusive), or greater than or equal to 100:

-5,40-90,100-

By default, only 0 is mapped to Completed.

Note: If you specify a value here, and you want 0 to be mapped to Completed (as it would be by default), you must include 0 in the list.
Maximum Starts

The maximum number of restarts allowed for the Job. The value is decremented after each restart. This means that a Maximum Restarts of 3 will restart the Job 3 times and the total number of runs will be 4. It is only decremented when the system does a fully automatic restart. When an operator intervenes using an action on a Job or an Operator Message, for example, then the value is reset to the value of the Job Definition.

On a Step, the initial run counts towards the value specified in Maximum Starts. However, on a Job Definitions, the initial run does not count towards the value specified in Maximum Starts.

 100
Action

  • Continue Advanced Schedule: The restart will occur following the Advanced Schedule.

  • Default Behavior: The return code for this Job is ignored. The Job is not restarted. The next instance of the Job or Workflow Definition is run at the specified time.

  • Request Restart: When this option is selected, you can specify an Operator Message to send. Human intervention will be required to restart the Job. For more information, see Restart Behavior of a Job Call used in a Step.

  • Restart: Restarts the Job immediately.

  • Restart From Error: Restarts a Job Call from the Step that reached status Error. This option is identical to Restart for non-Workflow Jobs.

  • Restart No Resubmit: The Job will be restarted, but the restarted Job will not be resubmitted.

  • Stop Advanced Schedule: The Advanced Schedule is stopped.

Restart Delay The delay between the end of the Job and the restart. 15s

The following table provides more detail about the Action field options.

Action Process Restarted? Advanced Schedule Obeyed?
Continue Advanced Schedule (Default behavior) No Yes
Stop Advanced Schedule No No
Request Restart Only if an Operator responds to the Operator Message Yes
Restart Yes Yes
Restart from Error Yes, from the Step that reached Error status. Yes
Restart No Resubmit Yes No

Note: Using the Completed status in combination with Restart from Error will restart from Error only if there was a Job in status Error, and Continue if there was no Job in status Error.

Note: When you configure a restart behavior on a Job Definition and call it from within a Workflow, the restart behavior of the Job Definition will take effect inside the Workflow.

Manual and Automatic Restarts

There are some differences between a manual restart and an automatic restart.

  • A manual restart uses the user who restarted the Job. The restart is not counted towards the Maximum Starts value, and the restart is not affected by any values specified for Maximum Starts or Restart delay The Restart Count is reset when either the object on which it is set is restarted, or a parent object is restarted. Thus the Restart Count on a Step, for example, is not reset when you restart a Job Call in the Step. When you restart the Step or any parent (such as the parent Workflow), the counter on the newly created object (Step or Workflow) is reset.
  • An automatic restart does not set the user, does update the restart count, and is limited by the Maximum Starts value. Any Restart Counts on child objects will be reset in the newly created object.

Restart Behavior in Workflow Definitions

A Workflow Definition is a type of Job Definition, so the restart behavior described above also applies to Workflow Definitions. In a restart, a new instance of the Workflow Job are created and the Parameters of the top-level Job are set according to those of the original. This is not a recursive operation. Call Parameters mapped to the Workflow will have the same values, but Parameters that contain REL expressions will be reevaluated. Parameters on the Workflow itself that contain REL expressions will not be reevaluated.

Restart Behavior of a Job Call used in a Step

Assume you configure a Job Definition so that it should Request Restart when it goes into Error status, and then you call that Job Definition within a Workflow. If the Job goes into Error status, both the parent Step and its parent Workflow will go into status Waiting until an Operator responds to the Operator Message about the problem. Also:

  • If the Operator responds to the Operator Message with Handle as if Error, the Step containing the Job Call goes into status Console, and the Workflow goes into status Waiting, and an Operator Message is generated for the Step.

  • If the Operator responds to the Operator Message with Handle as if Complete, the Step goes into status Complete and the Job Call goes into status Error.

In addition, if you are using Job Call Dependencies, any successors to a Job Call that goes into status Error go into status Chained. Also:

  • If the Operator responds to the Operator Message with Handle as if Error, the Job Call goes into status Error, the Step goes into status Console, the Workflow goes into status Waiting, and an Operator Message is generated for the Step.

  • If the Operator responds to the Operator Message with Handle as if Complete, the Job Call goes into status Error, any successor Job Calls go into status Skipped, and the Step goes into status Complete.

Restart Behavior in Scheduled Recurring Jobs

Assume that a process with restart behavior On Error Request Restart was submitted with an Advanced Schedule and a presubmit count of 3, and the first scheduled occurrence of the Job has reached Completed.

The following figure illustrates the number of Jobs in this recurrence.

The following figure illustrates the Job reaching Error. Note that in the figure, an Operator Message is waiting for a reply. As soon as the Job reaches a final state, a new one is submitted.

The following figure illustrates the Job being restarted.

The following figure illustrates the restarted Job reaching Completed.

The following figure illustrates the restarted Job reaching Error. Again, an Operator Message has been generated and is waiting for a reply.