The scenario:

Recently problems were experienced with XA modules. Errors like these had been seen in the console log:

130701 17563461 11696 CICSPR08 CASXO0029I XA log reported in-doubt transaction 19 branch 1 17:56:34

(These errors result from xa switch modules that do not support automated XA recovery
or are operating in one phase commit mode. Originally, those switch modules returned a 0 return-code back to
ES. However, once ES had implemented the ability to recover in-doubt XA transactions, the 0 return-code implied that there were in fact transactions to process. The system in that case creates indoubt transaction
entries in the xa log files for each transaction executed in the system).

The fix in this particular case was replacing the XA modules with ones that support automated XA recovery. However, the messages are seen to persist afterwards. When the region was brought up with the new modules in place, the in-doubt messages are still there.

How can these be cleared?

The resolution:

There are log files with the "tscLognnnn-nnn.log" format that are created on disk and that exist in the region’s system directory. These are the XA recovery logs that were added to facilitate recovery from failures that leave resource managers such as DB2 and MQ with in-doubt transactions. The ones that were created when the issue was encountered may still be present. ES will attempt to load them on region startup, even when the new switch modules are in place.

If the region is stopped and these logfiles are deleted, the next region start-up should be clean. You should not see the "in-doubt" messages any longer.

If the messages persist after this, it could be that the old version of the XA modules are still being pointed to.

The messages can also be suppressed through the use in the region under Properties -> Configuration Information of

ES_XA_LOG_SUPPRESS=Y

This turns off the XA recovery logging.

(The ES_XA_LOG_SUPPRESS environment variable is new in ED v2.1.1).