CICS Fundamentals for COBOL

Analogy categoryAnalogies

What CICS Provides for Online COBOL Programs

CICS, Customer Information Control System, is a transaction processing monitor that runs on the mainframe alongside batch job scheduling, giving COBOL programs the ability to serve online, terminal-driven or now browser-driven transactions by managing screen input and output, task scheduling, and resource sharing across potentially thousands of concurrent users hitting the same load module. Rather than a batch program's linear flow from job start to STOP RUN, a CICS program is written as a transaction, identified by a four-character transaction ID such as CICS entered at a 3270-style terminal or invoked through a web service, that runs briefly, does its unit of work, and returns control to CICS itself rather than to an operating system. This model lets a single compiled COBOL load module be shared efficiently across many simultaneous users, since CICS manages multithreading and storage isolation between tasks rather than each user needing a dedicated operating-system process, which is what let banks run thousands of concurrent teller and ATM transactions against the same core COBOL programs for decades.

🏏

Cricket analogy: CICS is like the IPL's central match-scheduling and broadcast infrastructure that lets the same core rules engine run dozens of simultaneous matches across different stadiums, managing which umpire and ground resources are active for each game rather than each match needing its own independent league.

Pseudo-Conversational Design

Because CICS historically could not afford to hold a program and its storage in memory for the entire time a human user was reading a screen and deciding what to type next, the standard CICS design pattern is pseudo-conversational: a transaction processes one screen interaction, sends output to the terminal with EXEC CICS SEND MAP, then immediately terminates by issuing EXEC CICS RETURN with a TRANSID and COMMAREA, releasing all its storage back to the system, and CICS automatically re-invokes that same transaction ID fresh from the top when the user next presses Enter or a function key. This means a pseudo-conversational program cannot rely on WORKING-STORAGE values surviving between one screen and the next the way a batch program relies on values persisting across the whole run, so any state that must carry forward, such as which record the user is currently editing, must be explicitly passed forward in the COMMAREA on the RETURN statement and read back at the very start of the next invocation. This design dramatically reduces how much storage CICS must hold resident at any moment, since a program only occupies memory for the few milliseconds it takes to process one screen, not for the seconds or minutes a human spends reading it.

🏏

Cricket analogy: Pseudo-conversational design is like a bowler who completes exactly one delivery, walks back to their mark, and effectively 'restarts' fresh for the next ball, carrying forward only what's written on the over-count scoreboard rather than holding a continuous private memory of the whole over in their head.

COMMAREA and Common EXEC CICS Commands

The COMMAREA, short for communication area, is the primary mechanism for passing data both between successive pseudo-conversational invocations of the same transaction and between one CICS program and another it links to or transfers control to, and it is received in the LINKAGE SECTION via EXEC CICS RECEIVE MAP or through the DFHCOMMAREA field automatically made available at program entry. A program typically checks EIBCALEN, a field in the CICS-supplied Execute Interface Block that reports the length of the incoming COMMAREA, to determine whether this is the very first invocation of the transaction, when EIBCALEN is zero, versus a subsequent screen interaction where COMMAREA holds context like the last key processed. Beyond SEND MAP and RETURN, common EXEC CICS commands include READ and WRITE for accessing VSAM files under CICS control, LINK to call another CICS program synchronously and get control back, XCTL to transfer control to another program without expecting to return, and STARTBR/READNEXT/ENDBR for browsing sequentially through a VSAM file's keys.

🏏

Cricket analogy: COMMAREA is like the handover note a fielding captain passes to a substitute fielder coming on, briefing them on the field placements and which batter is on strike so the substitute doesn't need the whole match history, just the current relevant state.

cobol

       WORKING-STORAGE SECTION.
       01  WS-COMMAREA.
           05  WS-LAST-CUST-ID     PIC X(6).
           05  WS-SCREEN-STATE     PIC X(1).

       LINKAGE SECTION.
       01  DFHCOMMAREA             PIC X(7).

       PROCEDURE DIVISION.
           IF EIBCALEN = 0
               MOVE LOW-VALUES TO WS-COMMAREA
               PERFORM 1000-SEND-INITIAL-MAP
           ELSE
               MOVE DFHCOMMAREA TO WS-COMMAREA
               PERFORM 2000-PROCESS-USER-INPUT
           END-IF

           EXEC CICS RETURN
               TRANSID('CICS')
               COMMAREA(WS-COMMAREA)
               LENGTH(LENGTH OF WS-COMMAREA)
           END-EXEC.

EIBCALEN, part of the Execute Interface Block automatically available to every CICS program, is the standard way to detect a first-time transaction invocation: a value of zero means no COMMAREA was passed in, indicating this is the initial entry rather than a continuation of a pseudo-conversational dialogue.

Never write a CICS program with a tight PERFORM UNTIL loop waiting for user input the way a batch program waits on file I/O; this ties up a CICS task and its storage indefinitely, starving other concurrent transactions. Always terminate with EXEC CICS RETURN after each screen interaction and let CICS re-invoke the transaction on the next user action, which is the entire point of pseudo-conversational design.

CICS is a transaction processing monitor that lets COBOL programs serve many concurrent online users against one shared load module.
Pseudo-conversational design processes one screen interaction per invocation, then RETURNs, freeing storage between user actions.
State that must survive between screens must be explicitly passed forward in the COMMAREA, not left in WORKING-STORAGE.
EIBCALEN reports the incoming COMMAREA length and is the standard way to detect a transaction's first invocation.
EXEC CICS SEND MAP displays a screen; EXEC CICS RETURN ends the current task and can specify the next TRANSID.
LINK calls another CICS program and returns control; XCTL transfers control without expecting to return.
Never block a CICS transaction waiting on user input in a loop; always RETURN and let CICS re-invoke on the next action.