In CICS, a transaction is a unit of work identified by a transaction ID (TRANSID). When a user or system invokes that TRANSID, CICS starts a task—a separate thread of control—and runs the program (or programs) associated with the transaction. Many tasks can run at once; CICS switches between them so that multiple users and transactions are served concurrently. This page explains what a transaction and a task are, how the transaction flow works from invocation to completion, and how CICS manages concurrent transaction processing.
Imagine a counter where people take a number and wait for their turn. Each number is like a transaction code (TRANSID). When someone calls a number, the clerk (CICS) looks up what to do for that number, then starts working on that person's request (that is a task). The clerk can put one request on hold while waiting for something (e.g. a signature) and help the next person, then come back. So many people are being served at once, each with their own "task," and each task is tied to a transaction code that says which program (recipe) to run.
A CICS transaction is identified by a transaction ID: a one- to four-character identifier (e.g. MENU, INQ1, TXN). The TRANSID is defined in the CICS resource definitions (e.g. in the PPT or in the region's definition repository). The definition associates the TRANSID with the program that runs first when the transaction is invoked—the "initial program." It may also specify transaction attributes (e.g. priority, whether it can be run from a terminal or only by another program). Users and applications invoke a transaction by TRANSID; they do not need to know the program name. This indirection allows the installer to change the program for a transaction without changing the user-facing code.
A task is the runtime instance of a transaction. When a TRANSID is invoked, CICS creates a task. That task runs the initial program and remains the same logical unit of work until it ends (e.g. when the program returns to CICS or the task is abended or cancelled). The program can LINK to another program (the linked program runs in the same task and returns to the caller) or XCTL to another (control transfers, same task). So one task can run several programs in sequence. Multiple invocations of the same TRANSID result in multiple tasks, each with its own storage and context, so many users can run the same transaction at the same time.
The flow from "user invokes transaction" to "task ends" is: (1) The user or calling system provides the TRANSID (e.g. types it at a terminal or sends it via an API). (2) CICS looks up the TRANSID in its definitions and finds the initial program and transaction attributes. (3) CICS allocates a task and builds the necessary control blocks (task control block, program control, etc.). (4) The initial program is loaded (if not already in memory) and given control. (5) The program runs; it may read input, call other programs (LINK/XCTL), access files, and return output. (6) When the program returns to CICS (or the task is terminated), the task ends and resources are released. The user may then invoke another transaction.
| Step | What happens |
|---|---|
| User or system invokes TRANSID | TRANSID entered at terminal or sent via API |
| CICS looks up TRANSID | Finds initial program and transaction definition |
| Task created | New thread of control for this execution |
| Program runs | Initial program executes; may LINK/XCTL to others |
| Task ends | When program returns to CICS or task is terminated |
CICS is multitasking: it can run many tasks at the same time. Each task has its own thread of control. When a task waits—for terminal input, file I/O, or a response from another region—CICS can dispatch another task so the processor is used productively. The CICS task control program and dispatcher manage task switching and scheduling. Priorities can be set so that some transactions get preference. This concurrency allows many users to use the system simultaneously and allows one user's transaction to make progress while another is waiting. Resource locking and syncpoint (commit/rollback) ensure that concurrent tasks do not leave data in an inconsistent state.
The link between TRANSID and program is in the CICS definitions. The transaction definition specifies the initial program (and possibly other attributes). The program definition points to the load module or program object. When you install or define a new transaction, you give it a TRANSID and the name of the initial program. At runtime, CICS uses only these definitions; the application invokes by TRANSID and does not hardcode program names in the user flow. This supports deployment and change: you can point a TRANSID to a new program without changing the way users invoke the transaction.
1. A CICS transaction is identified by:
2. When you invoke a TRANSID, CICS creates a:
3. Multiple users running the same TRANSID at the same time result in: