Key Takeaways: Advanced CICS Programming

  1. Temporary Storage Queues (TSQs) are your scratch pad for data that must persist across pseudo-conversational task boundaries. They support random access by item number, making them ideal for browse/scroll patterns. Always include EIBTRMID in the queue name and always delete TSQs when the transaction exits.

  2. Transient Data Queues (TDQs) are event channels. Reads are destructive (items are consumed). Intrapartition TDQs with trigger levels enable automatic processing when a threshold is reached — perfect for audit logging and decoupled batch-like operations within CICS.

  3. The START command enables asynchronous processing. Use it when the user's transaction should not wait for secondary operations (notifications, reports, downstream processing). The started transaction uses RETRIEVE to get the passed data. Always design a batch backup for async operations in case the started transaction fails.

  4. Channels and containers are the modern alternative to COMMAREA. They remove the ~32 KB size limit, support named data items, and map naturally to web service JSON/XML payloads. Use them for new development, especially programs that will be exposed as services.

  5. The browse/scroll pattern is one of CICS's most common transaction types: load results into a TSQ, display one page at a time, and handle PF7/PF8 for pagination. Track the top-item position and total-items in the COMMAREA. Handle boundary conditions (already at top, already at bottom).

  6. Multi-screen transactions use a state machine in the COMMAREA. The state field determines which screen to display and which logic to execute on the return. Design the state machine explicitly with a diagram before coding.

  7. Optimistic locking is essential for CICS update transactions. Store original values in the COMMAREA, include them in the UPDATE's WHERE clause, and check SQLERRD(3) to detect concurrent changes. Pessimistic locking (SELECT FOR UPDATE) is incompatible with pseudo-conversational design.

  8. HANDLE ABEND provides error recovery. Use it to intercept fatal errors, log diagnostics to a TDQ, clean up TSQs, and display a user-friendly message instead of a cryptic CICS error screen. Use application-specific abend codes (not CICS reserved 'A' prefix).

  9. CICS web services bridge old and new. Existing COBOL programs can serve as REST API endpoints using channels/containers and CICS pipeline processing. The same business logic can serve 3270 terminals and modern web/mobile clients.

  10. Defensive programming in CICS is non-negotiable because a misbehaving program affects all users in the region. Check RESP on every command, handle MAPFAIL on every RECEIVE, clean up TSQs, keep transactions under 1 second, and never use STOP RUN, COBOL file I/O, or DISPLAY.

  11. TSQ cleanup is your responsibility. CICS does not automatically clean up orphaned TSQs. Implement a periodic cleanup transaction (via START with INTERVAL) that deletes stale queues matching your application's naming convention.

  12. LINK is for subroutines (call and return); XCTL is for navigation (transfer and do not return). Use LINK for validation routines, logging utilities, and reusable business logic. Use XCTL for transferring between major transaction modules.