Articles
CICS Interview Questions: Pseudo-Conversational Flow, COMMAREA, and Transaction Recovery
Practice CICS interview questions with task lifetimes, COMMAREA validation, pseudo-conversational state, and recoverable transaction boundaries.
A user opens an account screen, thinks for thirty seconds, then confirms an update. In a CICS interview, that pause raises the real design questions: which task is still alive, which state survives, whether a lock is held, and what can be recovered if confirmation fails. Saying “use COMMAREA” answers only part of the problem.
For CICS interview questions, separate the user’s conversation, each task’s lifetime and each recoverable unit of work. Pass a validated continuation contract between interactions, reread business state when needed, and explain which effects CICS can commit or back out. A redisplayed screen is not evidence that an update was undone.
This guide uses IBM CICS Transaction Server 6.x documentation and original practice cases. It does not present invented candidate reports or employer interview frequencies.
What is pseudo-conversational processing?
Official fact: IBM describes pseudo-conversational processing as separate tasks for successive user interactions, commonly one unit of work per task. By comparison, a conversational task remains active while the user reads and enters input. Ending a task releases its associated resources rather than retaining them throughout the user’s thinking time. IBM processing dialogs with users.
The user sees one conversation, but your program must not depend on one suspended invocation resuming at its next instruction. Treat the next interaction as another entry requiring explicit state and validation. Transaction identifiers, task instances and business request identities are different identifiers even when their displayed values look related.
Original exercise: transaction ACCT displays an account-edit screen in task T1. The program returns to CICS with the next transaction identifier and a small continuation area. The user submits the screen later; task T2 starts and decides whether to apply the proposed update.
T1 ends before the user’s confirmation starts T2; the conversation crosses a task boundary. A local variable from T1 is not your documented business-state transfer mechanism. A recoverable update committed by T1 does not become uncommitted again because T2 later fails.
A pseudo-conversational design also needs an answer to interruption: the user can cancel, lose the terminal session or return with old information. Decide which state is merely a convenience for navigation and which state is necessary to recover a business operation.
Trace the two-task account update
Original contract: the continuation carries a schema version, screen phase, account identifier, displayed account version and stable request identifier. T1 reads account A1042 at version 17 and displays an editable contact preference. It does not hold a record-update lock throughout the user’s pause.
| Point in the conversation | What the application knows | Required action |
|---|---|---|
| T1 displays version 17 | Account state observed before user input | Send the screen and explicit continuation |
| T1 ends | Its task resources are released | Do not rely on T1’s local storage or locks |
| Another task updates the account to version 18 | T1’s displayed version is stale | Keep the newer business state authoritative |
| T2 receives confirmation for version 17 | Intent exists, current-state agreement does not | Reread and validate under the chosen concurrency contract |
| T2 commits an accepted change | Recoverable work reached its commit boundary | Save a durable outcome keyed by request identity |
The displayed version is a comparison input, not a lock. A check followed by an unprotected write can still race another writer. Describe an atomic compare-and-update or the platform’s appropriate locked update sequence, including handling a mismatch, before calling this optimistic concurrency safe.
If version 18 is present, do not quietly overwrite it with the version 17 screen’s fields. Redisplay the current account or reject with a clear stale-state message according to the business policy. The right branch depends on whether the user’s requested change can be merged without violating another update.
In a follow-up, explain this distinction: pseudo-conversation reduces long-held resources, while the application still owns the integrity of decisions made across the gap.
What must be checked before reading DFHCOMMAREA?
Official fact: EIBCALEN records the passed communication-area length and is zero when no communication area was passed. IBM’s RETURN documentation explains how COMMAREA and LENGTH pass an area to the next program and specifies the receiving COBOL name DFHCOMMAREA. IBM EIB fields, EXEC CICS RETURN.
Validate the length before accessing a field. “EIBCALEN is nonzero” establishes less than “the expected versioned payload is present.” A short payload can contain the header while omitting the account version or request identity your code assumes exists.
A source-reviewed teaching sketch is:
if EIBCALEN == 0:
initialize the first-screen flow
else if EIBCALEN < required_header_length:
reject the continuation safely
else:
read schema version
validate length for that schema
validate phase and identifiers
continue the allowed branch
This is pseudocode, not compiled COBOL or a substitute for the translated CICS program. For a fixed-size schema, require its exact agreed length unless the versioning contract explicitly permits extensions. For a larger future version, rejecting it deliberately is safer than interpreting its bytes using an older field layout.
Validate the user’s terminal input separately. A correct continuation does not make a newly entered amount, account selection or command valid. Never use the presence of COMMAREA as an authorization decision; the application still needs the appropriate identity and resource checks.
Is COMMAREA a durable transaction log?
No. Official fact: IBM identifies the inter-transaction COMMAREA mechanism as nonrecoverable and describes its scope and storage limitations. It supports passing information in a pseudo-conversational sequence; it is not a recoverable business-state store. IBM communication areas.
Carry the schema, phase, account version and request identity needed to resume; keep durable outcomes in their recoverable store.
In the original account case, the continuation helps T2 reconstruct intent. The durable request outcome belongs in an appropriate recoverable resource if the business requires reconciliation after a task or system failure. Passing “completed” in a screen-state area cannot replace that record.
Do not summarize the limit as “COMMAREA is always 32 KB.” The RETURN reference gives a valid LENGTH range of 0 through 32763 bytes; distributed transfer and control overhead introduce additional constraints. Channels and containers provide another transfer mechanism, but their scope and recovery properties still need explicit design. IBM RETURN reference, communication-area guidance.
In an interview, explain why your small payload is sufficient before choosing a larger mechanism. Carrying an entire database row across the user’s thinking time can encourage stale writes, even when the transfer itself fits within a size limit.
How do LINK, XCTL and RETURN differ?
Official facts: LINK passes control to a program at the next lower application logical level with an eventual return expected. XCTL transfers control at the same logical level without returning to the transferring program. A RETURN from a linked program goes back to its caller; a highest-level RETURN can end the task by returning to CICS. IBM program linking, flow of control, RETURN reference.
Original call trace: the screen controller LINKs to account validation. Validation returns a result; the controller decides whether to display another screen or apply the update. If the controller XCTLs to another controller, it has handed over its logical-level execution instead of creating a normal call-and-return relationship.
Neither a local LINK nor a local XCTL automatically creates a separate task or commits the current unit of work. Avoid describing program modularity as a transaction boundary. A remote invocation can have additional syncpoint and scope options, so establish whether the question is local or distributed before generalizing the trace.
Also remember that command-level error handling belongs to the actual control context. A reusable validation program should define how it returns a rejected business result and how it reports an unexpected CICS command failure; those are different outcomes for its caller.
What can a unit of work recover?
Official facts: CICS syncpoints commit recoverable resource changes. Backout concerns uncommitted updates in the current unit of work, with resource definitions and participation determining what is recoverable. A prior committed unit is not rolled back by a later task’s failure. IBM synchronization points, CICS backward recovery.
Original exercise: T2 changes a recoverable account record and writes a recoverable request-outcome record within one agreed unit of work. If the task fails before commit, those uncommitted changes belong to its backout story. If it commits and the terminal confirmation is lost, the account change can remain durable even though the user never saw the success screen.
Now add an external email or payment API that does not participate as a recoverable resource in that unit of work. CICS backout does not magically unsend the email or reverse that API’s effect. State this external participation assumption explicitly rather than asserting that all services behave that way.
An application may record a durable intent and let a separate worker deliver the external action using a supported repeat-handling contract. That is a design option; it still needs recovery, duplicate detection and reconciliation. Do not call it exactly-once merely because the local database update is transactional.
What does a lost confirmation mean?
Original failure ledger: request R17 has a committed account update, but SEND confirmation does not reach the user. On a repeated submission, a durable record of R17’s completed outcome can allow the application to return the same result instead of applying the update again.
The request identity must refer to the same business intent. Reusing R17 for a different account or changed preference requires rejection or a deliberately documented new-intent rule. Otherwise your repeat handler can acknowledge the wrong operation.
Store the request outcome consistently with the business update. If the update commits but its duplicate-detection record does not, a repeated request may still perform the effect twice. The original exercise assumes both recoverable records share the relevant atomic boundary; it does not prove distributed atomicity across unrelated systems.
A user who missed the confirmation needs the recorded outcome of R17, not another account update triggered by a retry.
For an in-doubt or recovery failure, avoid equating a normal application response with final recovery completion. IBM documents commit-failed, backout-failed and indoubt recovery categories with different handling. Operations evidence and resource state may be required before another update is safe. IBM unit-of-work recovery.
How do you diagnose the failing branch?
Record the transaction identifier, task instance, business request identifier, command and its RESP/RESP2 evidence. Add resource name, continuation version/length, last confirmed syncpoint and whether the effect was local recoverable work or an external action.
“Transaction failed” is too broad. A malformed continuation requires input/version handling; a stale account needs concurrency handling; a failed file command requires its CICS condition; an unresolved commit needs recovery investigation. Reentering the screen flow is not one repair for all four.
The saved Python controls check an original version-1, 16-byte continuation contract, a version-17-versus-18 rejection, and a serial R17 repeat ledger. They do not run a CICS region, exercise locking or simulate recovery-manager durability. Present the design proof and the execution evidence separately.
Practice CICS interview questions through state traces
No CICS-specific question bank was verified.
| Question | Practice focus |
|---|---|
| Design In-Memory Transactions with Snapshots and Savepoints | Separate transaction boundaries, snapshots and savepoints |
| Explain ACID and transactions | Explain which effects belong to one atomic unit |
| Compare Locks and MVCC in a Versioned Store | Trace stale observations and protected updates |
| Implement account CRUD and transfer | Reconcile business updates with account integrity |
| Design Payment Processing with Idempotency and Reconciliation | Use stable intent identities after uncertain confirmation |
Start with Design Payment Processing with Idempotency and Reconciliation, then explain why R17 needs a durable outcome when its confirmation screen disappears.
For your next CICS interview answer, identify the task that ends, the continuation that crosses the gap and the recoverable unit containing the update. Then explain what the user sees after a stale submission or a lost confirmation.
Sources and Further Reading
- IBM processing dialogs with users
- IBM communication areas
- IBM EXEC interface block fields
- IBM EXEC CICS RETURN
- IBM program linking
- IBM flow of control
- IBM synchronization points
- IBM CICS backward recovery
- IBM unit-of-work recovery
Research checked October 5, 2026. ACCT, T1/T2 and R17 are original examples; no CICS execution or employer frequency is claimed.