CICS: Online COBOL

What is CICS?

CICS (Customer Information Control System) is a powerful, mixed-language application server that runs on the IBM mainframe operating system called z/OS. While standard batch COBOL programs run in the background processing massive files, CICS allows COBOL programs to be executed online, interacting with users through terminals in real time.

If you’ve ever interacted with a green-screen terminal at an airline desk or a bank, you’ve likely triggered a CICS transaction on a mainframe. CICS acts as the middleman between the terminal and the COBOL program, handling the networking, threading, and screen rendering.

The Pseudo-Conversational Model

One of the most profound paradigm shifts when moving from traditional desktop programming to CICS is understanding how memory and state work. A naive approach to writing an online application would be to wait for user input in a loop.

However, in a high-volume mainframe environment, this is incredibly inefficient. Instead, CICS uses pseudo-conversational processing. When a COBOL program wants to ask the user a question, it sends the screen to the terminal and then completely terminates.

Because the program fully stops, all variables in the WORKING-STORAGE SECTION are lost. We can simulate this loss of state in standard COBOL. Notice how the program below resets to “FRESH” every time it starts, regardless of what it was changed to previously:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. WIPE-SIM.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 USER-STATE PIC X(10) VALUE "FRESH".
       PROCEDURE DIVISION.
           DISPLAY "Initial state: " USER-STATE.
           MOVE "LOGGED-IN" TO USER-STATE.
           DISPLAY "Modified state: " USER-STATE.
           STOP RUN.

Initial state: FRESH     
Modified state: LOGGED-IN 

To preserve state across these different invocations, the program passes a chunk of memory called the COMMAREA to CICS before it dies, and CICS hands it back to the new invocation when the user hits Enter.

Executing CICS Commands

You don’t use standard ACCEPT or DISPLAY for terminal input/output in CICS. Instead, you use the EXEC CICS block to send special commands. These commands are parsed by the CICS translator before your code is ever compiled, turning them into standard COBOL CALL statements.

We can simulate what the translator outputs. Under the hood, an EXEC CICS block becomes a CALL to a CICS interface module:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. TRANSLATOR.
       PROCEDURE DIVISION.
           DISPLAY "CALL 'DFHEI1' USING DFHEIGDI".
           STOP RUN.

CALL 'DFHEI1' USING DFHEIGDI

Here is how you would actually receive input from a user’s terminal map (screen) in a real CICS environment. (Note: this code requires a CICS mainframe to execute.)

       IDENTIFICATION DIVISION.
       PROGRAM-ID. CICS-EX-1.
       PROCEDURE DIVISION.
           EXEC CICS 
               RECEIVE MAP('MENU') 
               MAPSET('MENUMST') 
               INTO(MENU-INPUT) 
           END-EXEC.
           STOP RUN.

There is no output block here, and that is deliberate. This program cannot run on this site — nothing outside a CICS region can execute EXEC CICS, so no output was captured and none is shown. What it does is place the terminal’s input into the MENU-INPUT record; the syntax is from the IBM CICS Transaction Server for z/OS documentation on Basic Mapping Support. Everywhere else in this course an output block means a program was compiled and its output byte-matched at build time. Here that claim would be false, so the block is absent rather than filled with something plausible.

When you are ready to terminate your program and wait for the user to respond, you use a RETURN command, optionally passing the state via COMMAREA.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. CICS-EX-2.
       PROCEDURE DIVISION.
           EXEC CICS 
               RETURN TRANSID('NEXT') 
               COMMAREA(WS-COMMAREA) 
               LENGTH(LENGTH OF WS-COMMAREA)
           END-EXEC.
           STOP RUN.

Again no output block: the program ends, and CICS invokes transaction NEXT the next time this terminal sends input, carrying WS-COMMAREA forward. Syntax per the IBM CICS documentation on RETURN and passing data with COMMAREA.

When the user hits enter, the new program invocation can check if it has received a COMMAREA using a special system variable called EIBCALEN (Execute Interface Block Communication Area Length).

Can you predict the output of the following simulated check, assuming it’s the second invocation and the COMMAREA contains “STATE-DATA”?

       IDENTIFICATION DIVISION.
       PROGRAM-ID. SIM-STATE.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 SIMULATED-EIBCALEN PIC 9 VALUE 1.
       01 SIMULATED-COMMAREA PIC X(10) VALUE 'STATE-DATA'.
       PROCEDURE DIVISION.
           IF SIMULATED-EIBCALEN = 0
               DISPLAY 'First invocation'
           ELSE
               DISPLAY 'Resumed with state: ' SIMULATED-COMMAREA
           END-IF.
           STOP RUN.

Resumed with state: STATE-DATA