CICSadvanced
Pseudo-Conversational Programming
Understand why CICS programs release control between user screen interactions instead of waiting in memory, and how this shapes state management.
A CICS program does not wait while a user reads the screen. It sends the screen, ends completely, and starts again as a new task when the user responds.
Pseudo-conversational CICS is a call center where the agent hangs up completely after saying 'let me know when you're ready' — freeing that agent to help other callers — and only picks the conversation back up from the notes on the customer's file (COMMAREA) the moment that same customer calls back in.
Key Concepts
1
This is the single most important CICS design concept, and the one that most clearly distinguishes people
who have used CICS from people who have read about it.
2
The arithmetic that forces it. Suppose a task holds its storage while the user thinks.
3
1,000 users, each thinking for 30 seconds between screens
-> 1,000 tasks alive, holding storage and locks,
doing nothing at all4
Release control instead, and those thousand users occupy a handful of tasks, because at any instant almost
all of them are reading rather than submitting.
5
The flow.
task 1: build screen 1, SEND MAP,
RETURN TRANSID('INQC') COMMAREA(state)
-- task ends; storage freed6
... user reads, types, presses enter ...7
task 2: starts fresh. WORKING-STORAGE is new.
state arrives in DFHCOMMAREA.
RECEIVE MAP, validate, build screen 2, RETURN again8
Working storage does not carry over. Each task gets a fresh copy, initialised as declared. Anything that
must survive goes into the COMMAREA — or a channel, or temporary storage.
9
Assuming otherwise is the classic bug, and it is subtle because it sometimes appears to work in a quiet test
region.
10
Every program starts with the same check.
IF EIBCALEN = 0
PERFORM FIRST-TIME-SETUP
PERFORM SEND-FIRST-SCREEN
ELSE
PERFORM PROCESS-USER-INPUT
END-IF.11
EIBCALEN is the length of the COMMAREA received. Zero means this is the first invocation and nothing was
passed, so reading DFHCOMMAREA would address storage you do not own.
EIBCALENDFHCOMMAREA
12
What to keep in the state. Which screen the user was on, what they have entered so far, and any key
needed to re-read the record. Not the record itself, usually — re-read it, because it may have changed
while the user was thinking.
13
That last point is the real design consequence. Between screens, other users are running. A record read on
screen one may be different by screen two, so an update must re-read and check rather than assume.
14
The design exercise interviewers set is a two- or three-screen flow. What they are watching for is
whether you reach for the COMMAREA and EIBCALEN naturally, or assume state persists.
EIBCALEN
15
What the interviewer is probing.1. "What is pseudo-conversational and why is it used?" Probing: the central concept. Stalls:
"A style." Moves up: the program ends after sending the screen and restarts on the next input, so
no resources are held while the user thinks.
16
2. "What holds the state between turns?" Probing: the mechanism. Stalls: "Working storage."
Moves up: the COMMAREA or a channel passed on the RETURN, since the task and its storage are gone.
17
3. "Why not just write a conversational program?" Probing: the consequence. Stalls: "It is
simpler." Moves up: it holds a task, storage and locks for the entire think time, which does not
scale past a handful of users.
18
4. "How does the program know where it is in the flow?" Probing: the implementation. Stalls:
"It remembers." Moves up: a state indicator carried in the COMMAREA, checked on entry —
effectively a hand-written state machine.