CICSadvanced
CICS Transaction Lifecycle and Task Management
Understand how CICS dispatches, manages, and terminates tasks, and how resource contention and abends are handled at the task level.
This ties the other CICS topics together: what actually happens from the moment a transaction id arrives until the task ends.
The CICS dispatcher is an efficient host at a packed food court who never lets one customer's slow order tie up the whole kitchen — when one order (task) is waiting on the fryer (I/O), the host immediately moves attention to someone else's ready order, and if any one order goes wrong, only that customer's meal gets remade, not everyone else's.
Key Concepts
1
Starting.
1. A transaction id arrives — typed at a terminal, from another program's `START`, or triggered by a TD
queue reaching its level.
2. CICS looks it up in its resource definitions to find the program.
3. Task storage is allocated and the program is dispatched.START
2
Running: the task shares the region. CICS's dispatcher multitasks. When a task waits on I/O — a file
read, a terminal receive — it is suspended and another runs.
3
That is why a modest region serves thousands of users: at any moment most tasks are waiting rather than
computing, and waiting costs no CPU.
4
Waiting on other tasks is different from waiting on I/O. A task that needs a record another task holds
with READ UPDATE waits for that lock.
READ UPDATE
5
task A: READ UPDATE record 500 ... (still working)
task B: READ UPDATE record 500 -> waits6
Normally that is milliseconds. If task A is slow — waiting on a remote call, or hung — task B waits with
it, and so does everyone else who wants that record.
7
This is the classic "CICS is slow" incident. The region is not busy and the CPU is idle. A queue of
tasks is waiting on one record or one resource held by a single stuck task.
8
Looking at CPU tells you nothing. Looking at which tasks are suspended, and on what, finds it in one step.
9
Ending normally.
EXEC CICS RETURN10
The task ends and an implicit syncpoint commits everything recoverable it changed — CICS files, DB2 updates,
recoverable queues.
11
Ending abnormally. An unhandled condition, a program check such as a data exception, or an explicit
EXEC CICS ABEND.
EXEC CICS ABEND
12
Everything since the last syncpoint is backed out automatically. That is safe for the data, and it is a
poor experience for the user: an abend code on a blank screen rather than a message explaining what went
wrong.
13
Which is the practical argument for RESP checking. Not data integrity — CICS protects that either
way. It is that a handled error produces "customer not found, please check the number", and an unhandled
one produces AEIL and a support call.
RESPAEIL
14
The pieces are separate and cooperating. The dispatcher schedules, the enqueue manager serialises
resources, and the syncpoint manager commits or backs out. Knowing they are distinct is what lets you
reason about an incident rather than guess at it.
15
What the interviewer is probing.1. "What happens when a user presses Enter?" Probing: the sequence. Stalls: "The program
runs." Moves up: CICS matches the transaction id, attaches a task, loads the program if needed,
runs it, and frees the task on RETURN.
16
2. "What is the EIB?" Probing: the vocabulary. Stalls: "A control block." Moves up: the
exec interface block — it carries the transaction id, terminal id, date, time, response codes and
the attention identifier.
17
3. "What causes an AICA abend?" Probing: practical knowledge. Stalls: "A bug." Moves up: a
runaway task exceeding its time limit, which usually means a loop that never issues a CICS command.
18
4. "Why does task priority matter?" Probing: the tuning angle. Stalls: "It does not." *Moves
up:* under constraint, CICS dispatches by priority, so a badly prioritised heavy transaction can
delay interactive ones.