隊列管理器*上的DLQ是否必須是QM上的本地隊列？

Question

我們正試圖將我們企業中的DLQ全面整合到一個Q中（如果您願意...）。我們在各種平臺上混合使用QM - 大型機，各種Unix風格 - Linux，AIX，Solaris等，Windows，AS/400 .... 想法是在QM上配置DLQ（將DEADQ屬性設置爲質量管理）與作爲羣集Q的ENTERPRISE_DLQ的QM進行比較。企業中的所有QM都是羣集的成員。但是，當我們測試它時，這種方法似乎不起作用。 我已經通過設置一個具有4個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觸發啓動QM3.QM1，當msg到達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 結果：Msg停留在QM1，QM3.QM1正在重試，QM1錯誤日誌抱怨無法MQOPEN Q - ENTERPRISE_DLQ！

QL（QM1）CURDEPTH（1）

測試2： 對QM1設置deadq到qr.enterprise.dlq，寫了味精在QM3 QR.NOT_EXIST 結果：消息原地踏步上QM1，QM3 QM1正在重試，QM1錯誤日誌抱怨無法MQOPEN Q - qr.enterprise.dlq（全部大寫）!!

QL（QM1）CURDEPTH（2）

測試3： 上QM1設置deadq到qa.enterise_dlq，寫了味精在QM3 QR.NOT_EXIST 結果：消息原地踏步上QM1，QM3.QM1正在重試，QM1錯誤日誌抱怨不能MQOPEN Q - qa.enterise_dlq（全部大寫）！

QL（QM1）CURDEPTH（3）

測試4： 上QM1設置deadq到local_dlq，寫了味精在QM3 QR.NOT_EXIST 結果：消息原地踏步上QM1，QM3.QM1是RUNNING ，QM3上的所有消息ql（QM1）將其轉換爲QM3上的local_dlq。

QL（QM1）CURDEPTH（0）

現在的問題是：看起來在QM 像DLQ必須是本地隊列。這是一個正確的結論嗎？如果沒有，我如何才能讓所有DLQ msg都轉到上面的單個Q-Enterprise_DLQ？

一個明顯的解決方案是在QM3上的local_dlq上定義觸發器（並在其他QM上執行相同的操作），它將讀取消息並將其寫入羣集Q - ENTERPRISE_DLQ。但是這涉及到額外的移動部件 - 觸發，觸發每個QM上的監視器。能夠將Q/QRemote/QAlias配置爲QM上的DLQ是最理想的。思考/想法？

感謝 -Ravi

Answer 1

每文檔here：

死信隊列有不同之處在於沒有特殊要求：

• 它必須是一個本地隊列
• 其MAXMSGL（最大消息長度）屬性必須使隊列能夠容納隊列管理器的最大消息已經
  來處理加死信報頭（MQDLH）

的DLQ提供了一種用於QMGR來處理一個信道無法傳遞消息的裝置的尺寸。如果DLQ不是本地的，那麼通道的錯誤處理本身將依賴於通道。這會帶來一些建築設計缺陷。

規定的方式來做你需要的是觸發一個工作轉發消息到遠程隊列。通過這種方式，只要消息遇到DLQ，觸發的作業就會啓動並轉發消息。如果您不想編寫這樣的程序，您可以輕鬆使用一些shell或Perl代碼以及來自SupportPac MA01的Q程序。建議用於從QMgr發送這些消息的信道將被設置爲不使用DLQ。理想情況下，這些將存在於專用羣集中，以便DLQ流量不與應用流量混合。

另外，請注意，如果轉換錯誤阻止它們發送，DLQ的其中一個功能是將消息移出XMitQ。將它們轉發到中央位置可能會將它們重新放回集羣XMitQ。同樣，如果目的地已滿，這些消息也將位於發送qMgr的羣集XMitQ上。如果它們的數量足夠多，則完整集羣XMitQ將阻止所有集羣通道正常工作。在這種情況下，您需要某種工具來讓您有選擇地刪除或移出羣集XMitQ中的消息，這會有點具有挑戰性。

考慮到這一切，這項要求似乎會面臨比解決問題更多的挑戰。建議：通道的錯誤處理最好在不進一步使用通道的情況下處理 - 即在本地處理。