Units of recovery

Data Replication for IMS maintains transactional consistency by applying each source transaction as a transaction to your target IMS databases.

A unit of recovery (UOR) is a group of operations that are either committed or backed out as a group. These operations represent a transaction, such as an online transaction, or similar changes that applications generate. You can configure the capture server to treat multiple transactions as a single transaction by specifying the UORGROUPCOUNT configuration parameter.

These programs are examples of applications that modify IMS databases:

Batch message processing (BMP) applications
The IMS Database Resource Adapter (DRA)
Open Database Access (ODBA) applications

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 this behavior is optional.

Data Replication products for VSAM use the following Unit of Recovery (UOR) Identifiers (Ids). A UOR Id defines a group of changes that are applied together. For recoverable data sources (for example recoverable VSAM under the control of a transaction manager like CICS TS or DFSMSTVS) this is usually a group of changes representing 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 in order to create a printable UOR Id. The maximum printed UOR Id is therefore 64-bytes, but some information in the UOR Id is already printable character data an effort is made to retain existing character values and avoid simply converting each byte to hex to maintain the readability of the UOR Id when that's 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 often for VSAM. All UOR Ids have a uniqueness STCK added after the first 24 bytes 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 might be 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 formats that are used and provides an example of the printable converted UOR Id.

1. Recoverable CICS TS workload:
----+----1----+----2----+----3--
ttttttttnnnnaaaaaaaa    ssssssss

Printed example:
0001144CDEMDCI57        DB2B6B1D05150B4A

2. Recoverable CICS TS ESDS inserts:
----+----1----+----2----+----3--
ttttttttnnnnaaaaaaaaESINssssssss

Printed example:
0001144CDEMDCI57    ESINDB2B6B1D05150B4A

3. Non-recoverable CICS TS workload w/o DSNLUORTIMEOUT:
----+----1----+----2----+----3--
ttttttttnnnnaaaaaaaaNRCVssssssss
The first non-recoverable change of the group sets the UOR Id values.  When subsequent non-recoverable changes occur with an in-flight non-recoverable UOR they are included in the existing group until the group is ended and then a new group begins with its first non-recoverable change.  The VSAM replication products determine when the grouping ends for non-recoverable data.

Printed example:
0000958CDEMECI57    NRCVDB27651D51F9972C

4. Non-recoverable CICS TS workload w/  DSNLUORTIMEOUT
----+----1----+----2----+----3--
rrrrrrrrDSNLCICS TS NRCVssssssss

Printed example:
00000088DSNLCICS TS NRCVDB2B88454B2E785A

5. CICS VR workloads
----+----1----+----2----+----3--
jjjjjjjjppppaaaaaaaaNRCVssssssss

Printed example:
@BTCTST1VSMK.RPNEW02NRCVDB2B6ED4B6BCEC2B

6. DFSMSTVS
----+----1----+----2----+----3--
uuuuuuuuuuuuaaaaaaaauuuussssssss

Printed example:
db2b77907ebb9f4000000540.GWTV00201020000db2b779098d16421

7. DFSMSTVS ESDS inserts
----+----1----+----2----+----3--
uuuuuuuuuuuuaaaaaaaauuuussssssss

Printed example:
db2b77907ec313d000000a02eGWTV00101010000db2b77908783f66a

8. Non-recoverable DFSMSRLS workload w/o DSNLUORTIMEOUT
----+----1----+----2----+----3--
jjjjjjjjppppDFSMSRLSNRCVssssssss
The first non-recoverable change of the group sets the UOR Id values.  When subsequent non-recoverable RLS changes occur with an in-flight non-recoverable UOR they are included in the existing group until the group is ended and then a new group begins with its first non-recoverable change.  The VSAM replication products determine when the grouping ends for non-recoverable data.

Printed example:
@RLSESD2RLSEDFSMSRLSNRCVDB27696F24A27A20

9. Non-recoverable DFSMSRLS workload w/  DSNLUORTIMEOUT
----+----1----+----2----+----3--
rrrrrrrrDSNLDFSMSRLSNRCVssssssss

Printed example:
0000010FDSNLDFSMSRLSNRCVDB2B73A4F98FC968

10. VSAM remote source - Refresh UORs
----+----1----+----2----+----3--
                      RFSHssssssss


Printed example:
                      RFSHDB2B211266C90000

11. ZUOR UORs are generated by VSAM file close and tieups.
Temporary, internal UORs that result in ZUOR format (below) UORs replicated to advance the bookmark.  This should only be visible in tracing.
----+----1----+----2----+----3--
                      ZUORssssssss

Printed example:
                      ZUORDB2B2159F3D60000

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

Printed example:
ZUORdb27641a86e58c2a

Legend:
a- Appl Id
   For CICS TS, region where the transaction occurred.
   For CICS VR, unique instance for an LPAR from D SMS,CICSVR,ALL report. The first byte may be unprintable and might be displayed as '.' to ensure a printable character
   For DFSMSTVS, unique instance for an LPAR (TVSNAME) from D SMS,TRANVSAM,ALL report.  The first byte of the TVSNAME is 0x05 in log records, but will be displayed as character '.' except for ESDS inserts that might display as character 'e' (EBCDIC 0x85) or à (ASCII 0x85) in the UOR Id.
j- jobname
n- CICS transaction ID
p- first four bytes of the step name
r- hex, unique, replication object ID (ROID) for the data set
s- uniqueness STCK
t- character conversion of packed decimal task number; last character converted is the sign nibble 'C'
u- RRS URID (hex) - split with first 12 bytes before the Appl Id and last 4 bytes after the Appl Id -- when displayed will be the hex values
x- Converted character display of the hex STCK used to advance the subscription bookmark