Understanding IMS units of recovery

The Classic data server sends only committed work to the target engine. If commit control is in effect at the target database, the target engine applies all changes within a transaction as a unit.

A unit of recovery (UOR) represents an IMS transaction, such as an online transaction, or changes that applications generate. Examples of applications that modify IMS databases include:

Typically, a BMP application generates multiple UORs, one for each checkpoint that the application issues. Ideally, a DL/I batch application also issues checkpoints and generates multiple UORs, but it is not a requirement.

Data Replication products for IMS use the following Unit of Recovery (UOR) Identifiers (Ids). A UOR Id defines a group of changes that are applied together. For IMS this is usually a group of changes that represent a source commit scope.

The UOR Id is always 32 bytes. The internal format might include binary values to create a unique UOR Id. When necessary, the replication products convert binary data to hex to create a printable UOR Id. Therefore, the maximum printed UOR Id is 64 bytes since some information in the UOR Id is already printable character data an effort is made to retain existing character values. Avoid converting each byte to hex to maintain the readability of the UOR Id when that is possible.

Each UOR Id contains information that is related to its source in the first 24 bytes. Some UOR Ids might re-use this information creating multiple UORs with the same information in the first 24 bytes. This occurs rarely for IMS, but it is possible if restarts occur soon. All UOR Ids have a uniqueness STCK added after the first 24 bytes. This is to create unique groups and this ensures when the data in the first 24 bytes is repeated the groups are still unique. Any UOR that was already unique in the first 24 bytes still gets a uniqueness STCK added. The uniqueness STCK value is taken from the first log record that causes tracking of the UOR Id. The log record time that is used is adjusted by the log reader to ensure uniqueness. Note: ZUORs are an exception to the uniqueness STCK statements since these are already uniquely generated empty groups to impact the subscription bookmark.

The following summarizes the format that is used and provides an example of the printable converted UOR Id.

1. IMS UORs
----+----1----+----2----+----3--
ccccccccddddddddiiiiiiiissssssss

Printed example:
000005e4000000e7IM1A db2b7f1ac8f0945c

2. ZUOR UORs to advance restart during inactivity
----+----1----+----2----+----3--
ZUORxxxxxxxxxxxxxxxx

Printed example:
ZUORdb27641a86e58c2a

Legend:
c- 8 position binary commit number as hex character
d- 8 position binary schedule number as hex character
i- IMS Id (subsystem or DL/I batch job name)
s- uniqueness STCK
x- Converted character display of the hex STCK used to advance the subscription bookmark