Processes Monitor Diagrams
Diagrams
Understanding Status changes
A simple process would pass the stages below, in fact, not all statuses are displayed here, most of the time you will not see processes in status New, Dispatched, or Assigned as these are transitional and are immediately reacted upon:
Wait events and locks force the process to wait until all wait events are raised or until the lock is released:
The following three figures display all possible states in chronological order:
Processes that have not yet reached the Running status can be canceled; processes that have reached the Running status and not yet reached a final status must be killed if you want to interrupt them. When you cancel or kill a process, the process will remain in one of the two transition states Canceling or Killing for a short time, depending on the system load, before it reaches its final status.
Chains
A submitted chain consists of the following items:
- a parent for the chain itself
- a chain process per step
- a process per chain process
A basic chain with one step and one chain process that got submitted has three processes.
When a chain is submitted, steps and Chain processes will remain in status Chained or Disabled until they are started. Disabled processes immediately reach status Ignored when the process server processes them. Disabled and Ignored steps have been disabled by an operator.
You can skip processes by submitting a chain at a specific step, all processes that would have been executed before the step in question will be skipped. Precondition functions can be used to have specific processes run at specific times only, for example, a chain that runs every day could have one or more processes with a precondition restricting these processes to run only on Mondays. The chain would run every day, the processes that were to run on Mondays will be Skipped on other weekdays.
By default, a chain process will wait until all its child-steps have completed successfully or a child-step completed unsuccessfully. Steps will wait in the same way for their Chain processes. When a chain process fails, the step waits for the other chain processes in the step to reach a final state and is set to Error. At this moment the chain will be set to Error and steps that came after the failed step are not executed and remain Chained. You can use Status Handlers to customize this behavior.
By default, when you kill or cancel a step or a chain process, the main chain process will be set to status Error. You can use Status Handlers to customize this behavior.
The final status of a chain is determined by the status of the last step that reached a final state; the following final 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 enable the behavior:
@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.
Parameter Validation, Constraints, and States
There are two types of constraints, built-in and simple. Built-in process definition parameters may have built-in constraints which are used to validate the In parameter value and/or display a list of valid values (LOV). During the life cycle of a process the constraints fire a number of times to confirm the validity of the parameter In value.
The constraints fire for each status change except the following:
- status change to a final state (Completed, Error, Unknown, Canceled, Killed)
- status changes to the following statuses
- Killing
- Canceling
- PostRunning
- Disabled
- Modified
Note that all constraints also fire when fields or parameter values are changed; changes to the following list of fields are ignored:
BlocksOnJobChildOrderCompletionStrategyCreationTimeCreationTimeZoneDescriptionJobChainCallJobChainStepLLPVersionNextRecalculationNextSubmitBaseTimeNumChildJobsNumJobFilesNumJobLocksNumJobMetaDataNumJobNotesNumJobRaiseEventsNumJobWaitEventsRequestedStartTimeTypeStatusForJobGroupUniqueId
JobGroups and JobStatusForGroup
Processes that have been submitted as part of a recurrence (JobGroup), using a submit frame or a repetition as defined in the submit wizard for example, have an additional status, the Status For Recurrence (JobStatusForJobGroup) status. It is used to indicate if the process is part of the recurrence (status Default) or has left the recurrence (Delayed, Edited, or Restarted).
The following statuses for recurrences are used:
- Default (
D) - the process is part of the recurrence - Delayed (
L) - the process has been delayed independently of other processes in the recurrence - Edited (
E) - the process has been edited independently of other processes in the recurrence - EditedPersist (
P) - the process has been edited and this has not yet been processed completely. The process will have the status for recurrence of Edited in short moment - Restarted (
R) - the process is the consequence of a restart of a process that is part of the recurrence
See Also
- Monitoring and Managing Processes
- Advanced Process Search
- Process Forecasting
- Workload Processing
- Available Columns in the Processes Monitor
- Configuration Entries
- The Registry
Status