com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2035'

Question

I am building a Java application that should be able to connect to an IBM WebSphere MQ queue manager and I cannot understand why I keep getting this error.

I alread

Answer 1

If you have set MCAUSER in the channel, then this overrides any ID presented by the client. If you still get a 2035 then there are two possibilities. The first is that the ID in MCAUSER hasn't been properly authorized using setmqaut commands. The second (at least for Windows) is that it's not the right ID. For example, if the channel definition has MCAUSER(userx) instead of MCAUSER('userx@domain') then it is entirely possible that the ID presented is not the same SID that WMQ resolves. This can happen when userx is defined on a laptop and on the WMQ server. The server must be able to resolve the ID presented to the SID that comes with it.

There are additional considerations for WMQ v7.1 regarding CHLAUTH rules. If the ID presented has administrative privileges, WMQ will block it on all channels by default. This is because an administrative ID has full access to WMQ and can remotely execute code on the QMgr's host server using the WMQ services or triggering functionality. So if you have WMQ v7.1 you either need to enable WMQ admin access on the desired channel or use a non-administrative user ID to connect.

Finally, the easiest way to debug all of this is to enable authorization events on the QMgr and install SupportPac MS0P into WMQ Explorer. This will generate an event message every time there's a 2035 and then the MS0P plugin will parse that into human-readable format. The message will tell you...

• What API call failed. (CONNECT, OPEN, CLOSE)
• The options specified on the API call
• The ID making the API call
• The object against which the API call was made

This can be helpful in determining whether you have provided all the right permissions. For example, the Java and JMS classes will inquire on every object they touch. This is how they discover the DLQ name when connecting or the BOQNAME when opening a queue. So if you didn't provide +inq on the QMgr and queue you get a 2035 and the event message will show you the object and options used. Similarly, if you read a poison message and the ID doesn't have rights to the backout queue or the Dead Queue then you get a 2035 which appears (until you look at the event message) to have occurred on a queue from which you have been happily consuming messages. So please be sure to enable Auth events and use MS0P.

If you want a friendly tutorial to WMQ security, there are several conference presentations archived here.