The daily edition.

Scope: Rocket Enterprise Developer 12.0 for Eclipse on Linux/UNIX; Enterprise Server XA support.

When a resource-manager connection fails, two separate concerns arise: restoring connectivity and resolving any transaction left in the prepared state. Enterprise Server handles these through XA reconnect processing and XA recovery, respectively.

An in-doubt transaction can result from connection loss, process death, or resource-manager failure during phase two of a two-phase commit. At that point, one or more resource managers might have prepared the transaction but not completed the final commit or rollback. Enterprise Server records the outcomes of XA syncpoint operations in its XA log, then uses that information to decide how recovered branches must be completed. XA Recovery

The XA recovery system transaction is triggered in several documented situations:

• Enterprise Server region startup
• A service execution process (SEP) abend
• RMFAIL or RMERR returned during phase two of a syncpoint

The recovery transaction asks the resource manager for recoverable transactions, correlates them with the XA log, and issues the appropriate commit or rollback. Messages such as CASXO0029I report transactions found in the log at startup; a later CASXO0027I confirms successful recovery. XA logging is enabled by default for resource managers that expose xa_recover(). It is bypassed when that capability is absent. Although ES_XA_LOG_SUPPRESS=Y can disable logging where its performance cost matters, Rocket describes XA logging as the mechanism underpinning in-doubt recovery. XA Recovery

ES_XA_RECONNECT instead controls how Enterprise Server reacts to lost connectivity. With:

ES_XA_RECONNECT=Y,120,4

single-attempt mode is enabled. Before each transaction executes, Enterprise Server performs an XA ping. If it fails, Enterprise Server performs xa_close, xa_open, and another ping. Failure does not disable the resource manager; the sequence is repeated when subsequent transactions attempt to use it. Applications requiring that RM must decide how to handle the resulting error—for example, by abending or rolling back. Single mode reconnect for CICS

The second value controls the delay, in seconds, before XA recovery after a phase-two failure and between recovery reschedules; the maximum is 300 seconds. The third value controls retries when recovery commit or rollback returns RC 04; its default is five. After the retry limit, CASXO0055S reports that the in-doubt transaction requires manual commit. Without this variable, reconnect operates in multi-attempt mode. Single mode reconnect for CICS

Takeaway: A restored RM connection does not prove transaction consistency—confirm both reconnection and the subsequent CASXO0027I recovery outcome.