CICS Multitasking and Multithreading: Tasks, QR TCB, and Threadsafe Programs

A CICS region may receive terminal input from hundreds of users while the same order-entry program is already loaded in storage. CICS does not normally load a private copy of the program for every user. It starts tasks, dispatches them, and lets those tasks share program code safely when the program follows CICS rules.

One program, many tasks.

What is a CICS task?

A CICS task is one execution of a transaction for one request. If five users run transaction ORDR, CICS can create five separate tasks. Each task has its own control information and its own path through the application, even when all five tasks use the same program.

This is different from saying that five copies of the program are loaded. CICS can keep one copy of the executable program and dispatch several tasks through it at different times.

What is CICS multitasking?

CICS multitasking means that more than one task can be active in the region. One task may be waiting for a VSAM read, another may be waiting for terminal input, and a third may be ready to run. The CICS dispatcher decides which task gets control.

From the user's side, several transactions appear to run at once. Inside the region, CICS gives control to work that is ready and takes control back when a task waits for CICS or system service.

What is CICS multithreading?

CICS multithreading means that several tasks can use the same copy of an application program. Task A can enter program ORDRPGM, issue an EXEC CICS READ, and wait. While Task A is waiting, Task B can enter the same loaded program copy.

That is why CICS programs must not keep user-specific state in a place that can be damaged by another task. The application must be safe when control leaves the program at an EXEC CICS command and later returns.

Multitasking vs multithreading

Term	Meaning in CICS	Example
Task	One execution of a transaction request	User 1 runs ORDR to add an order
Multitasking	Many tasks are active in the region	ORDR, PAYM, and INQY tasks are all active
Multithreading	Many tasks can pass through one loaded program copy	Several users run the same ORDRPGM program
Threadsafe	The program can run safely when CICS allows concurrent execution on open TCBs	A program protects shared storage before update

Why quasi-reentrant programs matter

IBM describes CICS application programs as needing quasi-reentrant behavior. In plain terms, the program must be in a clean, consistent state when it gets control and whenever it gives control back to CICS, such as at an EXEC CICS command.

For COBOL programs, CICS gets a separate copy of working storage for each task invocation. That protects normal WORKING-STORAGE data from being shared accidentally across users. The program code itself still has to behave correctly when several tasks use the same loaded program.

QR TCB and open TCB in simple terms

A TCB is a dispatchable unit of work in z/OS. Older CICS application work often ran under the quasi-reentrant TCB, usually called the QR TCB. The QR TCB serializes quasi-reentrant application code so only one such program is running on that TCB at a time.

Modern CICS can also run eligible work on open TCBs. This matters for programs defined as THREADSAFE or REQUIRED and for workloads that use resource managers such as Db2, IBM MQ, or JVM servers. A wrong THREADSAFE definition can expose bad shared-storage code that looked harmless under QR serialization.

PROGRAM CONCURRENCY settings

The CICS PROGRAM resource definition includes a CONCURRENCY attribute. This is not a decoration field. It tells CICS what the program promises about shared-resource safety.

Setting	Meaning	Support note
QUASIRENT	The program follows quasi-reentrant rules.	CICS keeps it on the QR TCB for application execution.
THREADSAFE	The program is written to protect shared resources.	CICS may let it continue on an open TCB after some resource-manager work.
REQUIRED	The program must run on an open TCB.	Use only when the program meets the required API and threadsafe rules.

Where shared data causes trouble

Most CICS multitasking bugs show up when programs update shared resources without control. Examples include the common work area, shared TS queues used like global scratchpads, user exits, assembler static storage, and non-CICS APIs used from OPENAPI programs.

EXEC CICS ENQ RESOURCE('ORDR-CONTROL') END-EXEC

   *> Update shared control information here.

EXEC CICS DEQ RESOURCE('ORDR-CONTROL') END-EXEC

The exact protection method depends on the resource and site standards. The point is simple: if two tasks can update the same value, the program must control that update.

Common mistakes

Calling every CICS program threadsafe

THREADSAFE is a claim about the application logic. Do not set it just to chase performance. Review shared storage, non-CICS calls, exits, and resource-manager behavior first.

Confusing task with transaction name

A transaction code such as ORDR is a definition. A task is one running instance of that transaction request. Many tasks can use the same transaction code.

Assuming working storage is shared by every user

For normal CICS COBOL programs, each task invocation gets its own working-storage copy. Shared-data problems more often come from global storage, external resources, exits, or static storage outside normal COBOL working storage.

Review checklist for CICS programs

• Confirm the transaction code and program name involved in the incident.
• Check the PROGRAM definition for CONCURRENCY and API.
• Identify whether the program runs under QR TCB, open TCB, or switches between them.
• List every shared resource updated by the program.
• Check whether shared updates are protected by site-approved locking or serialization.
• Review long CPU loops between EXEC CICS calls because they can hold the QR TCB too long.
• Test with more than one user task, not only with a single terminal session.

Related Mainframe Forum guides

For connected CICS topics, read How CICS Transactions Work, Conversational vs Pseudo-Conversational Programming, CICS Commands Quick Reference, CICS Transactions, CICS Interview Questions, and COBOL RENT Compiler Option.

External references

IBM documents these topics in multithreading, reentrant, quasi-reentrant, and threadsafe programs, PROGRAM resource definitions, quasi-reentrant application programs, and how a CICS transaction flows.

FAQ

What is the difference between CICS multitasking and multithreading?

Multitasking means many CICS tasks are active in the region. Multithreading means many tasks can use the same loaded application program copy.

What is a CICS task?

A CICS task is one execution of a transaction request. If ten users run the same transaction, CICS can create ten tasks.

Does every CICS COBOL task share the same working storage?

No. For normal CICS COBOL programs, each task invocation gets its own working-storage copy. Shared data must still be handled carefully when it lives outside that private copy.

What does THREADSAFE mean in CICS?

THREADSAFE means the application logic is written to protect shared resources when CICS allows the program to run on open TCBs.