CICS Transactions & Commands

Learn how CICS transaction IDs work, what pseudo-conversational programming means and why it matters at scale, and get an overview of common CICS commands like SEND, RECEIVE, and READ.

Introduction

The previous lesson explained what CICS is and why it exists. This lesson goes one level deeper into how it actually works: how a specific piece of interactive work is identified and kicked off with a transaction ID, why CICS programs are traditionally written in a very particular style called pseudo-conversational programming, and what the handful of everyday CICS commands — SEND, RECEIVE, READ — actually do. None of this requires you to write production CICS code; the goal is a solid conceptual map you could recognize and reason about if you saw it in a real shop.

What You Will Learn in This Lesson

What a CICS transaction ID is and how it triggers a program
What pseudo-conversational programming means, conceptually
Why this style exists and why it matters at massive scale
An overview of common CICS commands: SEND, RECEIVE, READ, and a few others
A simplified, annotated walkthrough of what a CICS program does

The Transaction ID

Every unit of interactive work in CICS is identified by a transaction ID (often shortened to "trans-id" or "tranid") — typically a short, four-character code such as INQY (an account inquiry) or WDRL (a withdrawal). When a user takes an action — a teller pressing a function key, an ATM sending a request, a screen submitting a form — that action is associated with a specific transaction ID, and CICS uses it to look up exactly which program should run and what resources that program is allowed to use.

Concept	Analogy	Role
Transaction ID	A menu item number	Identifies WHAT the user wants to do
Program	The kitchen preparing the order	Contains the actual logic that does the work
Terminal / screen	The table the order came from	Where the request originated and the response is shown
CICS region	The restaurant itself	Coordinates everything so many orders run smoothly at once

This indirection is deliberate and powerful: CICS controls, at a system level, exactly which transaction IDs exist, which programs they map to, and who is authorized to use them (working together with RACF, covered in an upcoming lesson). A shop can add, disable, or redirect a transaction without touching the terminals or the users at all — only the mapping inside CICS changes.

Pseudo-Conversational Programming

A "conversational" program is the intuitive way most people first imagine an interactive program working: it displays a screen, then sits there, holding onto memory and system resources, waiting indefinitely for the user to respond. That model works fine for a handful of users. It falls apart at the scale CICS was built for, where thousands of users might be mid-interaction at any given moment — holding resources for every one of them while they think, type, or simply walk away from their desk would exhaust the system almost immediately.

CICS solves this with pseudo-conversational programming: from the user's point of view, the interaction feels continuous and conversational (screen, response, screen, response), but underneath, the program actually ends and releases all of its resources every single time it sends a screen and waits for input. When the user finally responds, CICS starts the transaction again, essentially from scratch, and the new instance of the program figures out where the conversation left off (typically using data CICS temporarily stored on the user's behalf) before continuing.

The Core Idea

Pseudo-conversational programming trades a small amount of extra bookkeeping in the program for a massive win in scalability: no resources are ever held hostage waiting on a human to think or type.

Why Pseudo-Conversational Matters at Scale

Consider a bank with tens of thousands of active tellers, ATMs, and online banking sessions at a single moment. If every one of those sessions held onto CICS resources — memory, control blocks, database locks — for as long as a human took to read a screen and decide what to do next, the system would run out of capacity almost immediately, no matter how powerful the underlying hardware was. Pseudo-conversational design means CICS only ever holds resources for the brief instant it is actually doing computational work — milliseconds — and is completely free the rest of the time, even while a human is staring at their screen thinking.

This is one of the clearest examples in this entire course of how mainframe design philosophy differs from a typical web or desktop application: the system is engineered around what happens when ordinary behavior is multiplied by an enormous number of concurrent users, not around what feels simplest to code for one user in isolation.

Common CICS Commands

CICS commands are embedded directly inside a host language — almost always COBOL in production shops — using a special EXEC CICS ... END-EXEC block. The compiler recognizes these blocks and translates them into calls CICS understands at runtime. At an overview level, three commands come up constantly:

Command	Purpose	Rough Analogy
SEND	Sends a screen or message out to the user's terminal	Displaying output to the user
RECEIVE	Reads whatever the user typed or submitted from the terminal	Reading user input
READ	Reads a record from a file or dataset (often a VSAM file)	A database/file lookup
WRITE / REWRITE	Adds a new record, or updates an existing one	Saving or updating data
RETURN	Ends this instance of the transaction (the "pseudo" part in action)	Releasing all resources and waiting for the next request

Conceptual shape of embedded CICS commands (illustrative, not full syntax)

EXEC CICS
    SEND MAP('ACCTMAP') MAPSET('ACCTSET')
END-EXEC

EXEC CICS
    RECEIVE MAP('ACCTMAP') MAPSET('ACCTSET')
END-EXEC

EXEC CICS
    READ FILE('ACCTFILE') INTO(ACCOUNT-RECORD)
         RIDFLD(ACCOUNT-NUMBER)
END-EXEC

EXEC CICS
    RETURN TRANSID('INQY') COMMAREA(SAVED-DATA)
END-EXEC

Reading this conceptually

Click Run to see what this code prints.

A Simplified CICS Program Walkthrough

Put together, a typical CICS-driven account inquiry might unfold like this, entirely conceptually:

A teller enters transaction ID INQY and an account number on their terminal.
CICS looks up INQY, finds the associated COBOL program, and starts it.
The program uses RECEIVE to read the account number the teller typed.
The program uses READ to fetch the matching account record from a file (or, more commonly today, issues SQL against DB2 — covered in the next lesson).
The program uses SEND to display the account balance and details back to the teller's screen.
The program issues RETURN, ending this instance and freeing all resources — even though, from the teller's perspective, the "session" is still open and ready for the next request.

Common Mistakes

Avoid These Mistakes

Assuming a CICS transaction stays "alive" and holds memory while a user thinks — pseudo-conversational design specifically avoids this.
Confusing the transaction ID with the program name — the transaction ID is the entry point users invoke; CICS maps it internally to the actual program.
Treating SEND/RECEIVE/READ as full syntax to memorize at this stage — the goal here is recognizing their purpose conceptually, not writing production CICS COBOL yet.
Assuming pseudo-conversational is an implementation detail that does not matter — it is precisely why CICS can support massive numbers of concurrent users on shared hardware.

Best Practices

When reasoning about a CICS transaction, always ask what data it needs to "remember" between screens — that is the core challenge pseudo-conversational design solves.
Learn to read EXEC CICS ... END-EXEC blocks as intent (send a screen, read input, look up a record) even before memorizing exact syntax.
Keep the restaurant analogy (transaction ID as menu item, program as kitchen, terminal as table) handy — it maps cleanly onto real production terminology.
Notice how RETURN ties directly back to scalability — every command in CICS exists to serve reliability and throughput at scale, not just correctness.

Frequently Asked Questions

What language are CICS commands written in?

CICS commands are embedded inside a host programming language, most commonly COBOL in production shops, using EXEC CICS ... END-EXEC blocks. CICS itself is not a programming language.

Why not just let a program wait for user input the normal way?

Because holding a program's memory and system resources open for every user who is simply thinking or typing would exhaust system capacity almost instantly at the scale CICS operates. Pseudo-conversational design frees those resources between each user action.

Is a transaction ID the same as the program name?

No. The transaction ID is a short code the user or terminal invokes; CICS maps it internally to the program that should actually run. This indirection lets a shop change what runs behind a transaction ID without changing anything the user does.

Do modern CICS programs still use plain file READ commands?

Some still read VSAM files directly with commands like READ, but a large share of modern CICS applications retrieve and update data through embedded SQL against DB2 instead, which is exactly what the next lesson covers.

Key Takeaways

A transaction ID is the short code that tells CICS which program to run for a given piece of interactive work.
Pseudo-conversational programming makes an interaction feel continuous to the user while actually ending and restarting the program between each screen.
This design exists to prevent resources from being held hostage while a human thinks, letting CICS scale to enormous numbers of concurrent users.
SEND displays output, RECEIVE reads input, READ retrieves a record, and RETURN ends the current instance while telling CICS how to resume later.
CICS commands are embedded in a host language (typically COBOL) rather than being a language of their own.

Summary

Transaction IDs, pseudo-conversational design, and a small set of commands like SEND, RECEIVE, and READ are what let CICS support enormous numbers of simultaneous, real-time users without buckling under the load. The pattern to remember is simple: display something, free every resource, wait, and only spring back to life the instant there is real work to do. In the next lesson, you will meet DB2, the relational database that both CICS transactions and batch jobs rely on to store and retrieve the data behind everything you have seen so far.

Next Lesson →