The daily edition.

Scope

This lesson covers multiple XA resources in Rocket Enterprise Developer / Enterprise Server 12.0 for Linux/UNIX.

Enterprise Server supports multiple XA resource definitions in one region, but “multiple” does not always mean extra application work. If each resource uses a different resource-manager switch-module type, the region can use one XAR of each type without recompiling the application or adding special XAR configuration. The distinction becomes important when two or more XARs use the same switch-module type. Working with Multiple XARs

For same-type XARs used by CICS or Web Services SQL modules, Rocket documents two essential steps:

1. Give every XAR a unique resource-manager ID.
2. Compile each SQL program module with the XAID directive set to the ID of the XAR that module must use.

This binds SQL activity to the intended resource definition. If one source module must use multiple XARs, Rocket’s preferred design is to split it into separate modules and compile each with its corresponding XAID. Provider-specific alternatives exist—such as SET CONNECTION or an AT clause—but the identifiers must align with the applicable connection name, database name, or XAR ID. Working with Multiple XARs

Connection scope is another design decision. By default, every CICS, IMS MPP, or IMTK container-managed SEP establishes a connection to each enabled XAR in the region. A resource needed only by JCL can instead include:

BatchOnly=T

That makes it available only to batch jobs and their corresponding SEPs, avoiding the cost of opening it in transactional SEPs. Rocket’s documented example for three same-type resources uses one ordinary definition for CICS and marks the two batch-only definitions this way. Planning and Designing XARs SQL xa_open string Configuration Options

Switch registration further affects overhead. Static registration enrolls the resource manager in every transaction, even when unused. Dynamic registration waits until the first SQL call, and Rocket generally prefers it when multiple XARs exist. Oracle and DB2 dynamic-registration cases can still require XAID, particularly with embedded SQL options or user impersonation. RM Switch Module Registration

Finally, do not use LocalTX=T merely as a performance shortcut in a multi-resource unit of work. It makes that XAR commit and roll back independently of other resources; Rocket specifically cautions against it for jobs combining VSAM and SQL. The default LocalTX=F uses distributed global transactions. SQL xa_open string Configuration Options

Takeaway: Treat each same-type XAR as an explicitly addressed endpoint—bind code with XAID, isolate batch-only resources, and preserve global transaction coordination when resources must commit together.