Sharing data in CICS applications

CICS® applications often need to keep data available beyond a single program call. For example, one program might collect input, another might validate that input, and a later transaction might need to continue processing after a user interaction. To support this, CICS provides several mechanisms for passing and sharing data.

When choosing a mechanism, it is important to understand how long your data needs to live and who needs access to it. In CICS, a transaction is started by a user or system event and runs as a task which can execute one or more programs. When the transaction completes, its task ends.

  • Some data is only needed while a transaction is running.
  • Some data must be passed to another program.
  • Some data must survive long enough for a later transaction to use it.

Most new or modern applications use channels and containers. Many of the other mechanisms exist mainly for compatibility with older applications or for specialized scenarios. However, it is important to note that in some environments, organizational or architectural policies might restrict which mechanisms you can use.

For more information about transactions and tasks, see Transactions in CICS.

Channels and containers

Channels and containers are the preferred mechanism for most modern CICS applications.

A channel is a named collection of containers, where each container holds a single piece of data. Channels provide a flexible way to pass multiple independent data items between programs, without the size and structural limitations of COMMAREAs.

Channels are typically used to pass data between programs within a transaction, and they can also be passed to a follow‑on transaction to preserve data across transaction boundaries.

Channels and containers are managed automatically by CICS and are associated with the lifetime of the task or transaction to which they are passed.

For more information, see Benefits of channels. Channels are described in Transferring data between programs using channels.

Communication areas (COMMAREAs)

A COMMAREA is a fixed‑length block of storage used to pass data between programs. Many existing applications use COMMAREAs and they are still supported.

COMMAREAs are often used in pseudo‑conversational applications. Pseudo-conversational applications are applications where each user interaction runs as a separate, independent transaction rather than keeping one long-running transaction active. In these flows, any data needed by the next transaction must be explicitly passed along.

Compared to channels and containers, COMMAREAs are less flexible:

  • the data structure must be predefined (you must know the exact layout and size in advance)
  • only one COMMAREA can be passed at a time
  • size limits apply

When working with existing applications, you might often encounter COMMAREAs. For new applications, channels are generally a better choice.

Temporary storage queues

Temporary storage queues provide a way for programs and transactions to share data by using a named queue that can be accessed by multiple tasks. Data written to a temporary storage queue can be read by the originating task or by any other task that knows the queue name.

Unlike transient data queues, they support flexible access patterns. Data items can be read in any order, read multiple times, and updated or rewritten as required. Items remain in the queue until they are explicitly deleted.

Temporary storage queues can also be defined as recoverable resources, allowing data to be restored after a failure when recoverability is required. They can be used when data must be shared between multiple transactions, preserved across transaction boundaries, or accessed as part of a multi‑step processing flow. They are also used for audit and logging scenarios where data needs to remain available until it is explicitly removed and can be shared between regions by using the temporary storage data sharing server.

Transient data queues

Transient data queues support sequential processing of data that is written by one program or transaction and read by another. Unlike temporary storage queues, transient data queues are designed for one‑way, ordered processing and can be configured with recovery options to protect data in case of system failures.

Data written to a transient data queue is read in sequence and removed as it is read. Items cannot be updated or rewritten, which makes transient data queues suitable for simple, linear processing flows. Writing to a transient data queue can also be configured to automatically start a transaction,allowing data arrival to trigger further processing.

Shared storage

CICS applications can use shared user storage to hold data that needs to be available to more than one transaction. This storage is obtained dynamically and can be accessed by other transactions if they are given the address of the storage.

Unlike most task‑related storage, shared user storage is not automatically released when a transaction ends. It remains available until the application explicitly frees it, making it suitable for data that must persist across transaction boundaries.

Because this storage is retained beyond a single task, applications are responsible for managing its lifetime carefully.

Transaction Work Area (TWA)

The Transaction Work Area (TWA) is a block of storage that is allocated for the lifetime of a single CICS transaction. It provides a simple way for programs that run as part of the same transaction to share data with each other.

Any program invoked within the transaction can read from and write to the TWA, which makes it useful for passing small amounts of state or context between programs without using external storage or COMMAREAs. The contents of the TWA are private to the transaction and are not visible to other transactions.

The TWA exists only while the transaction is running. When the transaction ends, the TWA and all the data stored in it are discarded automatically.

Program storage

When CICS runs a program, it allocates storage to hold that program’s working variables, such as counters, flags, and temporary data. This storage is known as program storage.

CICS creates a separate copy of program storage for each transaction that runs the program. This ensures that if multiple transactions execute the same program at the same time, each transaction has its own private set of variables and they do not interfere with each other.

Program storage exists only while the program is running and is local to that specific program invocation. It is not a CICS mechanism for passing data to other programs or for sharing data across transactions. When the program returns control to CICS, the storage is released automatically.

Common Work Area (CWA)

The Common Work Area (CWA) is a block of storage that is shared across the entire CICS region. Unlike program storage or the Transaction Work Area (TWA), the CWA is not associated with a specific program or transaction. Any transaction running in the region can access the CWA, subject to protection and security rules.

Because the CWA is shared by all transactions, its contents can be read or modified concurrently by multiple applications. Data stored in the CWA therefore persists beyond the life of a single transaction and remains available until it is explicitly changed or until the CICS region is restarted.

Terminal User Area (TCTUA)

The Terminal User Area (TCTUA) is associated with a specific terminal. It is intended for transactions that run serially at that terminal and should only be accessed by transactions that have the terminal as their principal facility. The principal facility is the terminal that a transaction is directly associated with, typically the terminal that initiated the transaction. The TCTUA is not a region‑wide mechanism and should not be used for general data sharing.

Choosing the right approach

When selecting a mechanism, consider how long the data must be stored, which programs or transactions need access to it, and whether the data must cross a transaction boundary. Your choice might also be constrained by company standards, existing application design, or platform configuration, so some options might not always be available. Also think about performance, recoverability, security, and any transaction affinities that the mechanism might introduce.

For most application designs, channels and containers provide the best balance of clarity, flexibility, and modern design practice.