Commit process

During the synchronization point (sync point) processing for an application, IMS creates a log record to establish commitment of database changes and availability of output messages. The commit process is not complete until IMS physically writes this log record to the OLDS because an incomplete set of database change and message records exist on the log for system restart.

The commit processes work differently for full-function and Fast Path applications. For full-function, IMS makes database changes in the buffer pool at the time of a DL/I call, and can write the changes to disk before the commit point. If you restart the system, IMS backs out these uncommitted changes by using the log. IMS stores inserted message segments in the message queue and must similarly discard them.

For Fast Path, IMS keeps all changes in memory until it physically logs the commit record. Only then does IMS write database changes to DASD and send output messages. Because no changes appear on external storage (except for the log) until the commit record is written, IMS does not perform backout processing for the database. IMS discards the updates in memory. With Fast Path, system restart ensures that IMS writes committed updates to DASD and sends output messages.

Relationship between checkpoints and sync points

IMS tracks all checkpoints and sync points. IMS usually uses a sync point during recovery, but returns to the checkpoint in the following situations: In the following figure, for example, if a system-wide failure occurs in the DB/DC environment just after the MTO takes a system checkpoint but just before program B commits (assuming that program A has not made any updates since its last commit), IMS must return to the system checkpoint before Beta started.

For a full recovery in the DB/DC environment, IMS returns to the earliest of either the checkpoint before the current checkpoint or the checkpoint before the first uncommitted application program update.
For a full recovery in the DBCTL environment, IMS always returns to the checkpoint before the first uncommitted application program update.
For a full recovery in the DCCTL environment, IMS always returns to the checkpoint before the latest system checkpoint.
In the DB/DC or DCCTL environments, if a BUILDQ is requested on the restart, IMS returns to the last SNAPQ or DUMPQ checkpoint. IMS returns to this checkpoint even if it is older than the checkpoint normally needed for the restart.

This figure illustrates the time flow during a system-wide failure and the checkpoints taken.

Synchronization point processing in CPI Communications-driven programs

For CPI Communications-driven programs running under Advanced Program-to-Program Communications for IMS (APPC/IMS), the application programs control their own sync point processing. An application program can issue certain CPI Resource Recovery calls: SRRCMIT calls to commit data and SRRBACK calls to back out data. The protected resources managed by IMS (local) include:

IMS TM message-queue messages
IMS DB databases
Db2 for z/OS® databases

The highest level of synchronization supported for a conversation is SYNCPT, so CPI Communications-driven applications can have protected conversations.

Sync point and resource manager

IMS can be either the sync point manager or the resource manager, depending on the setting of the sync point level. For SYNCLVL=NONE or CONFIRM and AOS=B, S, or X, IMS is the sync point manager and the resource manager, but for RRS=Y and SYNCLVL=SYNCPT, z/OS Resource Recovery Services (RRS) is the sync point manager and IMS is the resource manager. For RRS=N, IMS is the sync point manager.