队列管理器*上的DLQ是否必须*是QM上的本地队列？

Question

我们正试图将企业中所有的DLQ合并成一个Q(如果您愿意的话是一个Enterprise_DLQ )。我们有各种平台上的QMs -大型机，各种Unix口味- Linux，AIX，Solaris等，Windows，AS/400.其想法是将QM上的DLQ (在QM上设置DEADQ属性)配置为ENTERPRISE_DLQ (集群Q )的属性。企业中的所有QMs都是集群的成员。然而，当我们测试它时，这种方法似乎不起作用。我已经通过建立一个4 QMs的简单集群来测试这个问题。在其中一个QM上，将QRemote定义为不存在的QM和不存在的Q，但定义一个有效的xmitq，并在QMs之间配置requsite SDR chl，如下所示：

QM_FR - Full_Repos QM1，QM2，QM3 -集群成员

QM_FR主机ENTERPRISE_DLQ，并向集群发布广告

在QM3上设置以下内容:QM3.QM1-SDR到QM1，ql( QM1 )，使用xmitq，qr(qr.not_exist) rqmname(not_exist) rname(not_exist) xmitq( QM1 )，在消息到达QM1时启动QM1以触发QM3.QM1

关于QM1: QM3.QM1-RCVRCHL，ql(local_dlq)，ql(qa.enterise_dlq)，qr(qr.enterprise.dlq)

测试1:在QM1上将死q设置为ENTERPRISE_DLQ，在QM3结果上为QR.NOT_EXIST写一个消息: msg停留在QM1上，QM3.QM1正在重试，QM1错误日志抱怨不能将Q- ENTERPRISE_DLQ！

ql(qm1)曲线深度(1)

测试2:在QM1上将死q设置为qr.enterprise.dlq，在QM3结果上给QR.NOT_EXIST写一个消息: msg停留在QM1上，QM3.QM1正在重试，QM1错误日志抱怨不能将Q- qr.enterprise.dlq (所有的大写)！

ql(qm1)曲线深度(2)

测试3:在QM1上将死q设置为qa.enterise_dlq，在QM3结果上给QR.NOT_EXIST写一个消息: msg停留在QM1上，QM3.QM1正在重试，QM1错误日志抱怨不能将Q- qa.enterise_dlq (所有的大写)！

ql(qm1)曲线深度(3)

测试4:将QM1上的deadq设置为local_dlq，将msg写入QM3结果上的QR.NOT_EXIST : Msg停留在QM1上，QM3.QM1正在运行，QM3 ql(QM1)上的所有Msg都在QM3上运行。

ql(qm1)曲线深度(0)

现在的问题是:看起来QM上的DLQ必须是本地队列。这是正确的结论吗？如果不是，我如何使所有DLQs msg转到上面的单个q- Enterprise_DLQ？

一个明显的解决方案是在local_dlq上QM3上定义一个触发器(在其他QMs上也这样做)，它将读取msg并将其写入集群q- ENTERPRISE_DLQ。但这涉及到额外的移动部件-触发器，触发监视器对每个QM。最理想的是能够将集群Q/QRemote/QAlias配置为QM上的DLQ。想法/想法？

谢谢-Ravi

Answer 1

根据文档这里

死信队列没有特殊要求，只是：

• 它必须是本地队列。
• 它的MAXMSGL (最大消息长度)属性必须使队列能够容纳队列管理器拥有的最大消息。 处理加上死信标题的大小(MQDLH)

DLQ为QMgr提供了一种处理通道无法传递的消息的方法。如果DLQ不是本地的，那么通道的错误处理本身就取决于通道。这将在某种程度上造成架构设计缺陷。

执行所需任务的规定方法是触发作业，将消息转发到远程队列。这样，每当消息到达DLQ时，触发的作业就会触发并转发消息。如果您不想编写这样的程序，您可以很容易地使用一些shell或Perl代码以及来自SupportPac MA01的q程序。最好将用于从QMgr发送此类消息的通道设置为不使用DLQ。理想情况下，这些信息将存在于专用集群中，这样DLQ流量就不会与应用程序通信混合。

另外，如果转换错误阻止消息发送，则DLQ的功能之一是将消息从XMitQ中移出。将它们转发到一个中心位置会产生将它们重新放到集群XMitQ上的效果。类似地，如果目标被填满，这些消息也将位于发送qMgr的集群XMitQ上。如果它们的数量足够多，那么一个完整的集群XMitQ就会阻止所有集群通道的工作。在这种情况下，您需要某种工具来让您有选择地删除或将消息从集群XMitQ中移出，这可能有点困难。

考虑到所有这些，这个需求所带来的挑战似乎比它所解决的要多。建议:对通道的错误处理最好不要进一步使用通道--即本地通道。