Processes Monitor Diagrams

A simple process passes through the stages below. (Note that not all statuses are displayed here, because most of the time you will not see processes in status New, Dispatched, or Assigned, because 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, moving from left to right and top to bottom.

Processes that have not yet reached the Running status can be canceled. If you want to interrupt a process that has reached Running status but has not yet reached a final status, you must kill it. When you cancel or kill a process, the process will remain in the transitional states Canceling or Killing for a short time, depending on the system load, before it reaches its final status.

Chain Diagram

A submitted Chain consists of the following items:

  • A parent for the Chain.
  • A Chain Process per Step.
  • A process per Chain Process.

A basic Chain with one Step and one Chain Process 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, but the processes that were to run on Mondays would be Skipped on other weekdays.

By default, a Chain Process waits until either all of its child Steps have completed successfully, or a child Step completes 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 then is set to Error. At this moment, the Chain too will be set to Error status, and any Steps that come 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, too.

The final status of a Chain is determined by the status of the last Step that reached a final state. However, the Disabled, Skipped, andIgnored final states are special. If you have a Chain for which the last Step is Disabled, for example, the final status of the Chain will be Completed.

Manually Setting Chain Status

You can configure RunMyJobs so that the final status of a Chain always reflects the status of the last executed Step. There are two ways to do this.

  • Create the /configuration/jcs/jobchain/useLastExecutedStepStatus registry entry and set it to true.

  • In the Chain Definition, go to the Documentation tab and enter @useLastExecutedStepStatus=true.

Note: The keyword in the Documentation tab of the Chain Definition has precedence over the registry entry. If you want most (but not all) chains to always use the final status of their final Step, set the registry entry and then enter @useLastExecutedStepStatus=false in the Documentation tab.

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, these 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:

  • A change to a final state (Completed, Error, Unknown, Canceled, or Killed)
  • A change to one of the following statuses:
    • Killing
    • Canceling
    • PostRunning
    • Disabled
    • Modified

All constraints also fire when fields or parameter values are changed. Changes to the following fields are ignored.

  • BlocksOnJob
  • ChildOrder
  • CompletionStrategy
  • CreationTime
  • CreationTimeZone
  • Description
  • JobChainCall
  • JobChainStep
  • LLPVersion
  • NextRecalculation
  • NextSubmitBaseTime
  • NumChildJobs
  • NumJobFiles
  • NumJobLocks
  • NumJobMetaData
  • NumJobNotes
  • NumJobRaiseEvents
  • NumJobWaitEvents
  • RequestedStartTimeType
  • StatusForJobGroup
  • UniqueId

Status For Recurrence

Processes that have been submitted as part of a recurrence (for example, using a Submit Frame or a repetition defined in the Submit Wizard) have an additional status: the Status For Recurrence 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 are used for recurrences.

  • 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 a moment.
  • Restarted (R): The process is the consequence of a restart of a process that is part of the recurrence.