CICSbeginner
CICS Transaction Processing Fundamentals
Understand what a CICS transaction is, how it differs from a batch job, and why response-time and concurrency demands shape its whole design.
CICS runs online transactions: short units of work, many users at once, answers expected in a fraction of a second.
CICS is the maître d' at a always-busy restaurant with one shared kitchen (the region) serving thousands of diners a night — instead of one chef cooking one meal start to finish before starting the next (batch), the maître d' juggles many orders in flight at once, making sure no two tables' meals get mixed up on the same shared stove.
Key Concepts
1
A batch program owns its run. A CICS transaction shares a region with thousands of others.
2
A transaction is identified by four characters. A user types INQC, or a request arrives, and CICS
starts a task running the program mapped to that id.
INQC
3
One copy of the program serves everybody, and that is the constraint everything else follows from.
4
batch one program, one run, its working storage is its own
CICS one program in storage, hundreds of concurrent tasks5
Each task gets its own copy of WORKING-STORAGE, but the executable code is shared. So the program must be
reentrant — it may not modify its own instructions, and it cannot assume its storage survives between
separate invocations.
6
Which kills the obvious way of writing an online program. In batch you would read a screen, keep the
values in working storage, display the next screen, and carry on.
7
In CICS, holding a task open while a user reads the screen means holding a task — and its storage, and any
locks — for however long that person takes. Multiply by a thousand users and the region is exhausted by
people thinking.
8
That is why CICS applications are written pseudo-conversationally: end the task, return control, and let the
user's next keystroke start a fresh one.
9
CICS provides the services the program uses instead of ordinary I/O.
terminal BMS maps, rather than DISPLAY
files EXEC CICS READ, rather than COBOL READ
storage temporary storage, transient data
recovery syncpoints, spanning files and DB2 together10
Everything goes through EXEC CICS.
EXEC CICS READ
FILE('CUSTFILE')
INTO(WS-CUSTOMER-REC)
RIDFLD(WS-CUST-ID)
RESP(WS-RESP)
END-EXEC.EXEC CICS
11
A translator turns these into CALL statements to the CICS runtime before the COBOL compiler sees them.
So the program is COBOL, and the I/O is requests to CICS, which is what lets CICS serialise, recover and
schedule them.
CALL
12
The framing that lands in an interview. CICS is not "COBOL online". It is an operating environment on
top of z/OS built for throughput and sub-second response, and every other CICS topic — pseudo-conversational
design, COMMAREA, syncpoints — exists because many users share the same programs and must not interfere
with each other.
13
What the interviewer is probing.1. "What is a transaction in CICS terms?" Probing: the vocabulary. Stalls: "A database
commit." Moves up: a unit of work identified by a four-character id, which maps to a program and
runs as a task when a user invokes it.
14
2. "What makes CICS different from batch?" Probing: the model. Stalls: "It is online."
Moves up: many short tasks share one address space with sub-second response expectations, so a
single long-running task starves everyone else.
15
3. "What is the golden rule for a CICS program?" Probing: the discipline. Stalls: "Be fast."
Moves up: never do anything that waits — no long loops, no unbounded reads, and nothing that holds
a resource across a terminal interaction.
16
4. "What resources define a transaction to CICS?" Probing: the setup. Stalls: "The program."
Moves up: entries in the transaction and program definitions, plus file and map definitions —
usually managed through CEDA or as source-controlled definitions.