私は WebSphere MQ の初心者です。MQ 6 で作業していて、問題なく動作していましたが、MQ 7.1 をインストールしたので、新しいキュー マネージャーを作成しようとすると、それを実行できますが、接続できず、それは私に次のエラーを与えます:
それについて何か考えはありますか?ありがとうございました :)
私は WebSphere MQ の初心者です。MQ 6 で作業していて、問題なく動作していましたが、MQ 7.1 をインストールしたので、新しいキュー マネージャーを作成しようとすると、それを実行できますが、接続できず、それは私に次のエラーを与えます:
それについて何か考えはありますか?ありがとうございました :)
コマンドを使用して WebSphere MQ クライアントまたはサーバーがインストールされている場合は、WebSphere MQ エラー コードを調べることができますmqrc
。この場合:
C:\Users\MUSR_MQADMIN>mqrc 2059
2059 0x0000080b MQRC_Q_MGR_NOT_AVAILABLE
2059 は通常、リスナーが実行されていないか、キュー マネージャーがダウンしていることを示します。リスナーが実行されていて QMgr 名が間違っている場合は別のエラー コードがあり、正しい QMgr に接続されているがチャネル名が間違っている場合は別のエラー コードがあります。チャネルが出口によってサーバー側で閉じられた場合、2059 を取得できる場合がありますが、出口について言及していないため、この場合はリスナーの問題であると想定しています。
inetd
またはrunmqlsr
コマンドを使用するのではなく、リスナー オブジェクトを定義していることを願っています。オブジェクトを定義し、QMgr の制御下で開始および停止するように設定することは、最も信頼できる設定方法です。
2059 を過ぎると、WMQ V7.1 の時点で、キュー マネージャーはデフォルトで保護されており、明示的に承認しない限り、リモート クライアント接続を受け入れないことに注意する必要があります。これは、リスナーを実行する新しく定義されたキュー マネージャーで、リスナーへの TCP ルートを持つすべてのユーザーがそれを管理し、mqm
ユーザーとして OS コードをリモートで実行できる V6 の動作とは逆です。したがって、次に遭遇する問題は 2035 エラーになると思います。
これは、WMQ 管理者の仕事が増えることを意味すると言われています。これが当てはまる唯一のケースは、V6 以前のキュー マネージャーがセキュリティなしで構成されていた場合です。V7.0 QMgr を保護するためのタスクを v7.1 以降の QMgr でアクセスをプロビジョニングするためのタスクと比較すると、アクセスをプロビジョニングする方が簡単であることがわかります。ただし、V7.0 の動作が気に入った場合は、いつでも QMgr を変更してCHLAUTH
ルールを無効にすることができます。言うまでもなく、セキュリティを有効のままにしておくことを強くお勧めします。
セキュリティ エラーをデバッグするには、QMgr を変更して、runmqsc
コマンドを使用して承認イベントを有効にしますALTER QMGR AUTHOREV(ENABLED)
。次に、SupportPac MS0Pをダウンロードして WebSphere MQ Explorer にインストールします。その後、セキュリティー・エラーが発生した場合は、WebSphere MQ エクスプローラーを使用してキューを調べてください。キューを右クリックし、イベント メッセージを解析するオプションを選択します。これにより、承認エラーをデバッグするために必要なすべての情報が非常に詳細に表示されます。
最後に、新しいセキュリティ機能について詳しく知りたい場合は、t-rob.net /links にアクセスして、そこで開催される会議のプレゼンテーションをご覧ください。下にスクロールするとインデックスされた記事もあります。
スクリーンショットでは、ホスト名「127.0.0.1」とポート番号 1414 が表示されます。ローカル キュー マネージャーの場合は、それに直接接続します。
また、各キュー マネージャーは一意のポート番号を使用する必要があります。WMQ v6 キュー マネージャーで動作していた場合、これは同じキュー マネージャーですか? そうでない場合は、各キュー マネージャーが異なるポート番号 (1415、1416 など) を使用していることを確認してください。