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.

CICS Multitasking and Multithreading: Tasks, QR TCB, and Threadsafe Programs

A CICS region may receive terminal input from hundreds of users while the same order-entry program is already loaded in storage. CICS does not normally load a private copy of the program for every user. It starts tasks, dispatches them, and lets those tasks share program code safely when the program follows CICS rules.

One program, many tasks.

What is a CICS task?

A CICS task is one execution of a transaction for one request. If five users run transaction ORDR, CICS can create five separate tasks. Each task has its own control information and its own path through the application, even when all five tasks use the same program.

This is different from saying that five copies of the program are loaded. CICS can keep one copy of the executable program and dispatch several tasks through it at different times.

What is CICS multitasking?

CICS multitasking means that more than one task can be active in the region. One task may be waiting for a VSAM read, another may be waiting for terminal input, and a third may be ready to run. The CICS dispatcher decides which task gets control.

From the user's side, several transactions appear to run at once. Inside the region, CICS gives control to work that is ready and takes control back when a task waits for CICS or system service.

What is CICS multithreading?

CICS multithreading means that several tasks can use the same copy of an application program. Task A can enter program ORDRPGM, issue an EXEC CICS READ, and wait. While Task A is waiting, Task B can enter the same loaded program copy.

That is why CICS programs must not keep user-specific state in a place that can be damaged by another task. The application must be safe when control leaves the program at an EXEC CICS command and later returns.

Multitasking vs multithreading

Term	Meaning in CICS	Example
Task	One execution of a transaction request	User 1 runs ORDR to add an order
Multitasking	Many tasks are active in the region	ORDR, PAYM, and INQY tasks are all active
Multithreading	Many tasks can pass through one loaded program copy	Several users run the same ORDRPGM program
Threadsafe	The program can run safely when CICS allows concurrent execution on open TCBs	A program protects shared storage before update

Why quasi-reentrant programs matter

IBM describes CICS application programs as needing quasi-reentrant behavior. In plain terms, the program must be in a clean, consistent state when it gets control and whenever it gives control back to CICS, such as at an EXEC CICS command.

For COBOL programs, CICS gets a separate copy of working storage for each task invocation. That protects normal WORKING-STORAGE data from being shared accidentally across users. The program code itself still has to behave correctly when several tasks use the same loaded program.

QR TCB and open TCB in simple terms

A TCB is a dispatchable unit of work in z/OS. Older CICS application work often ran under the quasi-reentrant TCB, usually called the QR TCB. The QR TCB serializes quasi-reentrant application code so only one such program is running on that TCB at a time.

Modern CICS can also run eligible work on open TCBs. This matters for programs defined as THREADSAFE or REQUIRED and for workloads that use resource managers such as Db2, IBM MQ, or JVM servers. A wrong THREADSAFE definition can expose bad shared-storage code that looked harmless under QR serialization.

PROGRAM CONCURRENCY settings

The CICS PROGRAM resource definition includes a CONCURRENCY attribute. This is not a decoration field. It tells CICS what the program promises about shared-resource safety.

Setting	Meaning	Support note
QUASIRENT	The program follows quasi-reentrant rules.	CICS keeps it on the QR TCB for application execution.
THREADSAFE	The program is written to protect shared resources.	CICS may let it continue on an open TCB after some resource-manager work.
REQUIRED	The program must run on an open TCB.	Use only when the program meets the required API and threadsafe rules.

Where shared data causes trouble

Most CICS multitasking bugs show up when programs update shared resources without control. Examples include the common work area, shared TS queues used like global scratchpads, user exits, assembler static storage, and non-CICS APIs used from OPENAPI programs.

EXEC CICS ENQ RESOURCE('ORDR-CONTROL') END-EXEC

   *> Update shared control information here.

EXEC CICS DEQ RESOURCE('ORDR-CONTROL') END-EXEC

The exact protection method depends on the resource and site standards. The point is simple: if two tasks can update the same value, the program must control that update.

Common mistakes

Calling every CICS program threadsafe

THREADSAFE is a claim about the application logic. Do not set it just to chase performance. Review shared storage, non-CICS calls, exits, and resource-manager behavior first.

Confusing task with transaction name

A transaction code such as ORDR is a definition. A task is one running instance of that transaction request. Many tasks can use the same transaction code.

Assuming working storage is shared by every user

For normal CICS COBOL programs, each task invocation gets its own working-storage copy. Shared-data problems more often come from global storage, external resources, exits, or static storage outside normal COBOL working storage.

Review checklist for CICS programs

• Confirm the transaction code and program name involved in the incident.
• Check the PROGRAM definition for CONCURRENCY and API.
• Identify whether the program runs under QR TCB, open TCB, or switches between them.
• List every shared resource updated by the program.
• Check whether shared updates are protected by site-approved locking or serialization.
• Review long CPU loops between EXEC CICS calls because they can hold the QR TCB too long.
• Test with more than one user task, not only with a single terminal session.

Related Mainframe Forum guides

For connected CICS topics, read How CICS Transactions Work, Conversational vs Pseudo-Conversational Programming, CICS Commands Quick Reference, CICS Transactions, CICS Interview Questions, and COBOL RENT Compiler Option.

External references

IBM documents these topics in multithreading, reentrant, quasi-reentrant, and threadsafe programs, PROGRAM resource definitions, quasi-reentrant application programs, and how a CICS transaction flows.

FAQ

What is the difference between CICS multitasking and multithreading?

Multitasking means many CICS tasks are active in the region. Multithreading means many tasks can use the same loaded application program copy.

What is a CICS task?

A CICS task is one execution of a transaction request. If ten users run the same transaction, CICS can create ten tasks.

Does every CICS COBOL task share the same working storage?

No. For normal CICS COBOL programs, each task invocation gets its own working-storage copy. Shared data must still be handled carefully when it lives outside that private copy.

What does THREADSAFE mean in CICS?

THREADSAFE means the application logic is written to protect shared resources when CICS allows the program to run on open TCBs.