CICS Conversational vs Pseudo-Conversational Programming

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.

Return between screens.

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-EXEC

This 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-EXEC

The 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-EXEC

On 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-IF

Where 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-EVALUATE

When 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 TRANSID path.
• Verify the state passed in COMMAREA or channels is enough for the next task.
• Check EIBCALEN before reading DFHCOMMAREA.
• 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.