The daily edition.

XA Reconnect Modes: Retry Per Transaction or Disable the Resource Manager

Scope: Rocket Enterprise Developer / Enterprise Server 12.0 for Eclipse on UNIX, CICS-compatible regions using XA resource managers. No other release or platform is blended in.

Enterprise Server no longer relies on the former CRCN CICS transaction for XA reconnection. Reconnect code now runs in a Service Execution Process (SEP): before each new transaction, it performs an xa-ping; if the ping fails, it attempts reconnection through the XA APIs. The mechanism applies to every XA entry that was enabled when the region started. To prevent attempts for an entry, remove it from the region definition or disable it before startup. See Enterprise Server XA Reconnect.

The important choice is what happens after a failed ping.

Single-attempt mode

Configure the global variable as:

ES_XA_RECONNECT=Y,wait-time[,retry_count]

For each transaction about to run, Enterprise Server tries xa-ping; on failure it performs xa-close, xa-open, then another xa-ping. If that sequence still fails, it writes an error to the console but does not disable the resource manager. The same processing occurs before each later transaction until connectivity returns. If the transaction needs the unavailable manager, the application decides whether to ABEND, roll back, or report the error.

The two numeric fields govern XA recovery after a two-phase-commit failure, not the per-transaction connection loop. wait-time is the delay before recovery and between reschedules when phase 2 returns RC 04, with a maximum of 300 seconds. retry_count is the number of recovery commit/rollback retries after RC 04; its default is 5. Rocket’s documented example is ES_XA_RECONNECT=Y,120,4. See Single mode reconnect for CICS.

Multi-attempt mode

To give a particular manager repeated reconnect attempts, set a second variable alongside ES_XA_RECONNECT=Y:

ES_XA_%xaname%_OPTIONS={reconnect_attempts,wait-time|EX}

%xaname% is the manager name defined in MFDS or ESCWA. Enterprise Server loops through xa-close, xa-open, and xa-ping, waiting the specified seconds between attempts. If all attempts fail, it disables the manager and issues a severe console error. Dynamic XA is then required to re-enable it during the region’s lifetime. The documented example ES_XA_MQPROD_OPTIONS=100,10 gives MQPROD 100 attempts with 10 seconds between them; EX excludes that manager from reconnect processing. Each manager needing multi-attempt behavior requires its own variable. See Multiple mode reconnect for CICS.

Takeaway: Choose single mode when a failed XA manager should remain enabled for transaction-boundary retries; choose per-manager multi-attempt mode when exhausting a bounded reconnect loop should disable that manager and require Dynamic XA re-enablement.