CICS Fundamentals for COBOL

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.

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.

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.