これを引き起こす可能性のあるいくつかの異なる問題があります。 1つは、非リポジトリQMgrを指し示す CLUSSDR チャネルが明示的に定義されている場合です。これにより、リポジトリのメッセージがリポジトリ以外のQMgrに届くため、 amqrrmfa リポジトリプロセスが終了する可能性があります。もう1つは、いくつかのAPARSがあります（この1つ）、それはそのプロセスの死を招く可能性があります。解決策は、構成の問題を修正するか、最新のフィックスパックを適用することです。あまり一般的ではない別の問題は、新しいQMgrがローカルQMgrに解決される前に、新しいQMgrへのメッセージがエラーになることです。この場合、 REFRESH は実際にリモートQMgrを解決させることはありません。
これをデバッグするには、考えられる原因を切り分けます。 amqrrmfa が実行されていることを確認します。すべての非リポジトリQMgrsに1つの明示的に定義されたCLUSSDRチャネルがあることを確認します。すべてのリポジトリに1つのリポジトリと1つの明示的に定義されたCLUSSDRがそれぞれ別のリポジトリにあることを確認します。重複するクラスタを使用する場合は、チャンネルを重ならないようにしてください。これは、 TO.QMGR のようなチャンネル名を避け、 CLUSTER.QMGR のような名前を好むことを意味します。チャネルが CLUSNL 属性を使用しないようにして、代わりに CLUSTER 属性を使用してこれを確認してください。最後に、 DIS CLUSQMGR（*）および DIS QCLUSTER（*）を発行して、両方のリポジトリと非リポジトリのオブジェクトを調整します。リポジトリには、オブジェクトインベントリが同一である必要があります。それが間違っている場合、問題があります。非リポジトリには、以前に話したすべてのQMgrのエントリが必要です。
過去に私が見たことの1つは、管理者が REFRESH CLUSTER をスケジュールしていたことです。彼の考えは、これがクラスタを修正するために必要なものだったので、定期的にそれを稼働させるのはなぜですか？だから彼は毎日実行するようにスケジュールしました。その後毎晩、QMgrはクラスタ内の他のQMgrsについて忘れてしまい、毎日アプリがリモートQMgrを解決したときに、慌ただしいリポジトリトラフィックが発生しました。このため、毎朝2087のエラーが発生していました。 あなたはそのようなことをするわけではありません。 :-)