ibm-mq - MQ安全性-在一个队列中获得2035

我有一个应用程序正在尝试将消息放入远程队列管理器上的队列（LOG.TRANSACTION.IN）。该消息最终失败并显示2035，并放在本地队列管理器的DLQ上。由于没有远程队列定义，因此应用程序在本地队列管理器（QMLOCAL）上将消息直接放在SCTQ上。该应用程序以具有对MQ的完全访问权限的ID运行。我知道这并不理想，但这是另一个讨论。我们在远程端（QMREMOTE）的clusrcvr通道上有一个mcauser，已被授予对本地队列的访问权限。我以为我已经解决了安全问题，但事实并非如此。这是安全信息

QMLOCAL：

Entity application_id has the following authorizations for object SYSTEM.CLUSTER.TRANSMIT.QUEUE:
            get
            browse
            put
            inq
            set
            crt
            dlt
            chg
            dsp
            passid
            passall
            setid
            setall
            clr

QMREMOTE：

Entity MY_MCAUSER has the following authorizations for object LOG.TRANSACTION.IN:
        put
        crt
        setall

任何帮助，将不胜感激。

最佳答案

这里有几种可能性。由于该消息最终出现在DLQ中，因此我们知道问题出在远端。如果您的推销应用程序生成了2035，则该消息将永远不会被发送。

这意味着问题所在是CLUSRCVR通道中的MCAUSER。为了使其正常工作，它需要具有以下内容（假设MY_MCAUSER在mqmmca组中）：

setmqaut -m QMREMOTE -g mqmmca -t qmgr -all +connect +inq +setall
setmqaut -m QMREMOTE -g mqmmca -n 'LOG.TRANSACTION.IN' -t queue -all +put +setall

与您的2035年无关，该频道还需要
setmqaut -m QMREMOTE -g mqmmca -n 'SYSTEM.CLUSTER.COMMAND.QUEUE' -t queue -all +put +setall
只是为了在集群中发挥作用。根据您的版本，通道MCAUSER可能还需要访问SYSTEM.CHANNEL.SYNCQ（v7变体）。

确定的一种简单方法是启用授权事件。
ALTER QMGR AUTHOREV(ENABLED)

授权事件告诉您失败的ID，失败的对象（QMgr，队列等），进行的API调用以及使用的选项。

然后将SupportPac MS0P安装到WMQ Explorer中。这会将二进制PCF事件消息格式化为易于理解的形式，并且很明显问题出在哪里。

在这种情况下，可能是a）MCAUSER在QMgr上缺少+ setall，或者b）是v7，并且MCAUSER在S.C.SQ上缺少适当的权限，如上所述。

关于ibm-mq - MQ安全性-在一个队列中获得2035，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/3933555/