问题描述
我是WebSphere MQ的初学者，我在MQ 6上工作，并且工作正常，但是现在我已经安装了MQ 7.1，当我尝试创建新的队列管理器时，我可以做到，但是可以. t连接，它给我以下错误:
I'm a beginner on WebSphere MQ, I was working on MQ 6 and it was working fine, but now I've installed MQ 7.1 and when I try to create a new Queue Manager I can do it But it can't connect and it gives me the following error :
您对此有任何想法吗?谢谢:)
Do you have any idea about that? Thank you :)
推荐答案
如果使用mqrc命令安装了WebSphere MQ客户端或服务器，则可以查找任何WebSphere MQ错误代码.在这种情况下:
You can look up any WebSphere MQ error code if either the WebSphere MQ Client or Server are installed using the mqrc command. In this case:
C:\Users\MUSR_MQADMIN>mqrc 2059
2059 0x0000080b MQRC_Q_MGR_NOT_AVAILABLE
2059通常指示侦听器未在运行或队列管理器已关闭.如果侦听器正在运行并且QMgr名称错误，则存在一个不同的错误代码；如果与正确的QMgr建立了连接，但通道名称是错误的，则存在另一个错误代码.如果通道在服务器端由出口关闭，有时您会得到2059，但是由于您没有提及任何出口，因此在这种情况下，我假设它的侦听器问题.
The 2059 usually indicates that the listener is not running or the queue manager is down. There's a different error code if the listener is running and the QMgr name is wrong and another one if the connection is made to the right QMgr but the channel name is wrong. Sometimes you can get a 2059 if the channel was closed at the server side by an exit but since you didn't mention any exits, I'm assuming in this case that its listener problem.
希望到目前为止，您正在定义一个侦听器对象，而不是使用inetd或runmqlsr命令.定义对象并将其设置为在QMgr的控制下启动和停止是配置它的最可靠方法.
Hopefully by now you are defining a listener object rather than using inetd or the runmqlsr command. Defining an object and setting it to start and stop under QMgr control is the most reliable way to configure it.
一旦您超过2059年，您应该意识到，从WMQ V7.1开始，队列管理器默认是安全的，除非您明确授权它们，否则它们将不接受任何任何远程客户端连接. .这与V6的行为相反，在新定义的运行侦听器的队列管理器上，任何具有TCP路由的人都可以对其进行管理，并以mqm用户身份远程执行OS代码.因此，我希望您遇到的下一个问题将是2035错误.
Once you get past the 2059, you should be aware that as of WMQ V7.1, the queue managers are secure by default and won't accept any remote client connections unless you explicitly authorize them. This is the opposite of the behavior of V6 where on a newly defined queue manager running a listener, anyone with a TCP route to it could administer it and remotely execute OS code as the mqm user. So I expect that the next problem you run into will be 2035 errors.
有人告诉我，这意味着WMQ管理员需要做更多的工作.唯一正确的情况是如果没有安全性就配置了V6或更早版本的队列管理器.如果将保护V7.0 QMgr的任务与提供v7.1和更高版本的QMgr的任务进行比较，那么提供访问的结果将变得更加容易.但是，如果您喜欢V7.0的行为，则始终可以更改QMgr以禁用CHLAUTH规则.不用说，强烈建议启用安全性.
I've been told this means more work for the WMQ administrator. The only case in which that's true is if the V6 or earlier queue manager had been configured without security. If the tasks to secure a V7.0 QMgr are compared to the tasks to provision access on a v7.1 and higher QMgr are compared, provisioning access turnds out to be easier. However if you liked the V7.0 behavior, you can always alter the QMgr to disable CHLAUTH rules. Needless to say, leaving security enabled is highly encouraged.
要调试安全性错误，请使用runmqsc命令ALTER QMGR AUTHOREV(ENABLED)更改QMgr以启用授权事件.接下来，下载 SupportPac MS0P 并将其安装到WebSphere MQ Explorer中.然后，当您收到安全性错误时，请使用WebSphere MQ资源管理器查看队列.右键单击队列，然后选择分析事件消息的选项.这将告诉您详尽的调试授权错误所需的所有信息.
To debug security errors, alter the QMgr to enable authorization events using the runmqsc command ALTER QMGR AUTHOREV(ENABLED). Next, download and install SupportPac MS0P into WebSphere MQ Explorer. Then when you do get a security error, use WebSphere MQ Explorer to look at the queue. Right-click on the queue and select the option to parse the event messages. This will tell you in excruciating detail all the information you need to debug the authorization error.
最后，如果您想阅读新的安全功能，请访问 t-rob.net/links 并查看那里的会议演示.如果您向下滚动，也有一些文章被编入索引.
Finally, if you wish to read up on the new security features, go to t-rob.net/links and look at the conference presentations there. There are also some articles indexed if you scroll down.
这篇关于无法连接Websphere MQ队列管理器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！