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

我们正试图将我们企业中的所有DLQ整合为一个单独的Q（企业级DLQ，如果您愿意…）。我们在各种平台上混合使用QMs—大型机、各种Unix风格—Linux、AIX、Solaris等、Windows、AS/400。。。。 其想法是将QM上的DLQ（在QM上设置DEADQ属性）配置为ENTERPRISE_DLQ的DLQ，后者是集群Q。企业中的所有QM都是集群的成员。然而，当我们测试它时，这种方法似乎不起作用。 我通过设置一个具有4个QMs的简单集群来测试这一点。在其中一个QM上，将QRemote定义为不存在的QM和不存在的Q，但定义为有效的xmitq，并在QMs之间配置重新使用SDR chl，如下所示：

QM\U FR-全面回购 QM1、QM2、QM3-群集的成员

QM_FR承载向集群播发的ENTERPRISE_DLQ

在QM3上设置以下内容： QM3.QM1-sdr到QM1，ql（QM1）使用xmitq，qr（qr.not_存在）rqmname（not_存在）rname（not_存在）xmitq（QM1），设置QM1以在消息到达QM1时触发启动QM3.QM1

关于QM1： QM3.QM1-rcvr chl、ql（本地）、ql（qa.enterise）、qr（qr.enterprise.dlq）

测试1： 将QM1上的deadq设置为ENTERPRISE_DLQ，将消息写入QR。QM3上不存在 结果：消息保持在QM1上，QM3.QM1正在重试，QM1错误日志抱怨无法MQOPEN Q-ENTERPRISE_DLQ

ql（qm1）curdepth（1）

测试2： 将QM1上的deadq设置为qr.enterprise.dlq，将消息写入qr.NOT_QM3上存在 结果：消息保持在QM1上，QM3.QM1正在重试，QM1错误日志抱怨无法MQOPEN Q-qr.enterprise.dlq（所有上限）

ql（qm1）curdepth（2）

测试3： 将QM1上的deadq设置为qa.enterise_dlq，将消息写入QR.NOT_存在于QM3上 结果：消息保持在QM1上，QM3.QM1正在重试，QM1错误日志抱怨无法MQOPEN Q-qa.enterise_dlq（所有caps）

ql（qm1）curdepth（3）

测试4： 将QM1上的deadq设置为local_dlq，将消息写入QR。QM3上不存在 结果：Msg保持在QM1上，QM3.QM1正在运行，QM3 ql（QM1）上的所有Msg都在QM3上的本地_dlq上

ql（qm1）curdepth（0）

现在的问题是：看起来QM上的DLQ必须是本地队列。这是正确的结论吗？如果没有，我如何将所有DLQ消息发送到上面的单个Q-Enterprise_DLQ

一个显而易见的解决方案是在QM3上的本地_dlq上定义一个触发器（在其他QMs上也这样做），它将读取消息并将其写入集群Q-ENTERPRISE_dlq。但这涉及到额外的运动部件-触发器，每个QM上的触发器监视器。最理想的是能够将集群Q/QRemote/QAlias配置为QM上的DLQ。想法/想法

谢谢 -Ravi

根据文件：

死信队列没有特殊要求，除了：

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

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

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

另外，请注意，如果转换错误阻止消息被发送，DLQ的功能之一是将消息移出XMitQ。将它们转发到中心位置将产生将它们放回集群XMitQ的效果。类似地，如果目的地已满，这些消息也将位于发送qMgr的集群XMitQ上。如果它们在那里建立了足够的数量，完整的集群XMitQ将阻止所有集群通道工作。在这种情况下，您需要某种工具来允许您有选择地删除或将消息移出集群XMitQ，这将有点困难

---

考虑到所有这些，这个需求似乎带来了比它解决的更多的挑战。建议：频道的错误处理最好在不进一步使用频道的情况下进行-即在本地进行。

感谢Rob-感谢您的及时响应。