The WebSphere MQ File Transfer Edition (WMQFTE / WMQ FTE) Database (DB) Logger fails with the following message shortly after starting; indicating that there was a problem at the coordination queue manager (QMgr):
BFGDB0018E: An MQ problem occurred while the database logger was beginning a new transaction. The reported reason code was MQRC_UNEXPECTED_ERROR and the reported message text (if any) was:
MQJE001: Completion Code '2', Reason '2195'. You should examine the MQ error log (for example, /var/mqm/qmgrs/COORD_QM/errors/AMQERR01.LOG ) for further information about the problem.
The coordination QMgr's error log points to an XA error indicating that the DB2 resource manager is not available during the xa_open call. XAER_RMERR is returned by the failed xa_open call.
AMQ7627: The XA resource manager 'DB2DB' was not available when called for xa_open. The queue manager is continuing without this resource manager.
EXPLANATION: The XA resource manager 'DB2DB' has indicated that it is not available, by returning XAER_RMERR on an xa_open request. Normally this indicates that the resource manager has been shut down. In this case the resource manager cannot participate in any new transactions. Any in-flight
transactions in which it was involved will be backed out, and any transactions in which it is in-doubt will only be resolved when contact with the resource manager is re-established. A further message will be
issued when the queue manager has been able to do this. If the resource manager should be available, then there may be a configuration problem or another possibility is that you are using a 32-bit instance of DB2, this is not supported on this platform, as WebSphere MQ processes are 64-bit and DB2 does not support 64-bit processes with its 32-bit instances.
ACTION: Try to establish the reason why the resource manager is unavailable. It may be that an invalid XAOpenString has been defined for the resource manager in the 'qm.ini' configuration file. If this is the case, stop and then restart the queue manager so that any change will be picked up. Alternatively, the queue manager may be reaching a resource constraint with this resource manager. For example, the resource manager may not be able to accommodate all of the queue manager processes being connected at one time, you may need to alter one of its tuning parameters.
The jdbcdb2 trace, collected using the XAJTA_TRACEFILE environment variable, shows that the XA_Open returns with -3. A DB2 formatted trace shows that the xa_open failure was preceded by an authentication failure:
7078 | sqlxaConnect exit [rc = 0x80370125 = -2143878875 = SQLJR_AUTHENTICATION_FAILED]
The .fmtc trace file shows that the password used in the XAOpenString was invalid:
NM: SECCHKRM - Security Check
LL: 15 CP: 1219
NM: SVRCOD - Severity Code
LL: 6 CP: 1149
Error Severity Code (0X0008)
NM: SECCHKCD - Security Check Code
LL: 5 CP: 11A4
Password Invalid (0X0F)
The password is invalid, because it is missing a '#' character at the very end. The '#' (hash mark) is being treated as the start of a comment on the XAOpenString line in the qm.ini file.
Diagnosing the problem
Verify that the password passed in the XAOpenString in the qm.ini file for the coordination QMgr is correct. If needed, collect DB2 trace to properly diagnose using the instructions linked below:
Resolving the problem
Configure the XAOpenString in the coordination QMgr's qm.ini to reflect the correct password token. If the password includes a hash mark ( '#' ), please escape it with a back slash ( '\'). For example:
XAOpenString=db=FTELOGDB, uid=fteadmin, pwd=adminpasswd\#, toc=p, tpm=mq
WebSphere MQ File Transfer Edition WMQFTE WMQ FTE