Data integrity in CICS means that recoverable resources (files, queues, and other protected resources) are never left in an inconsistent state. CICS achieves this by treating updates as a unit of work (UOW) bounded by SYNCPOINT: either all changes in the unit are committed together, or they are all backed out. Logging and journaling record changes so that when a task fails or the region restarts, the recovery manager can undo in-flight work or reapply changes to restored resources. This page explains how syncpoint, the unit of work, and logging work together to protect data integrity.
Imagine you are moving toys from one box to another. You want either both boxes to end up correct (all toys moved) or neither to change (nothing moved). You do not want one box updated and the other not—that would be inconsistent. CICS does the same with data: it groups a set of changes into one "unit of work." When you say "done" (SYNCPOINT), all those changes become permanent. If something goes wrong before you say "done," CICS puts everything back the way it was. It keeps a diary (the log) so it knows what to undo. That way the data is always in a consistent state.
In online transaction processing, a single business operation often touches multiple resources: for example, debiting one account and crediting another, or updating a master file and a history file. If the program fails after updating the first resource but before updating the second, the system would be inconsistent. CICS prevents this by making the whole set of changes atomic: either all of them are committed (SYNCPOINT) or all are rolled back (backout). The application designer defines the unit of work by where they place SYNCPOINT and SYNCPOINT ROLLBACK.
| Mechanism | What it does | Purpose |
|---|---|---|
| Unit of work | All changes between syncpoints commit or back out together | No partial updates |
| SYNCPOINT | Commit the current UOW; updates become durable | Define commit boundary |
| SYNCPOINT ROLLBACK | Back out the current UOW | Cancel the unit of work |
| System log | Records recoverable updates for backout and restart | Enable recovery |
| Forward recovery log | Records changes for reapplying to restored resources | Restore after media failure |
A unit of work is the set of all recoverable changes made by a task between two syncpoints (or between task start and the first syncpoint). CICS treats this set as one atomic operation: either the entire UOW commits at SYNCPOINT or the entire UOW is backed out on failure or rollback. So the application must design so that each UOW represents one logical business transaction. If you issue SYNCPOINT after every single update, each update is its own UOW—safe but potentially poor performance and more vulnerable to partial visible state. If you issue SYNCPOINT only at the very end, one failure backs out everything—simpler but a larger rollback. The right balance depends on the application.
EXEC CICS SYNCPOINT commits the current unit of work. All recoverable updates since the last syncpoint (or since task start) become durable. After SYNCPOINT, a subsequent failure will not undo those updates. EXEC CICS SYNCPOINT ROLLBACK (or equivalent) explicitly backs out the current UOW. The application uses ROLLBACK when it detects an error and decides to cancel the operation. After ROLLBACK or backout, the task can continue and start a new unit of work with new updates.
CICS uses the system log (and, where configured, journal streams) to record recoverable resource updates. The log is used in two main ways. First, when a task fails or issues ROLLBACK, the recovery manager reads the log and reverses each update in that task's UOW (dynamic transaction backout). Second, when the region restarts (warm or emergency), the recovery manager uses the log to identify units of work that were in progress and backs them out so that only committed work remains. For resources that support forward recovery, a separate forward recovery log records changes so that after restoring a resource from backup, you can reapply the log to bring it to a consistent point. Protecting and backing up these logs is essential for data integrity.
When more than one CICS region (or system) participates in a single business transaction, consistency across systems is maintained by distributed syncpoint. With synchronization level 2 (SYNCPOINT), the two-phase commit protocol ensures that all participants either commit or roll back together. The coordinator asks each participant to prepare; if all agree, the coordinator tells everyone to commit. If any participant cannot prepare or the coordinator fails, everyone rolls back. So even across regions, the logical unit of work is atomic and data integrity is preserved.
1. When should an application issue SYNCPOINT?
2. What happens to uncommitted updates when a CICS task abends?
3. What is the main purpose of the CICS system log for data integrity?