Unit of work identifiers

Unit of work IDs are persistent tokens used to identify a transaction. They are persistent because they are hardened by resource managers and transaction managers during syncpoint processing. Because they are persistent, they can be used to identify a particular transaction, part of a transaction, or both during normal processing and during restart processing.

Note: Resource managers sometimes use work IDs for other purposes. For example, XIDs are sometimes used as "lock tokens" by data managers. A lock token identifies the owner of a database lock; therefore, any program executing with a given lock token can access data controlled by the token.

RRS supports the following work IDs:

Unit of recovery identifier (URID)
Logical unit of work identifier (LUWID)
Enterprise identifier (EID)
X/Open identifier (XID)

A URID is a local identifier specific to RRS. It is RRS-specific because it is not defined by any standards body and is only used by RRS and the resource managers that work directly with RRS.

A URID is a local identifier because a URID is associated with a single unit of recovery. A distributed or cascaded transaction with many separate nodes and many URs will have many different URIDs. LUWIDs, EIDs, and XIDs are all global identifiers or a combination of a global identifier and a nonglobal identifier.

A LUWID is defined by the SAA LU 6.2 syncpoint architecture to identify a distributed transaction using the LU 6.2 protocols. It is a global identifier: all of the nodes in a distributed transaction that are part of a nondisjoint LU 6.2 transaction subtree have the same LUWID.

An EID is both a local and a global identifier. The first 4–bytes of an EID are the transaction identifier (TID). The TID is a local identifier: each node in a distributed transaction can have a different TID. The remaining 8–40 bytes of the EID are the global transaction identifier (GTID). The GTID is a global identifier: all of the nodes in a nondisjoint distributed transaction subtree managed by a communication resource manager using EIDs have the same GTID.

An XID is defined by the X/Open XA standard. In addition to the length and FormatID fields, an XID has two important parts: the global transaction identifier (GTRID) and the branch qualifier (BQUAL). The GTRID is a global identifier. All of the nodes in a nondisjoint distributed transaction managed by an X/Open compliant communications manager will have the same GTRID. The BQUAL, however, is not a simple local identifier. Communications resource managers use the BQUAL to denote tightly-coupled and loosely-coupled transaction nodes. Table 1 shows the differences between tightly-coupled and loosely-coupled transaction nodes.

Table 1. Differences Between Tightly-Coupled and Loosely-Coupled Transaction Nodes
Tightly-coupled transaction nodes	Loosely-coupled transaction nodes
Have exactly the same XIDs, including the BQUAL Normally share database locks A communications resource manager may send a single set of two-phase commit flows to the entire set of tightly-coupled nodes. Note: When RRS manages tightly-coupled nodes, it does not do this.	Have XIDs with different BQUALs Do not normally share database locks A communications resource manager sends separate two-phase commit flows to each node.

Nodes in a distributed transaction connected by a communication resource manager that does not use XIDs are normally loosely-coupled, as are cascaded transactions created by RRS. There are, however, exceptions. For example, APPC/MVS will set the same XID in each UR it creates, but send separate two-phase commit flows to each node, under the following conditions:

APPC is asked to allocate multiple protected conversations between the same two LUs (source and target), and
The LUs are part of the same distributed transaction (they are using the same LUWID), and
The target LU is an alternate scheduler, which causes APPC to create a work context and a UR for the alternate scheduler.

When RRS creates a cascaded transaction, each UR in the cascaded UR family will have an XID. Each UR's XID will have the same FORMATID and GTRID, but by default each will have a different BQUAL. When creating a cascaded UR via a call to the Express_UR_Interest service, a work manager can override this default behavior and directly control the BQUAL that RRS will use for the UR by specifying an XID on the call.

RRS automatically creates a URID whenever it creates a UR. RRS assigns an XID to a UR whenever the UR becomes part of a cascaded UR family. Otherwise, RRS assigns LUWIDs, EIDs, and XIDs to URs as indicated on either the Set_Work_Identifier service or the Retrieve_Work_Identifier service.

Table 2 lists each identifier, its format, whether RRS can generate it, and how RRS propagates the identifier when creating a cascaded UR.

Table 2. Unit of Work Identifiers
Unit of work identifier (UWID)	Format	Generate via Retrieve_Work_ Identifier service	Propagated to a cascaded UR
LU 6.2 logical unit of work identifier (LUWID)	`netid.luname.instnum.seqnum` netid.luname 1-17 character identifier of the network and LU, preceded by a 1-byte fixed length field instnum 6-byte fixed TP instance seqnum 2-byte fixed sequence number	Allowed.	Not propagated.
Enterprise Identifier (EID)	`tidgtid` tid 4-byte transaction identifier (TID) gtid 8-40 byte global transaction identifier (GTID)	Not allowed.	Not propagated.
X/Open Identifier (XID)	`FormatIDGtrid_lengthBqual_lengthID` FormatID 4-byte fixed format ID Gtrid_length 4-byte fixed GTRID length Bqual_length 4-byte fixed BQUAL length ID 128-byte character XID The GTRID length and BQUAL length define the length of the first and second subsection of the ID. The GTRID must have a length of at least 1 byte, however the BQUAL can have a length of 0. The length of the entire XID cannot exceed 140 bytes.	Required. RRS automatically generates an XID whenever any request for an XID is made against a UR that does not already have one.	The format ID is propagated. GTRID and GTRID length are propagated. BQUAL and BQUAL length are not propagated. BQUAL will be different from all other BQUALs with the same FORMATID and GTRID. This behavior may be overridden by specifying an XID when creating a cascaded UR with the Express_UR_Interest service.