A terminal user may pause for two minutes on an order screen before pressing Enter. A conversational CICS program keeps the task alive during that pause. A pseudo-conversational program sends the screen, returns control to CICS, and starts again when the next AID key arrives.
What is conversational processing in CICS?
Conversational processing keeps one task running across several screen interactions. The program sends a map, waits for terminal input, receives the input, processes it, sends the next screen, and waits again.
EXEC CICS SEND MAP('ORDMAP')
MAPSET('ORDSET')
ERASE
END-EXEC
EXEC CICS RECEIVE MAP('ORDMAP')
MAPSET('ORDSET')
END-EXECThis design is easy to understand because one task holds the program flow from start to finish. The cost is that the task can keep storage, locks, and other resources while the user is reading the screen or away from the keyboard.
What is pseudo-conversational processing?
Pseudo-conversational processing breaks the dialog into short transactions. Each task handles one input, sends the next screen, saves state, and ends. CICS starts the next task when the user sends input from the terminal.
EXEC CICS RETURN
TRANSID('ORDR')
COMMAREA(WS-SCREEN-STATE)
LENGTH(LENGTH OF WS-SCREEN-STATE)
END-EXECThe user still sees a conversation. CICS sees smaller tasks that release resources between terminal waits. That is why pseudo-conversational design is the normal choice for many CICS terminal applications.
Conversational vs pseudo-conversational at a glance
| Area | Conversational | Pseudo-conversational |
|---|---|---|
| Task life | One task stays active across user waits. | Each screen step runs as a separate task. |
| Storage | Held while waiting for terminal input. | Released when the task returns to CICS. |
| State handling | State can stay in task storage. | State must be passed or stored between tasks. |
| Typical use | Rare cases where several updates must stay in one unit of work. | Most screen flows with several terminal interactions. |
How COMMAREA keeps the conversation state
In a pseudo-conversational design, the program needs a place to remember what happened on the previous screen. A common method is COMMAREA on EXEC CICS RETURN TRANSID. IBM documents this as a safe technique for passing data between successive transactions in a CICS pseudo-conversation.
01 WS-SCREEN-STATE.
05 WS-STEP-NO PIC 9(02).
05 WS-ACCOUNT-NO PIC X(12).
05 WS-LAST-ACTION PIC X(08).
EXEC CICS RETURN
TRANSID('ACCT')
COMMAREA(WS-SCREEN-STATE)
LENGTH(LENGTH OF WS-SCREEN-STATE)
END-EXECOn the next attach, the receiving COBOL program checks EIBCALEN. If it is greater than zero, CICS passed a communication area and the program can use DFHCOMMAREA to restore the dialog state.
LINKAGE SECTION.
01 DFHCOMMAREA.
05 CA-STEP-NO PIC 9(02).
05 CA-ACCOUNT-NO PIC X(12).
05 CA-LAST-ACTION PIC X(08).
PROCEDURE DIVISION.
IF EIBCALEN > 0
MOVE DFHCOMMAREA TO WS-SCREEN-STATE
ELSE
MOVE 1 TO WS-STEP-NO
END-IFWhere AID keys fit
An AID key tells CICS that the terminal user has sent input. Enter, PF3, PF5, and Clear are common examples. A pseudo-conversational program usually receives the map, checks the AID key, decides the next action, and returns with the next transaction id when more input is needed.
EVALUATE EIBAID
WHEN DFHENTER
PERFORM PROCESS-INPUT
WHEN DFHPF3
EXEC CICS RETURN END-EXEC
WHEN OTHER
MOVE 'PRESS ENTER OR PF3' TO MSGO
END-EVALUATEWhen conversational design can still be used
IBM notes that conversational processing is not generally favored, but it can be needed when several interactions must be kept in one unit of work. For example, a tightly controlled update may need all screen steps to commit together or back out together. Even then, the design should be reviewed carefully because the task holds resources while waiting.
Common pseudo-conversational mistakes
Forgetting to save enough state
The next task starts fresh. If the program does not save the current step, key values, and validation results, it cannot know what screen it is processing.
Passing too much data in COMMAREA
A communication area should hold state, not a large working copy of every screen field and table. IBM documents an upper limit for COMMAREA length, but smaller state areas are easier to maintain and safer across routing changes.
Ignoring EIBCALEN
Do not assume DFHCOMMAREA contains valid data. Check EIBCALEN before using it, especially when the same transaction can start from a menu, a direct transaction code, or a previous screen.
Review checklist
- Confirm whether the program waits inside one task or returns after each screen.
- For pseudo-conversational code, check every
RETURN TRANSIDpath. - Verify the state passed in
COMMAREAor channels is enough for the next task. - Check
EIBCALENbefore readingDFHCOMMAREA. - Keep database locks and recoverable updates away from long terminal waits.
- Test Enter, PF keys, Clear, timeout, and direct transaction start paths.
Related Mainframe Forum guides
For connected CICS topics, read CICS Multitasking and Multithreading, How CICS Transactions Work, CICS Transactions, CICS Commands Quick Reference, CICS Interview Questions, and COBOL PERFORM Statement.
External references
IBM documents these topics in CICS conversational and pseudo-conversational programming, processing dialogs with users, the COMMAREA, and EXEC CICS RETURN.
FAQ
What is the main difference between conversational and pseudo-conversational CICS?
A conversational program keeps one task active while waiting for the user. A pseudo-conversational program ends after sending the screen and starts again when the user sends input.
Why is pseudo-conversational programming common in CICS?
It releases task resources between terminal waits, which helps storage use and throughput in regions with many users.
What does RETURN TRANSID do?
RETURN TRANSID tells CICS which transaction should run when the next input arrives from the terminal.
Why should a COBOL CICS program check EIBCALEN?
EIBCALEN tells the program whether a COMMAREA was passed. Check it before reading DFHCOMMAREA.
