CICS transaction flow

This section outlines how CICS processes transactions.

To begin an online session with CICS, you usually begin by “signing on,” which is the process that identifies you to CICS. Signing on to CICS gives you the authority to invoke certain transactions. When signed on, you invoke the particular transaction that you intend to use. A CICS transaction is usually identified by a one to four-character transaction identifier or TRANSID, which is defined in a table that names the initial program to be used for processing the transaction.

Application programs are stored in a library on a direct access storage device (DASD) that is attached to the processor. They can be loaded when the system is started or simply loaded as required. If a program is in storage and is not being used, CICS can release the space for other purposes. When the program is next needed, CICS loads a fresh copy of it from the library.

In the time it takes to process one transaction, the system might receive messages from several terminals. For each message, CICS loads the application program (if it is not already loaded) and starts a task to execute it. Thus, multiple CICS tasks can run concurrently.

CICS maintains a separate thread of control for each task. When, for example, one task is waiting to read a disk file, or to get a response from a terminal, CICS can give control to another task. Tasks are managed by the CICS task control program.

CICS manages both multitasking and requests from the tasks themselves for services (of the operating system or of CICS itself). This process allows CICS processing to continue while a task is waiting for the operating system to complete a request on its behalf. Each transaction that is being managed by CICS is given control of the processor when that transaction has the highest priority of those that are ready to run.

While it runs, your application program requests various CICS facilities to handle message transmissions between it and the terminal and to handle any necessary file or database accesses. When the application is complete, CICS returns the terminal to a standby state.

Program Control

A transaction (task) can execute several programs in the course of completing its work.

The program definition contains one entry for every program used by any application in the CICS system. Each entry holds, among other things, the language in which the program is written. The transaction definition has an entry for every transaction identifier in the system, and the important information kept about each transaction is the identifier and the name of the first program to be executed on behalf of the transaction.

These two sets of definitions, transaction, and program work in concert:
  1. The user types in a transaction identifier at the terminal (or the previous transaction determined it).
  2. CICS looks up this identifier in the list of installed transaction definitions, which tells CICS which program to invoke first.
  3. CICS looks up this program in the list of installed transaction definitions, finds out where it is, and loads it (if it is not already in the main storage).
  4. CICS builds the control blocks necessary for this particular combination of transaction and terminal using information from both sets of definitions. For programs in command-level COBOL, this includes making a private copy of working storage for this particular execution of the program.
  5. CICS passes control to the program, which begins running using the control blocks for this terminal. This program can pass control to any other program in the list of installed program definitions, if necessary, in the course of completing the transaction.

There are two CICS commands for passing control from one program to another. One is the LINK command, which is similar to a CALL statement in COBOL. The other is the XCTL (transfer control) command, which has no COBOL counterpart. When one program links another, the first program stays in main storage. When the second (linked-to) program finishes and gives up control, the first program resumes at the point after the LINK. The linked-to program is considered to be operating at one logical level lower than the program that does the linking.

In contrast, when one program transfers control to another, the first program is considered terminated and the second operates at the same level as the first. When the second program finishes, control is returned not to the first program, but to whatever program last issued a LINK command.

Some people like to think of CICS itself as the highest program level in this process, with the first program in the transaction as the next level down, and so on.

A sound principle of CICS application design is to separate the presentation logic from the business logic. Communication between the programs is achieved by using the LINK command, and data is passed between such programs in the COMMAREA. Such a modular design provides not only a separation of functions, but also much greater flexibility for the web enablement of existing applications using new presentation methods.