About Exception Handling

Process Manager provides built-in exception handlers you can use to automatically take corrective action when certain exceptions occur, minimizing the human intervention required. You can also define your own exception handlers for certain conditions.

Built-in exception handlers

The built-in exception handlers are:

Rerun
Kill
Opening an alarm

Rerun

The Rerun exception handler reruns the entire work item. Use this exception handler in situations where rerunning the work item can fix the problem. The Rerun exception handler can be used with Underrun, Exit and Start Failed exceptions. Work items that have a dependency on a work item that is being rerun cannot have their dependency met until the work item has rerun the last time. When selecting the Rerun exception handler, you can specify the maximum number of times the exception handler reruns the work item.

Kill

The Kill exception handler kills the work item. Use this exception handler when a work item has overrun its time limits. The Kill exception handler can be used with the Overrun exception, and when you are monitoring for the number of jobs done or exited in a flow or subflow.

If you are running z/OS® mainframe jobs on Windows, you need to configure a special queue and submit jobs to that queue to be able kill them.

Alarm

An alarm provides both a visual cue that an exception has occurred, and either sends an email notification or executes a script. You use an alarm to notify key personnel, such as database administrators, of problems that require attention. An alarm has no effect on the flow itself.

You can use an alarm as an automated exception handler for many types of exceptions.

For other types of exceptions where alarms are not available as exception handlers, you can create an alarm directly in the Flow Editor.

An opened alarm appears in the list of open alarms in the Flow Manager until the history log file containing the alarm is deleted or archived.

Alarms are configured by the Process Manager administrator.

Behavior when built-in exception handlers are used

The following describes the behavior when an exception handler is used.

Flows

When a Flow Experiences this Exception…	and the Handler Used is…	This Happens…
Overrun	Kill	The flow is killed. All incomplete jobs in the flow are killed. The flow status is ‘Killed’.
Overrun	Alarm	The alarm is opened. The flow continues execution as designed.
Underrun	Rerun	Flows that have a dependency on the success of this flow may not be triggered, depending on the type of dependency. The flow is recreated with the same flow ID. The flow is rerun from the first job, as many times as required until the execution time exceeds the underrun time specified.
Underrun	Alarm	The alarm is opened.
Flow has exit code of `n`	Rerun	Flows that have a dependency on this flow may not be triggered, depending on the type of dependency. The flow is recreated with the same flow ID. The flow is rerun from the first job, as many times as required until an exit code other than `n` is reached.
Flow has exit code of `n`	Alarm	The alarm is opened. Flows that have a dependency on this flow may not be triggered, depending on the type of dependency.
`n` unsuccessful jobs	Kill	The flow is killed. All incomplete jobs in the flow are killed. The flow status is ‘Killed’.
`n` unsuccessful jobs	Alarm	The alarm is opened. Flows that have a dependency on this flow may not be triggered, depending on the type of dependency. The flow continues execution as designed.
Work item has exit code of `n`	Rerun	Flows that have a dependency on this flow may not be triggered, depending on the type of dependency. The flow is rerun from the first job, as many times as required until the work item has a different exit code.

Subflows

When a Subflow Experiences this Exception…	and the Handler Used is…	This Happens…
Overrun	Kill	The subflow is killed. The flow behaves as designed.
Overrun	Alarm	The alarm is opened. Both the flow and subflow continue execution as designed.
Underrun	Rerun	Work items that have a dependency on this subflow may not be triggered, depending on the type of dependency. The subflow is rerun from the first job, as many times as required until the execution time exceeds the underrun time specified.
Underrun	Alarm	The alarm is opened. The flow continues execution as designed.
Subflow has exit code of `n`	Rerun	Work items that have a dependency on this subflow may not be triggered, depending on the type of dependency. The subflow is rerun from the first job, as many times as required until an exit code other than `n` is reached.
Subflow has exit code of `n`	Alarm	The alarm is opened. The flow continues execution as designed.
`n` unsuccessful jobs	Kill	The subflow is killed. The flow behaves as designed.
`n` unsuccessful jobs	Alarm	The alarm is opened. The flow and subflow continue execution as designed.
A work item has exit code of `n`	Rerun	Work items that have a dependency on this flow may not be triggered, depending on the type of dependency. The flow is rerun from the first job, as many times as required until the work item has a different exit code.

Job or job array

When a Job or Job Array Experiences this Exception…	and the Handler Used is…	This Happens…
Overrun	Kill	The job or job array is killed. The flow behaves as designed. The job or job array status is determined by its exit value.
Overrun	Alarm	The alarm is opened. Both the flow and job or job array continue to execute as designed.
Underrun	Rerun	Objects that have a dependency on this job or job array may not be triggered, depending on the type of dependency. The job or job array is rerun as many times as required until the execution time exceeds the underrun time specified.
Underrun	Alarm	The alarm is opened. The flow continues execution as designed.
An exit code of `n`	Rerun	The job or job array is rerun as many times as required until it ends successfully.
An exit code of `n`	Alarm	The alarm is opened. The flow behaves as designed.
`n` unsuccessful jobs	Kill	The job array is killed. The flow behaves as designed. The job array status is determined by its exit value.
`n` unsuccessful jobs	Alarm	The alarm is opened. The flow continues execution as designed.

User-defined exception handlers

In addition to the built-in exception handlers, you can create your flow definitions to handle exceptions by:

Running a recovery job
Triggering another flow

Recovery job

You can use a job dependency in a flow definition to run a job that performs some recovery function when an exception occurs.

Recovery flow

You can create a flow that performs some recovery function for another flow. When you submit the recovery flow, specify the name of the flow and exception as an event to trigger the recovery flow.