Restart Behavior on the Process Status Tab
Restart behavior is used to react to the final status of the process which has been scheduled with a submit frame. Usually to break or continue the submit frame when something unexpected happens. You configure the restart behavior on the Process Status tab of a process definition. When you break the submit frame, the process or chain does not get submitted again according to the submit frame. By default, all final states will continue to get submitted according to the submit frame. To restart a recurrence, according to the former base time, use the Scheduling > Restart action on any process of the recurrence and select Perform Restart on the recurrence in the dialog. The recurrence comprises all processes from the recurrence as well as restarted processes from the recurrence.
The following fields on the Process Status tab are not dependent on any status:
- Returncode Map To Completed - Allows you to map specific return codes to Completed. This field takes a comma-separated list of return codes; by default, only
0is mapped to Completed. Note that if you specify return codes here and you want0to be mapped to Completed (as is the default) you must specify it in the list; when this field is set, only return codes in this list are considered successful execution. - Maximum Starts - Allows you to specify the maximum number of automatic restarts allowed for processes; note that to use this feature, you must specify when to restart (see below). A manual restart does not count towards Maximum Starts.
The following states can be reacted on:
- Completed
- Error
- Killed
- Canceled
- Unknown
For each state one of the following reactions are available:
- Continue Submit Frame - The process is resubmitted according to the submit frame.
- Stop Submit Frame - The process is not resubmitted according to the submit frame.
- Request Restart - An operator message is sent requesting the restart, the operator needs to acknowledge and choose a restart option.
- Restart - The process is restarted.
- Restart from Error - Restart a chain process from the step that reached status Error; identical to Restart for process definitions.
- Restart No Resubmit - The process is restarted, however, it will not resubmit according to the submit frame.
Additionally, you can always send an operator message.
Built-in system defaults:
- Completed - Continue Submit Frame
- Error - Continue Submit Frame
- Killed - Continue Submit Frame
- Canceled - Continue Submit Frame
- Unknown - Continue Submit Frame
The different settings have the following outcome
| Option | Process Restarted | Submit frame obeyed |
|---|---|---|
| Continue Submit frame (Default behavior) | No | Yes |
| Stop Submit frame | No | No |
| Request Restart | Depends on the reply of the operator message | Yes |
| Restart | Yes | Yes |
| Restart from Error | Yes (from the step that reached Error) | Yes |
| Restart No Resubmit | Yes | No |
note
Using the On Completed status in combination with Restart from Error will restart from Error only if there was a process in status Error, which is very unlikely, and Continue if there was no process in status Error.
Restarts
You restart a process manually or specify conditions under which the system restarts the process, in both cases a new instance of the process is created and all values are set according to the original process.
There are some differences between a manual and automatic restart:
- A manual restart will set the user that restarted the process, the restart is not counted towards a Maximum Restarts counter and the restart is not affected by any maximum number of restarts ( Maximum Restarts ) or delays ( Restart delay ). The Restart Count is reset when the object on which it is set, or a parent object, is restarted; thus the Restart Count on a step, for example, is not reset when you restart a call in the step. When you restart the step or any parent (for example its direct parent the chain), the counter on the newly created object (step or chain) will be reset.
- An automatic restart does not set the user, does update the restart count and is limited by the Maximum Restarts property; it will stop once this is reached. Any Restart Counts on child objects will be reset in the newly created object (counters on any calls of a restarted step or chain).
Chain Definitions
Chain Processes
When you configure a restart behavior on a process definition and call it from within a chain, the restart behavior of the process definition will take effect inside the chain.
Final Status
The final status of a chain is determined by the status of the last step that reached a final state; the following states are special: Disabled, Skipped, Ignored. This means that if you have a chain of which the last step is Disabled, for example, the final status of the chain will be Completed.
The status of the chain can also be set to reflect the status of the last executed step. A registry entry and documentation keywords have been introduced to allow you to toggle the behavior. The keyword in the Documentation field of the chain definition has precedence over the registry entry.
The following comments can be used to use the status of the last executed determine:
@useLastExecutedStepStatus=true
To disable, use the following:
@useLastExecutedStepStatus=false
Just place the keyword (including @ and the desired value, true or false ) into the Documentation field on the Documentation tab of a chain definition.
The registry entry that governs the default behavior:
/configuration/jcs/jobchain/useLastExecutedStepStatus
The registry entry should be set to either true or false.
Maximum Restarts
The Maximum Restarts value is used to determine how often the system may run this particular process; the value is decremented after each restart. This means that a Maximum Restarts of 3 will restart the process 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 process definition or an operator message, for example, then the value is reset to the value of the process definition.
note
The Maximum Restarts property on a step behaves slightly differently as the initial run counts towards the value specified in Maximum Restarts; on process definitions, the initial run does not count towards the value specified in Maximum Restarts.
Values
| Tab | Field | Description | Default Value |
|---|---|---|---|
| Restart Behavior | Maximum Restarts | The maximum amount of process definition runs allowed for the process. | 100 |
| Restart Behavior | Action | ContinueSubmitFrame: The restart will occur following the submit frame. StopSubmitFrame: The submit frame will be broken. RequestRestart: An operator message will be sent to request restart permission. Restart: Restart the process immediately. RestartFromError: Restart a chain process from the step that reached status Error; identical to Restart for processes. RestartNoResubmit: The process will be restarted, the restarted process will not be resubmitted. | |
| Restart Behavior | restart Delay | The delay between the end of the process and the restart. | 15s |
| Restart Behavior | Operator Message to send | The operator message to send |
You set the default values in the DefaultJobDefinitionRestartLimit and DefaultStepRestartLimit configuration entries.
Restart Behavior in Chain Definitions
Restart Behavior on a Chain Definition
A chain definition is a type of process definition, therefore the restart behavior as described above will also apply to chain definitions. A new instance of the chain process will be created and the parameters of the top-level process will be set according to those of the original. This is not a recursive operation. Call parameters mapped to the chain will of course have the same values, however, parameters that contain REL expressions will be re-evaluated. Parameters on the chain itself that contain REL expressions will not be re-evaluated.
The final status of a chain is determined by the status of the last step that reached a final state. The statuses Skipped, Disabled, and Ignored are not taken into account. A chain which has its last step disabled, for example, the final status of the chain will be the status of the step before it. This behavior can be modified so the chain can also be set to reflect the status of the last executed step. The useLastExecutedStepStatus registry entry and @useLastExecutedStepStatus Documentation field keyword allow you to toggle the behavior. The keyword in the Documentation field of the chain definition has precedence over the registry entry.
Restart Behavior of a Definition used in a Call
When you configure a restart behavior on a process definition and call it from within a chain, the restart behavior of the process definition will take effect inside the chain. The step will wait until there are no more restarts.
Example
A process with restart behavior On Error Request Restart was submitted with a submit frame and a pre-submit count of 3, the first process has reached Completed.
The following figure illustrates the number of processes in this recurrence.
The following figure illustrates the process reaching Error. Note that in the figure, an operator message is waiting for a reply. Note that as soon as the process reaches a final state, a new one is submitted.
The following figure illustrates the process being restarted.
The following figure illustrates the restarted process reaching Completed.
The following figure illustrates the restarted process reaching Error; again an operator message has been generated waiting for a reply, you are back at the beginning.
See Also
- Controlling Global and Partition Restart Behavior
- Setting Chain Definition and Chain Definition Properties
JobChain JobDefinition ProcessDefinition