[Windows]

Windows でのアプリケーション、コマンド、およびメッセージの問題の判別

IBM® MQ アプリケーション、コマンド、およびメッセージで問題が発生した場合は、問題の原因を判別するために考慮できる質問がいくつかあります。

本タスクについて

次の質問を手掛かりとして使用して、問題の原因を見つけてください。

リストの内容を検討しながら、問題と関係がありそうな点をすべてメモしてください。 原因がすぐに判明しない場合でも、体系的な問題判別演習を実行する必要がある場合は、後で役立つ可能性があります。

IBMでケースをオープンする場合、問題の調査に役立つように、収集した追加の IBM MQ トラブルシューティング情報 (MustGather データ) を含めることができます。 詳細については 、「トラブルシューティング情報の収集 」を参照してください。

手順

  1. メッセージはキューへの到達に失敗していますか。
    予期しているときにメッセージが到着しない場合は、メッセージがキューに正常に書き込まれたかどうかを確認します。
    • キューは正しく定義されていますか。 例えば、 MAXMSGL は十分に大きいですか?
    • キューは書き込みが行えるようになっていますか。
    • キューが満杯になっていませんか。
    • 別のアプリケーションがそのキューへの排他的アクセスを取得していませんか。
    また、キューからメッセージを取得できるかどうかも確認します。
    • 同期点をとる必要はありませんか。 同期点内でメッセージが書き込まれたり取り出されたりしている場合、リカバリー単位がコミットされるまで他のタスクはそれらのメッセージを使用できません。
    • 待機間隔の長さは十分ですか。 待機間隔は、MQGET 呼び出しのオプションとして設定できます。 応答を待つ時間を十分に長くしてください。
    • 待っているのは、メッセージ ID (MsgId) または 相関 ID (CorrelId) で特定されるメッセージですか。 待っているメッセージの MsgId または CorrelId が 正しいかどうか確かめてください。 正常な MQGET 呼び出しでは、これらの値はどちらも取り出されたメッセージの値に設定されます。 したがって、別のメッセージを正常に取得するためにこれらの値をリセットする必要があることがあります。 他のメッセージをそのキューから取得できるかどうかも確認してください。
    • 他のアプリケーションはそのキューからメッセージを読み取ることができますか。
    • 予期しているメッセージは、永続メッセージとして定義されましたか。 そうでない場合、 IBM MQ が再始動されていれば、メッセージは失われています。
    • 別のアプリケーションがそのキューへの排他的アクセスを取得していませんか。
    キューに問題が見つからず、 IBM MQ が実行されている場合は、メッセージをキューに入れる予定のプロセスを調べて、以下を確認してください。
    • アプリケーションは開始していましたか。 トリガーで始動されたと思われる場合には、正しいトリガー・オプションが 指定されていたかどうか確認してください。
    • アプリケーションは停止しましたか。
    • トリガー・モニターは実行されていますか。
    • トリガー・プロセスは正しく定義されていましたか。
    • アプリケーションは正しく完了しましたか。 ジョブ・ログに異常終了の記録がないかどうか調べてください。
    • そのアプリケーションは、加えた変更内容をコミットしましたか。 それとも、バックアウトしましたか。

    複数のトランザクションがキューを処理している場合、それらは互いに競合する可能性があります。 例えば、あるトランザクションは、バッファー長ゼロを指定した MQGET 呼び出しを発行してメッセージの長さを調べ、その後、そのメッセージの MsgId を指定した特定の MQGET 呼び出しを発行するとします。 しかし一方で、別のトランザクションは、そのメッセージについて正常な MQGET 呼び出しを発行するため、最初のアプリケーションは理由コード MQRC_NO_MSG_AVAILABLE を受け取ることになります。 複数サーバー環境で実行されることが予期されるアプリケーションは、この状況に対処できるよう設計されている必要があります。

    メッセージは受信されたが、アプリケーションがある点でそれを処理できなかった場合を考えてください。 例えば、予期した形式のメッセージにエラーがあったためプログラムがそれを拒否しましたか。 そうである場合は、このトピックの後半にある情報を参照してください。

  2. メッセージに予期しない情報または破損した情報が含まれていますか。
    メッセージに含まれる情報が、アプリケーションの予期していたものではない場合、またはその情報が何らかの形で破損している場合、次の点を確認してください。
    • ご使用のアプリケーション、またはキューにメッセージを書き込むアプリケーションが変更されていませんか。 すべての変更が、その変更を認識している必要のあるすべてのシステムに等しく反映されていることを確認してください。 例えば、メッセージ・データの形式が変更された可能性がある場合、その変更を取り入れるために両方のアプリケーションを再コンパイルする必要があります。 いずれかのアプリケーションが再コンパイルされない場合、もう一方のアプリケーションにはデータが破損しているように見えます。
    • アプリケーションが誤ったキューにメッセージを送っていませんか。 アプリケーションが受信しているメッセージが、別のキューを処理するアプリケーションを対象にしたものではないかどうかを調べてください。 必要に応じてセキュリティー定義を変更し、無許可のアプリケーションが間違ったキューにメッセージを書き込めないようにしてください。 アプリケーションが別名キューを使用する場合は、別名が正しいキューを指し示していることを確認してください。
    • このキューのトリガー情報は正しく指定されていますか。 ご使用のアプリケーションが始動するはずだったか、それとも別のアプリケーションが始動するはずだったかを確認してください。

    以上を確認しても問題を解決できない場合は、メッセージを送信するプログラムとメッセージを受信するプログラムの両方について、アプリケーション・ロジックを確認してください。

  3. 分散キューの使用時に予期しないメッセージが受信されましたか。
    分散キューを使用するアプリケーションでは、次の点に注意してください。
    • IBM MQ が送信側システムと受信側システムの両方に正しくインストールされ、分散キューイング用に正しく構成されているか。
    • 2 つのシステムを結ぶリンクは使用可能ですか。 両方のシステムが使用可能であり、 IBM MQに接続されていることを確認します。 2 つのシステム間の接続がアクティブであるかどうかを検査してください。 キュー・マネージャー (PING QMGR) またはチャネル (PING CHANNEL) に対して MQSC コマンド PING を使用すると、リンクが操作可能であることを確認できます。
    • トリガー操作が、送信側のシステムでオンに設定されていますか。
    • 待機しているメッセージは、リモート・システムからの応答メッセージですか。 トリガー操作がリモート・システムでアクティブにされているかどうかを検査してください。
    • キューが満杯になっていませんか。 満杯になっている場合は、メッセージが送達不能キューに書き込まれていないかどうかを確認してください。 送達不能キューのヘッダーには、メッセージを宛先キューに書き込めなかった理由を示す理由コードまたはフィードバック・コードが入っています。 詳しくは、 送達不能 (未配布メッセージ) キューの使用 および MQDLH-送達不能ヘッダーを参照してください。
    • 送信側のキュー・マネージャーと受信側のキュー・マネージャーの間に不整合がありませんか。 例えば、メッセージ長が大きすぎて、受信側のキュー・マネージャーには扱えない場合があります。
    • 送信側チャネルと受信側チャネルのチャネル定義には整合性がありますか。 例えば、シーケンス番号の折り返しに不一致があると、分散キューイング・コンポーネントが停止する場合があります。 詳しくは、『分散キューイングとクラスター』を参照してください。
    • データ変換が関係していますか。 送信側のアプリケーションと受信側のアプリケーションの間でデータ形式が異なっている場合には、データ変換が必要です。 データ形式が、組み込まれている形式の 1 つとして認識される場合は、MQGET 呼び出しの発行時に自動的に変換が行われます。 データ形式が変換を行えるものとして認識されない場合には、ユーザー自身のルーチンで変換を行えるように、データ変換出口が取られます。 詳しくは、 データ変換を参照してください。

    問題を解決できない場合は、 IBM サポートにお問い合わせください。

  4. PCF コマンドから応答がありませんでしたか?
    コマンドを発行したものの応答を受け取っていない場合には、以下の事項を確認してください。
    • コマンド・サーバーが実行されているか。 dspmqcsv コマンドを使用して、コマンド・サーバーの状況を確認します。 このコマンドに対する応答で、コマンド・サーバーが実行されていないことが示された場合は、 strmqcsv コマンドを使用して開始してください。 コマンドに対する応答で、MQGET 要求に対して SYSTEM.ADMIN.COMMAND.QUEUE が使用できないことが示される場合は、そのキューを MQGET 要求に対して使用できるようにしてください。
    • 送達不能キューに応答が送られましたか。 送達不能キューのヘッダー構造体には、問題を説明する理由コードまたはフィードバック・コードが含まれます。 詳しくは、 MQDLH-送達不能ヘッダー および 送達不能 (未配布メッセージ) キューの使用を参照してください。 送達不能キューにメッセージが入っている場合は、提供されているブラウズ・サンプル・アプリケーション (amqsbcg) を使用して、MQGET 呼び出しでメッセージをブラウズすることができます。 サンプル・アプリケーションは、命名されたキュー・マネージャーの指定されたキューのすべてのメッセージを処理し、指定されたキューのすべてのメッセージのメッセージ記述子フィールドとメッセージ・コンテキスト・フィールドの両方を表示します。
    • メッセージがエラー・ログに送られましたか。 詳しくは、 AIX、 Linux、および Windows でのエラー・ログ・ディレクトリーを参照してください。
    • キューで、書き込み操作および取得操作が有効になっていますか。
    • WaitInterval の時間の長さは十分か。 MQGET 呼び出しがタイムアウトになった場合は、完了コード MQCC_FAILED および理由コード MQRC_NO_MSG_AVAILABLE が戻されます。 WaitInterval フィールド、および MQGET からの完了コードと理由コードについては、 WaitInterval (MQLONG) を参照してください。
    • 独自のアプリケーションを使用して SYSTEM.ADMIN.COMMAND.QUEUE、同期点を取る必要がありますか? 同期点から要求メッセージを除外した場合を除き、応答メッセージを受信するためには、事前に同期点をとっておく必要があります。
    • キューの MAXDEPTH 属性と MAXMSGL 属性は十分に高い値に設定されていますか?
    • CorrelId フィールドと MsgId フィールドを正しく使用していますか。 キューからすべてのメッセージを確実に受信できるよう、 MsgId と CorrelId の値をアプリケーションで適切に設定してください。

    コマンド・サーバーをいったん停止し、再始動させます。 その時生成されるエラー・メッセージに対応してください。 それでもシステムが応答しない場合は、キュー・マネージャーまたは IBM MQ システム全体に問題がある可能性があります。 まず、キュー・マネージャーを個別に停止して、障害が発生しているキュー・マネージャーの特定を試みます。 このステップで問題が明らかにならない場合は、エラー・ログに生成されたメッセージに応答して、 IBM MQを停止して再始動してみてください。 再始動しても問題が解決しない場合は、 IBM サポートに連絡して支援を受けてください。

  5. 一部のキューのみが失敗していますか?
    キューのサブセットのみで問題が起きている疑いがある場合には、問題があると考えられるローカル・キューを確認してください。

    各キューに関する情報を表示するには、MQSC コマンド DISPLAY QUEUE を使用します。 CURDEPTH が MAXDEPTHの場合、キューは処理されません。 すべてのアプリケーションが正常に実行されているかどうかを検査してください。

    CURDEPTH が MAXDEPTHでない場合は、以下のキュー属性が正しいことを確認してください。
    • トリガー操作が使用されている場合、トリガー・モニターは実行されていますか? トリガーのサイズは大きすぎませんか。 つまり、トリガー操作によってトリガー・イベントが十分な頻度で生成されていますか。 プロセス名は正しいですか。 プロセスは使用可能であり、操作可能ですか。
    • キューは共用可能ですか。 共用可能でなければ、別のアプリケーションがすでにそのキューを入力の目的でオープンしている可能性があります。
    • キューは、読み取り (GET) および書き込み (PUT) が適切に行えるようになっていますか。

    キューからメッセージを取得するアプリケーション・プロセスがない場合、その理由を判別してください。 アプリケーションを開始する必要があるか、接続が中断されたか、または何らかの理由で MQOPEN 呼び出しが失敗したことが原因である可能性があります。 キュー属性 IPPROCS および OPPROCSを確認します。 これらの属性は、キューが入出力のためにオープンされているかどうかを示しています。 値がゼロの場合、該当するタイプの操作は行われないことを示しています。 値が変更されたか、キューがオープンされているが現在はクローズされている可能性があります。

    メッセージの書き込みまたは取得が予定されている時刻の状況を確認してください。

    問題を解決できない場合は、 IBM サポートにお問い合わせください。

  6. 問題はリモート・キューのみに影響しますか?
    問題がリモート・キューにのみ影響する場合は、以下の確認を行ってください。
    • 必要なチャネルが開始されているかどうか、そのチャネルをトリガーできるかどうか、および必要なイニシエーターが実行されているかどうかを確認します。
    • リモート・キューにメッセージを書き込む必要のあるプログラムが問題を報告していないかを確認します。
    • トリガー操作を使用して分散キューイング・プロセスを開始する場合、伝送キューのトリガー操作がオンに設定されているかどうかを検査します。 また、トリガー・モニターが実行されているかどうかも検査します。
    • チャネル・エラーや問題を示すようなメッセージがないかエラー・ログを確認します。
    • 必要ならば、チャネルを手動で開始します。
  7. Windowsでキュー・マネージャーを作成または開始するときにエラー・コードを受け取りますか?
    IBM MQ Explorerまたは amqmdain コマンドが、権限の問題を示すキュー・マネージャーの作成または開始に失敗した場合は、 IBM MQ Windows サービスを実行しているユーザーの権限が不十分であることが原因である可能性があります。

    IBM MQ Windows サービスを構成するユーザーに、 IBM MQ Windows サービスに必要なユーザー権限に記載されている権限があることを確認します。 デフォルトでは、このサービスは MUSR_MQADMIN ユーザーとして実行するよう構成されています。 以降のインストールでは、 Prepare IBM MQ Wizard によって MUSR_MQADMINxという名前のユーザー・アカウントが作成されます。ここで x は、存在しないユーザー ID を表す、次に使用可能な番号です。

  8. アプリケーションまたはシステムの動作が遅いですか
    アプリケーションの動作が遅い場合、ループが起こっている、使用できないリソースを待機している、パフォーマンス上の問題が発生している、などの理由が考えられます。

    おそらく、システムが能力の限界近くで運用されています。 この種の問題は、おそらくシステム負荷がピークに達する時間 (通常は、 午前の中ごろと午後の中ごろ) に最悪になります (複数の時間帯にわたるネットワークでは、システム負荷のピークは他の時間に起こる可能性があります。)

    パフォーマンスの問題は、ハードウェア的な制約に起因することがあります。

    パフォーマンスの低下にシステム負荷が関与しておらず、システム負荷が軽いときにパフォーマンスが低下することがあると分かった場合には、おそらくアプリケーション・プログラムの設計の不備が原因になっています。 これは、特定のキューにアクセスするときにのみ起こる問題として明らかになる場合があります。

    アプリケーションのパフォーマンスが低下したり、キュー (通常は伝送キュー) にメッセージが蓄積したりする一般的な原因は、作業単位の外部で持続メッセージを書き込む 1 つ以上のアプリケーションです。 詳しくは、 メッセージの永続性を参照してください。

    パフォーマンスの問題が解決しない場合は、 IBM MQ 自体に問題がある可能性があります。 これが疑われる場合は、 IBM サポートに連絡して支援を受けてください。