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

Question

我们正在尝试将我们企业中的所有 DLQ 合并为一个 Q（如果您愿意的话，可以是一个 Enterprise_DLQ……）。我们在各种平台上混合了 QM - 大型机、各种 Unix 风格 - Linux、AIX、Solaris 等、Windows、AS/400.... 想法是将 QM 上的 DLQ（在 QM 上设置 DEADQ 属性）配置为集群 Q 的 ENTERPRISE_DLQ。企业中的所有 QM 都是集群的成员。然而，当我们测试它时，这种方法似乎不起作用。 我通过设置一个带有 4 个 QM 的简单集群对此进行了测试。在其中一个 QM 上，为不存在的 QM 和不存在的 Q，但有效的 xmitq 定义了一个 QRemote，并在 QM 之间配置 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 - rcvr chl, ql(local_dlq), ql(qa.enterise_dlq), qr(qr.enterprise.dlq)

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

ql(qm1) 曲线深度(1)

测试 2： 将 QM1 上的 deadq 设置为 qr.enterprise.dlq，将 msg 写入 QM3 上的 QR.NOT_EXIST 结果：消息停留在 QM1 上，QM3.QM1 正在重试，QM1 错误日志抱怨无法 MQOPEN Q - qr.enterprise.dlq（全部大写）！！

ql(qm1) curdepth(2)

测试 3： 将 QM1 上的 deadq 设置为 qa.enterise_dlq，将 msg 写入 QM3 上的 QR.NOT_EXIST 结果：消息保持在 QM1 上，QM3.QM1 正在重试，QM1 错误日志抱怨无法 MQOPEN Q - qa.enterise_dlq（全部大写）！！

ql(qm1) 曲线深度(3)

测试 4： 将 QM1 上的 deadq 设置为 local_dlq，将 msg 写入 QM3 上的 QR.NOT_EXIST 结果：消息保持在 QM1 上，QM3.QM1 正在运行，QM3 ql(QM1) 上的所有消息都进入 QM3 上的 local_dlq。

ql(qm1) curdepth(0)

现在的问题是：看起来 QM 上的 DLQ 必须是本地队列。这是一个正确的结论吗？如果没有，我怎样才能让所有的 DLQ 消息都转到上面的单个 Q - Enterprise_DLQ？

一个明显的解决方案是在 QM3 上的 local_dlq 上定义一个触发器（并在其他 QM 上执行相同操作），它将读取 msg 并将其写入 Cluster Q - ENTERPRISE_DLQ。但这涉及到额外的活动部件 - 每个 QM 上的触发器、触发器监视器。最希望能够将集群 Q/QRemote/QAlias 配置为 QM 上的 DLQ。想法/想法？？？

谢谢 -拉维

Answer 1

根据文档here：

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

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

DLQ 为 QMgr 提供了一种方法来处理通道无法传递的消息。如果 DLQ 不是本地的，那么通道的错误处理本身将依赖于通道。这会带来一些架构设计缺陷。

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

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

考虑到所有这些，该要求似乎带来的挑战多于它解决的问题。建议：最好在不进一步使用通道的情况下处理通道的错误处理 - 即本地。