アプリケーションが読み取り用に開いている最上位のキューがローカルに定義されている可能性があります。ただし、WMQ が解決するキューはそうではありません。たとえば、リモートのクラスター化されたキューに対してローカル エイリアスを定義すると、解決されたキューは非ローカルになります。もう 1 つの考えられる原因は、出力用に開く予定のキューが、実際には入力用にも開かれていることです。これは実際には非常に一般的です。
最後に、WMQ クライアントが予想とは異なるキュー マネージャーに接続されていることも、ある程度一般的です。例えば、接続が QMGRA であり、キュー・オブジェクトが QUEUE@QMGRB のような完全修飾名を指定しているとします。キューが QMGRB 上に存在し、JNDI オブジェクトがそのキュー マネージャーを名前で指定している場合でも、QMGRA 上の接続はそれを送信キューに解決するため、非ローカルと見なされます。
Dev でこの種のエラーを解決する最善の方法の 1 つは、SupportPac MA0Wを使用することです。この SupportPac は、API 出口またはチャネル出口として実行され、人間が読める言語ですべての API 呼び出しと呼び出しに選択されたすべてのオプションを一覧表示します。これにより、開かれたオブジェクト名、解決されたオブジェクト、使用されたオプションが明確に表示されます。
または、 strmqtrcを使用してトレースをオンにすることもできます。完了したら、 endmqtrcで無効にすることを忘れないでください。これらのトレースは、QMgr サーバーで有効化および無効化され、WMQ API 呼び出しをトレースします。クライアント側で実行する同等のトレースがありますが、必要な詳細レベルが表示されない場合があります。
最後に、JMS 例外にリンクされたすべての例外を出力することをお勧めします。JMS 例外は、リンクされた例外がプロバイダー固有の値を保持する複数レベルのデータ構造です。たとえば、JMS セキュリティ例外は、WMQ 許可エラーである可能性があります。ただし、キーストアまたはファイルシステムのエラーである可能性があります。リンクされた例外に WMQ 2035 理由コードが表示されない場合、それは WMQ セキュリティ エラーではありません。Infocenterでは、WebSphere MQ classes for JMS の例外という名前のセクションで、リンクされた例外データを印刷する方法について説明しています。
v7.0 WMQ ドキュメントへのリンクを提供したことに注意してください。v6 でコーディングしている場合、これらは完全に正確ではない可能性があるため、代わりにv6.0 Infocenterを参照することをお勧めします。WMQ の v6.0 は 2011 年 9 月の時点でサポートが終了しているため、新しい開発はすべて v7.0 で行うことを強くお勧めします。v7.0 クライアントが必要な場合は、SupportPac MQC7としてダウンロード可能で、v6.0 WMQ サーバーと下位互換性があります。