Reputation: 1891
Some legacy code is running on a mainframe that uses JMS classes to connect to MQ.
The older version uses Java 8, Java EE with Spring 5 and IBM-provided JARs: com.ibm.mq.jar, com.ibm.mq.jmqi.jar, com.ibm.mqjms.jar.
After we switched to Java 17, Jakarta EE and Spring 6 the code started failing with the error:
Caused by: com.ibm.msg.client.jakarta.jms.DetailedJMSSecurityException: JMSWMQ2008: Failed to open MQ queue 'XXXXXXXX.YYYYYYYY'.
at com.ibm.msg.client.jakarta.wmq.common.internal.Reason.reasonToException(Reason.java:531)
at com.ibm.msg.client.jakarta.wmq.common.internal.Reason.createException(Reason.java:215)
at com.ibm.msg.client.jakarta.wmq.internal.WMQMessageConsumer.checkJmqiCallSuccess(WMQMessageConsumer.java:222)
at com.ibm.msg.client.jakarta.wmq.internal.WMQMessageConsumer.checkJmqiCallSuccess(WMQMessageConsumer.java:156)
at com.ibm.msg.client.jakarta.wmq.internal.WMQConsumerShadow.initialize(WMQConsumerShadow.java:1172)
at com.ibm.msg.client.jakarta.wmq.internal.WMQSyncConsumerShadow.initialize(WMQSyncConsumerShadow.java:128)
at com.ibm.msg.client.jakarta.wmq.internal.WMQMessageConsumer.<init>(WMQMessageConsumer.java:486)
at com.ibm.msg.client.jakarta.wmq.internal.WMQSession.createConsumer(WMQSession.java:934)
at com.ibm.msg.client.jakarta.jms.internal.JmsSessionImpl.createConsumer(JmsSessionImpl.java:1012)
at com.ibm.msg.client.jakarta.jms.internal.JmsSessionImpl.createConsumer(JmsSessionImpl.java:1097)
at com.ibm.msg.client.jakarta.jms.internal.JmsQueueSessionImpl.createReceiver(JmsQueueSessionImpl.java:103)
at com.ibm.mq.jakarta.jms.MQQueueSession.createReceiver(MQQueueSession.java:87)
at xxxx.api.messaging.JMSMessagingManager.open(JMSMessagingManager.java:279)
... 4 common frames omitted
Caused by: com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').
at com.ibm.msg.client.jakarta.wmq.common.internal.Reason.createException(Reason.java:203)
The new code uses dependency: implementation group: 'com.ibm.mq', name: 'com.ibm.mq.jakarta.client', version: '9.4.1.0'
as mentioned above we need to use Jakarta EE instead of Java EE, as Spring 6 supports Jakarta EE 9.
The setup that fails, we use to run the application locally on a Windows machine while connecting to remote queues in client mode.
Application in production located on the same host as MQ and uses binding mode (no password, only user ID which is MVS user ID)
We use SecExit to connect in client mode with login and password (again, this is only for the development environment on local machines):
mq.security.exit = biz.capitalware.mqausx.MQAUSXJ2EE
If I intentionally use the wrong user ID or password I get a different error:
Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009;AMQ9204: Connection to host 'xxxxxxx(1415)' rejected. [1=com.ibm.mq.jmqi.JmqiException[CC=2;RC=2009],3=xxxxxxxxx(1415),4=,5=RemoteConnection.asyncConnectionBroken]
at com.ibm.mq.jmqi.remote.api.RemoteFAP$Connector.jmqiConnect(RemoteFAP.java:13703)
at com.ibm.mq.jmqi.remote.api.RemoteFAP$Connector.access$100(RemoteFAP.java:13206)
at com.ibm.mq.jmqi.remote.api.RemoteFAP.jmqiConnect(RemoteFAP.java:1456)
at com.ibm.mq.jmqi.remote.api.RemoteFAP.jmqiConnect(RemoteFAP.java:1397)
at com.ibm.mq.ese.jmqi.InterceptedJmqiImpl.jmqiConnect(InterceptedJmqiImpl.java:377)
at com.ibm.mq.ese.jmqi.ESEJMQI.jmqiConnect(ESEJMQI.java:562)
at com.ibm.msg.client.jakarta.wmq.internal.WMQConnection.<init>(WMQConnection.java:417)
So, I assume authentication passes OK, but then when Queue listener created something goes wrong.
I have searched for this problem and read these discussions:
IBM MQ JMS not working after migration to Spring Boot 3 with com.ibm.mq.jakarta.client.jar 9.3
and this
IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED')
I have tried different combinations of
-Dcom.ibm.mq.cfg.jmqi.useMQCSPauthentication=true -Duser.name=xxxxx
-Dcom.ibm.mq.cfg.jmqi.useMQCSPauthentication=false -Duser.name=xxxxx
-Dcom.ibm.mq.cfg.jmqi.useMQCSPauthentication=false
Nothing helped. In fact no difference, the only difference I see when I try the wrong password.
Since the code works with Java 8 and MQ JMS libs for Java EE, I do not want to modify any setting on QMGR side, mostly because this new set up only needed for development environment.
Any help / hint is appreciated.
Upvotes: 0
Views: 369
Reputation: 7506
I would strongly suggest you contact Capitalware Support.
It appears you have configured & are using the client-side security exit for MQ Authenticate User Security Exit (MQAUSX) and I presume that the z/OS MQAUSX server-side security exit is fully configured.
Application in production located on the same host as MQ and uses binding mode (no password, only user ID which is MVS user ID)
That comment does not make any sense. So, you are running the Java application on z/OS in the same LPAR as the z/OS queue manager? Also, in Bindings mode, the MQ client library does not use a channel, hence, a channel security exit would not be invoked.
If I intentionally use the wrong user ID or password I get a different error: Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2009;AMQ9204
The reason code of 2009 means that the MQAUSX server-side security exit shutdown the channel. i.e. Failed authenication.
You said that you switched from using MQ v8.0 to the latest MQ CSD 9.4.1.0 but IBM has made changes to the underlining handling of UserId sent between the client-side to the server-side queue manager. I'm willing to bet you are getting burnt by this.
Caused by: com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').
It appears that your application's UserId & Password were successfully authenticated by the MQAUSX server-side security exit but failed on RACF/ACF2 authorization for "connecting to the queue manager" or "opening a queue" because the UserId being used for authorization is mismatched.
Ask your z/OS MQAdmin to check the MQAUSX log file to see what MQAUSX outputted It will have a detailed output for the authenticated UserId and the UserId used for accessing the z/OS queue manager. Also, ask the z/OS MQAdmin if the queue manager's log file recorded the RC of 2035 & what was in the error message.
Finally, did you switch channel names to connect to the z/OS queue manager? If so, what value is in the MCAUSER field of the old channel and new channel?
Upvotes: 1