CICS Data Management

CICS data management is the set of facilities that CICS applications use to store and retrieve data. The main options are: file control (for VSAM and other files), temporary storage (TSQ), transient data (TDQ), and—when configured—DB2 or other databases. Each has different persistence, sharing semantics, and access patterns. Choosing the right one depends on whether data must be permanent or temporary, shared across tasks or private, and read once or many times. This page gives an overview of these options and when to use them.

Explain Like I'm Five: What Is Data Management in CICS?

Imagine CICS as an office. Data management is all the places the office can put information: filing cabinets (files) for things that must stay forever and be looked up by name or number; sticky notes and whiteboards (temporary storage) for things you are working on right now or want to pass to the next step; and out-trays (transient data) for things you send away in order—once someone takes from the tray, that item is gone. There might also be a big database (DB2) the office shares with other departments. CICS data management is the set of rules and commands for using each of these so your program can read, write, and manage data correctly.

Why Data Management Matters

Every transaction that does real work needs to read or write data: customer records, orders, session state, or messages to other systems. CICS does not let programs access datasets or memory arbitrarily; they must use the supported interfaces. File Control gives structured, persistent access to files (usually VSAM). Temporary storage gives named queues that can be in memory or on a backing file, with flexible read/write and sharing. Transient data gives sequential queues that can be read-destructive (intrapartition) or sent to an external destination (extrapartition). DB2 gives SQL and relational semantics. Using the wrong facility can lead to wrong persistence (e.g. using TS when you need a file), wrong sharing (e.g. task-private when you need shared), or wrong lifecycle (e.g. TD when you need to read the same item multiple times). Understanding data management helps you pick the right tool and use it correctly.

Data Resources at a Glance

File Control

File Control is the CICS component that manages access to files. Typically these are VSAM data sets (KSDS, ESDS, RRDS) or BDAM files. Each file is defined in the File Control Table (FCT) with a logical name, the physical dataset name, file type, and allowed operations (read, update, add, browse, delete). Programs use EXEC CICS READ, WRITE, REWRITE, and DELETE with the logical file name. For updates, you must READ with UPDATE so CICS locks the record before you REWRITE or DELETE. File Control handles translation from logical name to dataset, locking, and (with CICS recovery) participation in syncpoint. For full details on READ, WRITE, REWRITE, DELETE, and the FCT, see CICS File Management.

Temporary Storage (TSQ)

Temporary storage provides named queues (TSQs) that can hold data during or across transactions. There are two types: main and auxiliary. Main temporary storage holds the queue data in CICS region memory; it is fast but limited in size and is lost on region failure unless the region is set up for recoverable main TS. Auxiliary temporary storage holds the queue data in a backing file (typically the VSAM data set DFHTEMP). Auxiliary TS can hold more data and can be recoverable across restarts, but each read or write involves I/O. You write with WRITEQ TS and read with READQ TS; you specify the queue name and (for READQ) the item number. Queues can be task-private (only the creating task can access them) or shared (other tasks can access by name). TS is often used for work-in-progress that must be passed from one program to the next in a transaction or from one transaction to another (e.g. session data). Use main TS for small, short-lived data; use auxiliary when data is large or must survive region restart.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
* Write to temporary storage queue
EXEC CICS WRITEQ TS
    QUEUE('MYQUEUE')
    FROM(WS-DATA)
    LENGTH(WS-LEN)
    ITEM(WS-ITEM)
    RESP(WS-RESP)
END-EXEC.
* Read back (e.g. in a later program)
EXEC CICS READQ TS
    QUEUE('MYQUEUE')
    INTO(WS-DATA)
    LENGTH(WS-LEN)
    ITEM(WS-ITEM)
    RESP(WS-RESP)
END-EXEC.

Transient Data (TDQ)

Transient data queues are defined in the Destination Control Table (DCT). There are two kinds: intrapartition and extrapartition. Intrapartition TDQs are used within the CICS region. Data is written with WRITEQ TD and read with READQ TD. Reading is destructive: once a record is read, it is removed from the queue and cannot be read again. Records are processed in FIFO order. Intrapartition TDQs are often used to trigger another transaction: you define a trigger level (TRIGLEV) in the DCT; when the number of records in the queue reaches that level, CICS automatically starts a specified transaction to process the queue. Extrapartition TDQs send data to an external destination: a sequential dataset, another CICS region, or a printer. Data written with WRITEQ TD goes to the destination (e.g. a batch input stream or a print file); CICS does not read it back. So intrapartition TD is for in-region, read-destructive, sequential queues; extrapartition TD is for one-way output to an external system.

Temporary Storage vs Transient Data

DB2 and Other Databases

CICS can connect to DB2 so that CICS application programs run SQL (embedded or dynamic). The CICS-DB2 attachment coordinates the connection and allows CICS and DB2 to participate in the same unit of work. When the CICS task issues a syncpoint (e.g. normal task end or EXEC CICS SYNCPOINT), both CICS resource updates (e.g. file updates, TS) and DB2 commits are coordinated: either all commit or all roll back. This is important for consistency when a transaction updates both a VSAM file and a DB2 table. DB2 is suited to structured, relational data and complex queries; file control is often used for high-volume, keyed record access. Sites may also use other database or resource managers with CICS via similar attachment and syncpoint coordination.

Step-by-Step: Choosing the Right Data Resource

1. Decide if data must be permanent (survive region restart and be shared by many transactions) or temporary. Permanent, shared record access usually implies file control or DB2.
2. If temporary, decide if it is only for one task (work-in-progress) or must be shared or passed to another task/transaction. Task-private scratch data can use main TS; shared or cross-transaction data may use shared TS or intrapartition TD.
3. If the flow is one-way and sequential (e.g. send to batch or printer), consider extrapartition TD. If you need to trigger a transaction when a queue reaches a level, use intrapartition TD with TRIGLEV.
4. If data is large or must survive region restart, use auxiliary TS or files rather than main TS.
5. Define the resource (FCT for files, DCT for TD, TS system definitions for TS) and ensure the program has the right permissions and that recovery/syncpoint behavior matches your requirements.

Recovery and Syncpoint

CICS supports syncpoint (commit/rollback) for file updates, temporary storage (when recoverable), and DB2. When a task ends normally or issues EXEC CICS SYNCPOINT, CICS commits all recoverable changes made by that task. If the task abends or issues SYNCPOINT ROLLBACK, changes are rolled back. So data management in CICS is not only about where data lives but also about whether it participates in the unit of work. Non-recoverable resources (e.g. some TS or TD configurations) do not roll back on failure. Design your transaction so that persistent, critical updates use recoverable resources and participate in syncpoint.

Best Practices

• Use file control for master and transactional data that must be persistent and shared; use TS for temporary, session-like, or pass-between-program data.
• Prefer main TS for small, short-lived data to avoid auxiliary TS I/O; use auxiliary TS when size or recoverability requires it.
• Use intrapartition TD when you need read-destructive, sequential consumption or trigger-based processing; use extrapartition TD for output to batch or printers.
• Always check response codes after READ, WRITEQ, READQ, and file operations; handle NOTFND, errors, and full queue conditions.
• Coordinate with CICS recovery: use READ UPDATE before REWRITE/DELETE, and ensure recoverable resources participate in syncpoint when consistency is required.

Test Your Knowledge