com.ibm.mq.MQException：MQJE001：完成代码“2”，原因“2035”
我正在构建一个应该能够连接到 IBM WebSphere MQ 队列管理器的 Java 应用程序，但我不明白为什么我不断收到此错误。
我已经通过 MQ Explorer 使用 setmqaut 向我的用户 ID 授予了管理权限。我还在我的频道中定义了 MCAUSER，并将该用户与 MQ Windows 组相关联。
谁能提供一个简短的教程/示例，说明如何将 Java 程序与 Windows 环境上的 WebSphere MQ 安装连接起来？
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 already gave administration privileges to my userID using setmqaut through MQ Explorer. I also defined the MCAUSER in my channel and I also associated the user with the MQ Windows group.
Can anyone please give a short tutorial/example of how to connect a Java program with a WebSphere MQ installation on a Windows Environment?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您在通道中设置了
MCAUSER，则这会覆盖客户端提供的任何 ID。如果你仍然得到 2035 那么有两种可能性。首先是MCAUSER中的 ID 尚未使用setmqaut命令正确授权。第二个（至少对于Windows）是它不是正确的ID。例如，如果通道定义具有MCAUSER(userx)而不是MCAUSER('userx@domain')，那么所提供的 ID 完全有可能不是同一个 SID WMQ 解决了。当在笔记本电脑和 WMQ 服务器上定义userx时，可能会发生这种情况。服务器必须能够解析呈现给它附带的SID的ID。对于 WMQ v7.1，还有有关 CHLAUTH 规则的其他注意事项。如果提供的 ID 具有管理权限，WMQ 默认会在所有通道上阻止它。这是因为管理 ID 具有对 WMQ 的完全访问权限，并且可以使用 WMQ 服务或触发功能在 QMgr 的主机服务器上远程执行代码。因此，如果您有 WMQ v7.1，您需要在所需通道上启用 WMQ 管理员访问权限或使用非管理用户 ID 进行连接。
最后，调试所有这些的最简单方法是在 QMgr 上启用授权事件并将 SupportPac MS0P 安装到 WMQ Explorer 中。每次出现 2035 时都会生成一条事件消息，然后 MS0P 插件会将其解析为人类可读的格式。该消息将告诉您...
CONNECT、OPEN、CLOSE）这有助于确定您是否提供了所有正确的权限。例如，Java 和 JMS 类将查询它们接触的每个对象。这就是它们在连接时发现 DLQ 名称或在打开队列时发现 BOQNAME 的方式。因此，如果您没有在 QMgr 和队列上提供
+inq，您将收到 2035，并且事件消息将向您显示所使用的对象和选项。类似地，如果您读取了一条有害消息，并且该 ID 无权访问回退队列或死队列，那么您会收到 2035，该消息显示（直到您查看事件消息）已发生在您已从中获取的队列上。一直在愉快地消费消息。因此，请务必启用 Auth 事件并使用 MS0P。如果您想要有关 WMQ 安全性的友好教程，此处存档了多个会议演示文稿。
If you have set
MCAUSERin 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 inMCAUSERhasn't been properly authorized usingsetmqautcommands. The second (at least for Windows) is that it's not the right ID. For example, if the channel definition hasMCAUSER(userx)instead ofMCAUSER('userx@domain')then it is entirely possible that the ID presented is not the same SID that WMQ resolves. This can happen whenuserxis 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...
CONNECT,OPEN,CLOSE)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
+inqon 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.