CICS Process Processing

CICS process processing is how CICS turns a transaction request into execution: a transaction ID is resolved to a program, a task is created, programs run (and can call others via LINK or XCTL), and the task ends when the program returns. Multiple tasks run concurrently (multitasking), so when one task waits for I/O or the terminal, others can run. This page explains the transaction-to-task flow, program loading, execution, and how CICS schedules tasks.

Explain Like I'm Five: What Is Process Processing?

When you press a key to run a "transaction" (like ordering something), CICS has to do several steps: figure out which program to run first, start a "task" (your request), run that program, and when the program is done or waiting for you to type something, CICS can work on other people's tasks. Process processing is that whole flow: from "someone asked for transaction X" to "the task ran and finished."

Transaction and Transaction ID

A transaction is identified by a transaction ID: one to four characters (e.g. CEMT, Txn1). The user types the ID at the terminal (or it is sent by another system), and CICS receives the request. The transaction ID is defined in a resource table (e.g. Program Control Table, PCT) that specifies which program runs first when this transaction is invoked. So the transaction ID is the "name" of the unit of work; the definition tells CICS how to start it. A single transaction execution typically runs to completion (from first program to final RETURN), but one transaction ID can be invoked many times, each time creating a new task.

Task Creation and the Task Control Area (TCA)

When CICS starts processing a transaction, it creates (or assigns) a task. The task is CICS's unit of execution: it has its own Task Control Area (TCA), which holds task-specific data (e.g. terminal, user, COMMAREA or channel, state). The task runs one program at a time; that program can LINK to another (the same task continues, but the new program runs) or XCTL (transfer control to another program, same task). When the program issues RETURN, the task may end (if returning to CICS) or return to the caller (if the program was LINKed to). So one task = one logical request, possibly running several programs in sequence. The TCA exists for the life of the task and is freed when the task ends.

Program Loading and Execution

The first program for the transaction is named in the transaction definition. CICS loads it from the load library (or uses a cached copy if already in memory) and transfers control to its entry point. The program executes: it can READ files, SEND/RECEIVE maps, LINK to subroutines, XCTL to another program (replacing itself), and so on. When it LINKs, the called program runs in the same task; when that program RETURNs, control comes back to the caller. When it XCTLs, control never returns—the new program runs and eventually RETURNs (to CICS or to whoever LINKed the program that did the XCTL). Program loading is done by CICS using the PPT (Program Properties Table) or equivalent to find the load module. So process processing is: load first program → run → optionally load and run others via LINK/XCTL → return and end task.

1
2
3
4
5
6
7
8
9
10
       *> Transaction ABCD is defined to run program MENU
       *> MENU runs in the task; it can LINK to other programs
 
       *> In MENU:
       EXEC CICS LINK PROGRAM('INQUIRY') COMMAREA(WS-AREA) END-EXEC
       *> INQUIRY runs in same task; when it RETURNs, MENU continues
 
       EXEC CICS XCTL PROGRAM('DETAIL') COMMAREA(WS-AREA) END-EXEC
       *> DETAIL runs in same task; MENU is no longer in control
       *> When DETAIL does RETURN, task may end or return to whoever LINKed MENU

Multitasking

CICS runs many tasks concurrently. Only one task executes on a processor at a time in a single-threaded region, but when that task waits (e.g. RECEIVE MAP waiting for the user, or READ FILE waiting for I/O), CICS suspends it and dispatches another task that is ready to run. So the region can have hundreds of tasks, most of them waiting, and a few running or ready. This is multitasking: multiple tasks in progress, with CICS switching between them so that waiting does not block the whole region. Each task has its own TCA, so its COMMAREA, channel, and state are separate. Process processing therefore includes scheduling: which task runs next is determined by priority and readiness.

Task Priority

Tasks can have a priority (e.g. defined with the transaction or set at runtime). When more than one task is ready to run, CICS typically gives the processor to the highest-priority ready task. So critical transactions can be given higher priority so they get faster response when the region is busy. Priority does not change the order of execution within a single task (your program still runs step by step); it only affects which task gets to run when several are competing.

Waiting and Dispatching

A task "waits" when it issues a command that cannot complete immediately: RECEIVE (waiting for terminal input), READ (waiting for I/O), DELAY (waiting for time), or similar. CICS marks the task as waiting and does not give it the processor until the wait condition is satisfied (data arrived, I/O complete, timer fired). Meanwhile other tasks that are ready can run. When the wait ends, the task becomes ready again and will be dispatched according to priority. So process processing is not just "run one program"—it is run, wait, run again, possibly many times in one task, and interleaved with other tasks.

Transaction Flow End-to-End

End to end: (1) User or caller invokes transaction ID. (2) CICS looks up the transaction, gets the first program name, creates a task and TCA. (3) CICS loads the program (if needed) and starts it. (4) The program runs; it may LINK/XCTL to other programs, do I/O, wait for the terminal. (5) When it waits, CICS dispatches other tasks. (6) When the program (or the program that has control after XCTLs) issues RETURN, the task ends (or returns to the caller); CICS cleans up the TCA. That entire flow is process processing.

Step-by-Step: What Happens When a Transaction Is Invoked

1. CICS receives the transaction ID (from the terminal, LINK, START, or another source). It looks up the ID in the PCT (or equivalent) to find the first program to run.
2. CICS creates or assigns a task and allocates a TCA. The task is marked ready (or waiting if something is needed before the first program can start).
3. CICS loads the first program (from the load library, using the PPT) and transfers control to it. The program runs with the context (terminal, user, COMMAREA if any) in the TCA.
4. The program executes. If it LINKs, the called program runs in the same task; when it returns, the caller continues. If it XCTLs, the new program runs and the old one is no longer in the task.
5. When the program (or the program that currently has control) issues RETURN, the task ends (or returns to the program that LINKed). CICS frees the TCA and the task is gone.

Best Practices

• Design transactions so the first program is a clear entry point (e.g. menu or dispatcher) and use LINK for subroutines, XCTL when you do not need to return.
• Keep task duration reasonable; avoid long-running computations without waits so other tasks can run and the region stays responsive.
• Use task priority only where needed (e.g. critical vs batch-like); overuse can make tuning and fairness harder.
• Understand that when your program waits (RECEIVE, READ), other tasks run; do not assume single-threaded execution across tasks.
• Document the program flow (which program runs first, which LINK/XCTL) for each transaction to simplify debugging and operations.

Test Your Knowledge