CICS Task Coordination

CICS runs many tasks at the same time. Task coordination is how CICS schedules those tasks, lets one task wait (suspend) while others run, and resumes suspended tasks when a resource is ready or a timer expires. Understanding suspension, resumption, and what tasks wait for helps you design applications that use the dispatcher correctly and avoid deadlocks or long holds on resources. This page covers multitasking, SUSPEND and RESUME, INTERVAL, and the kinds of resources tasks wait for.

Explain Like I'm Five: What Is Task Coordination?

Imagine a teacher with one whiteboard and many students. When one student is thinking or waiting for something (like a book), the teacher can let another student use the board. When the first student is ready again, they get a turn. CICS does something similar: many tasks (like many students) share the processor. When a task waits for something—typing from a user, a file read, or a timer—CICS switches to another task. When the wait is over, the first task can run again. Coordinating tasks means deciding when to stop one (suspend) and when to start it again (resume).

CICS Multitasking and the Dispatcher

CICS uses a dispatcher to run multiple tasks. Each task has its own control flow and storage (e.g. commarea, working storage for its programs). Only one task runs on a given TCB (Task Control Block) at a time. When that task issues a command that cannot complete immediately—for example reading from a file or waiting for terminal input—the task is placed in a wait state and the TCB is freed so another task can run. When the wait condition is satisfied (I/O complete, data arrived, or a timer expired), the task becomes dispatchable again. This way, many users or many requests are served with a limited number of TCBs, and no single task need block the whole region while waiting.

Tasks can also voluntarily suspend themselves using the SUSPEND API. That is different from an implicit wait on I/O: the program explicitly says "pause this task until something else resumes it or until a time limit." Coordination between tasks (e.g. one task starts another and later resumes it) is done via START, LINK, and RESUME, and by defining what resources (including time) tasks wait for.

Suspending a Task: SUSPEND

The SUSPEND call stops the current task. The task does not run again until it is resumed. Two ways to resume are: another program (or the same program in another task) issues a RESUME for that task, or an INTERVAL specified on SUSPEND expires and CICS automatically resumes the task. When the task resumes after an interval timeout, it typically receives a response indicating TIMED_OUT so the program can tell that it was not resumed by another event.

On SUSPEND you can specify INTERVAL (in seconds or milliseconds) so the task does not wait forever. You can also pass RESOURCE_NAME and RESOURCE_TYPE to document what the task is waiting for (useful for tracing and operations). The PURGEABLE option controls whether the task can be purged (e.g. by an operator or by the deadlock timeout) while suspended. PURGEABLE(NO) makes the task immune to purge during suspension; PURGEABLE(YES) allows normal purge behavior.

1
2
3
4
5
6
7
8
9
10
       *> Suspend this task; resume after 30 seconds if not resumed earlier
       EXEC CICS SUSPEND
           INTERVAL(30)
           RESOURCE_NAME('USER-REPLY')
           RESOURCE_TYPE('TERMINAL')
           PURGEABLE(YES)
       END-EXEC
 
       *> If we get here, task was resumed (or timed out)
       *> Check EIBRESP/EIBRESP2 for TIMED_OUT or other reason

Resuming a Task: RESUME

A suspended task can be resumed by the XPI (External Programming Interface) RESUME call. The program that calls RESUME must identify the task to resume (e.g. by task id or by the resource name/type that was used on SUSPEND). Typically another task or a trigger (e.g. an incoming message or event) drives the RESUME. After RESUME, the suspended task becomes dispatchable again and continues from the point after the SUSPEND. If no one calls RESUME and the task had an INTERVAL, CICS resumes it when the interval expires.

What Tasks Wait For

Tasks enter a wait state for several reasons. Some waits are implicit: the program issues a CICS command that cannot complete immediately (e.g. READ a file, RECEIVE from the terminal), and CICS puts the task in a wait queue until the operation completes. Other waits are explicit: the program issues SUSPEND and optionally specifies INTERVAL. The dispatcher also manages waits when there are not enough TCBs: a task that is ready to run may wait for a TCB from the pool. The following table summarizes common resources that CICS tasks wait for.

INTERVAL and Time-Based Resumption

When you specify INTERVAL on SUSPEND, you give a time in seconds or milliseconds (depending on the TIME_UNIT option). The task is suspended until either a RESUME is issued for it or that time elapses. When the interval expires, CICS resumes the task and the response (e.g. in EIBRESP/EIBRESP2 or the API response area) indicates that the resume was due to TIMED_OUT. Your program can use that to implement timeouts: "wait up to N seconds for something to happen; if it does not, continue anyway." The INTERVAL value can override the transaction's deadlock timeout (DTIMOUT) for that suspension; see your CICS documentation for details.

PURGEABLE and Task Termination

While a task is suspended, operators or the system might try to purge it (abnormally terminate it). The PURGEABLE option on SUSPEND controls whether that is allowed. PURGEABLE(YES) means the task can be purged during suspension (e.g. by deadlock timeout or operator command). PURGEABLE(NO) means the task cannot be purged while suspended; the system will not apply deadlock timeout to it and purge attempts may be rejected. Use PURGEABLE(NO) when the task must not be interrupted until it is resumed or the interval expires; use PURGEABLE(YES) when you want normal purge behavior so stuck tasks can be cleaned up.

Coordinating Multiple Tasks

You can use START to create another task (asynchronous transaction) and SUSPEND in the first task to wait until that other task or some external event does something, then RESUME the first task. The second task (or an event handler) would issue RESUME for the suspended task's identifier. This pattern is used when one transaction must wait for another to finish or for an external event (e.g. a message, a file update) before continuing. Design the flow so that you do not create deadlocks: e.g. task A suspended waiting for task B, and task B waiting for task A. Use timeouts (INTERVAL) so that if the expected event never happens, the task eventually resumes and can clean up.

Step-by-Step: Using SUSPEND with a Timeout

1. Decide how long the task may wait (e.g. 60 seconds). Choose INTERVAL in seconds or milliseconds.
2. Issue EXEC CICS SUSPEND with INTERVAL set to that value. Optionally set RESOURCE_NAME/RESOURCE_TYPE and PURGEABLE.
3. When the task continues (after RESUME or timeout), check the response. If it is TIMED_OUT, the interval expired and no one resumed the task.
4. Branch in your code: if TIMED_OUT, perform timeout handling (e.g. message to user, cleanup); otherwise, process the normal resumption.

Step-by-Step: Resuming Another Task

1. Obtain the task id (or other identifier) of the task you want to resume. You might store it when you START the task or receive it via a channel/container or shared storage.
2. Issue the RESUME call (e.g. via the appropriate CICS API for your version) for that task.
3. The suspended task becomes dispatchable and continues from after its SUSPEND. Handle any errors from RESUME (e.g. task not found, already running).

Best Practices

• Always specify INTERVAL on SUSPEND when you expect to be resumed by another event, so the task does not wait forever if that event never occurs.
• Check the response after SUSPEND to distinguish normal resumption from TIMED_OUT and handle both cases.
• Use RESOURCE_NAME and RESOURCE_TYPE to document what the task is waiting for; it helps operations and tracing.
• Avoid deadlocks: do not have two tasks each waiting for the other; use timeouts and clear protocols for who resumes whom.
• Use PURGEABLE(NO) only when the task must not be purged during suspension; otherwise prefer PURGEABLE(YES) so stuck tasks can be cleaned up.

Test Your Knowledge