![[z/OS]](ngzos.gif)
z/OS での問題の詳細な調査
システムに変更が加えられていないこと、およびアプリケーション・プログラムに問題がないことを確認したが、事前チェックによって問題の解決が可能になっていない場合に実行する追加検査。
本タスクについて
手順
- 誤った出力を受け取りましたか?受け取った出力に何らかの誤りがあると思う場合は、以下の点を考慮してください。
- 出力を正しくないものとして分類する場合
「誤った出力」とは、予期していなかった出力という意味の場合もあります。 しかし、別の種類のエラーから派生する二次的な結果であることもあるため、 問題判別の中でこの言葉を使用するときは注意が必要です。 例えば同じ出力が繰り返される場合は、その出力が期待どおりであっても、 ループが発生している可能性があります。
- エラー・メッセージ
IBM MQ は、エラー・メッセージを送信することによって、検出した多くのエラーにも応答します。 そのメッセージを「誤った出力」と見なしてしまうことがありますが、それは別の種類の問題の症状にすぎません。 予期しないエラー・メッセージを IBM MQ から受け取った場合は、 Are there any error messages, return codes or other error conditions? を参照してください。 z/OSでの問題の特性の識別を参照してください。
- 予想外のメッセージ
アプリケーションが予期していたメッセージを受信しなかったか、予期しない情報または破損した情報を含むメッセージを受信したか、予期しないメッセージ (例えば、別のアプリケーションに宛てられたメッセージ) を受信した可能性があります。 詳しくは、 z/OSを参照してください。
- 出力を正しくないものとして分類する場合
- 予期しないエラー・メッセージまたは戻りコードを受け取りましたかアプリケーションが予期しないエラー・メッセージを受け取った場合は、エラー・メッセージの発信元が IBM MQ であるか、別のプログラムであるかを検討してください。
- IBM MQ エラー・メッセージ
IBM MQ for z/OS エラー・メッセージには、CSQ の文字の接頭部が付きます。 予期しない IBM MQ エラー・メッセージが (例えば、コンソール・ログまたは CICS® ログに) 表示された場合は、 IBM MQ for z/OS のメッセージ、完了コード、および理由コード を参照して説明を確認してください。これにより、問題を迅速に解決するための十分な情報が得られる可能性があります。あるいは、詳細情報にリダイレクトされる可能性があります。 メッセージを処理できない場合は、 IBM サポートに連絡して支援を受ける必要があります。
- IBM MQ 以外のエラー・メッセージ別の IBM プログラムまたはオペレーティング・システムからエラー・メッセージを受け取った場合は、該当するメッセージおよびコードの資料で、その意味の説明を参照してください。 キュー共用環境では、以下のエラー・メッセージを探してください。
- XES (先頭に IXL という文字が付く)
- Db2® (接頭部に DSN という文字が付きます)
- RRS (先頭に ATR という文字が付く)
- 予想外の戻りコード
アプリケーションが IBM MQから予期しない戻りコードを受け取った場合は、アプリケーションが IBM MQ 戻りコードを処理する方法について、 戻りコード を参照してください。
- IBM MQ エラー・メッセージ
- 異常終了がありましたかアプリケーションが実行を停止した場合は、異常終了が原因である可能性があります。 異常終了は、ユーザーが正常に終了する前に実行中のタスクを終了したことが原因で発生することがあります。例えば、 CICS トランザクションをパージした場合などです。 また異常終了は、アプリケーション・プログラムのエラーが原因の場合もあります。異常終了があったのかどうかは、アプリケーションの種類に応じて、次の場所で知ることができます。
- バッチ・アプリケーションの場合、リストには異常終了が示されます。
- CICS アプリケーションの場合、 CICS トランザクション異常終了メッセージが表示されます。 実行中のタスクが端末タスクなら、このメッセージは画面に現れます。 タスクが端末に接続されていない場合、メッセージは CICS CSMT ログに表示されます。
- IMS アプリケーションの場合、すべての場合に、 IBM MQ for IMS マスター端末と、関連する従属領域のリストにメッセージが表示されます。 端末から入力された IMS トランザクションが処理されていた場合は、エラー・メッセージもその端末に送信されます。
- TSO アプリケーションの場合、画面に戻りコードを含む TSO メッセージが表示されることがあります。 (このメッセージが表示されるかどうかは、システムがどのようにセットアップされているか、およびエラーのタイプに依存します)。
異常終了によっては、アドレス・スペース・ダンプが書き出されることがあります。 CICS トランザクションの場合、トランザクションにとって重要なストレージ域を示すトランザクション・ダンプが提供されます。- アプリケーションがなんらかのデータを渡したものの、そのアドレスがもはや有効でないときは、ユーザーのアドレス・スペースのダンプが書き出されることがあります。注: バッチ・ダンプの場合、ダンプはフォーマット設定され、SYSUDUMP に書き込まれます。 SYSUDUMP については、 z/OSを参照してください。 CICSの場合、システム・ダンプが SYS1.DUMP データ・セット、および取得されるトランザクション・ダンプ。
- IBM MQ for z/OS 自体の問題が原因で異常終了が発生した場合は、異常終了コード
X'5C6'またはX'6C6'が、異常終了理由コードとともに返されます。 この理由コードは、問題の原因を一意的に説明しています。 異常終了コードについては、 IBM MQ for z/OS の異常終了 を参照してください。理由コードの説明については、 戻りコード を参照してください。
プログラムが異常終了した場合は、 IBM MQ for z/OSでの異常終了の処理を参照してください。
システムが異常終了し、生成されたダンプを分析したい場合は、「 IBM MQ for z/OS ダンプ」を参照してください。 このセクションでは、ダンプの書式設定方法と、そこに含まれているデータの解釈方法について説明します。
- MQSC コマンドから応答がありませんでしたか?z/OS コンソールからではなく、アプリケーションから MQSC コマンドを発行したが、応答を受け取っていない場合は、以下の質問を考慮してください。
- コマンド・サーバーが実行されているか。次のようにして、コマンド・サーバーが動作しているか調べてください。
- z/OS コンソールで DISPLAY CMDSERV コマンドを使用して、コマンド・サーバーの状況を表示します。
- コマンド・サーバーが稼働していない場合は、 START CMDSERV コマンドを使用して始動します。
- コマンド・サーバーが稼働している場合は、システム・コマンド入力キューの名前と CURDEPTH および MAXDEPTH 属性を指定した DISPLAY QUEUE コマンドを使用して、表示されるデータを定義します。 これらの値によりキューが満杯であることが示され、コマンド・サーバーが開始済みの場合は、キューからメッセージが読み取られていません。
- コマンド・サーバーをいったん停止し、再始動させます。 その時生成されるエラー・メッセージに対応してください。
- もう一度表示コマンドを出して、 コマンド・サーバーが動作するようになったかどうかを確認します。
- 送達不能キューに応答が送られましたか。
システムの送達不能キューの名前が分からない場合は、 DISPLAY QMGR DEADQ コマンドを使用して名前を見つけてください。 この名前を DISPLAY QUEUE コマンドで CURDEPTH 属性とともに使用して、キューにメッセージがあるかどうかを確認します。 送達不能キュー・メッセージ・ヘッダー (送達不能ヘッダー構造体) には、問題を記述する理由コードまたはフィードバック・コードが含まれています 送達不能ヘッダー構造体については、 Reason (MQLONG)を参照してください。
- それらのキューに対して PUT と GET が許されていますか。
コンソールから DISPLAY QUEUE コマンドを使用して確認します (例:
DISPLAY QUEUE(SYSTEM.COMMAND.INPUT) PUT GET)。 - WaitInterval パラメーターに設定した時間の長さは十分ですか。
MQGET 呼び出しがタイムアウトになった場合、アプリケーションは完了コード 2、および理由コード 2033 (MQRC_NO_MSG_AVAILABLE) を受け取ります。 ( WaitInterval パラメーター、および MQGET からの完了コードと理由コードについては、 WaitInterval (MQLONG) および MQGET-メッセージの取得 を参照してください。)
- 同期点が必要ですか。
システム・コマンド入力キューへのコマンドの書き込みに独自のアプリケーション・プログラムを用いている場合は、 同期点をとる必要があるかどうかを考慮してください。 キューにメッセージを書き込んだ後や、応答メッセージの受信を試行する前には、 同期点をとるか、メッセージの書き込み時に MQPMO_NO_SYNCPOINT を使用する必要があります。 同期点から要求メッセージを除外している場合を除き、応答メッセージの受信を試行するには、事前に同期点をとっておかなければなりません。
- キューの MaxDepth
パラメーターと MaxMsgL パラメーターに設定した大きさは十分ですか。
システム・コマンド入力キューおよび応答先キューの定義については、 CSQO016E を参照してください。
- CorrelId パラメーターと
MsgId パラメーターを正しく使用していますか。
キューを識別してから、 CURDEPTHを表示する必要があります。 コンソールから DISPLAY QUEUE コマンド (例えば、
DISPLAY QUEUE (MY.REPLY.QUEUE) CURDEPTH)) を使用して、受信していないメッセージが応答先キューにあるかどうかを確認します。 キューからすべてのメッセージを確実に受信できるよう、MsgIdとCorrelIdの値をアプリケーションで適切に設定してください。
z/OS コンソール (または同等のもの) またはアプリケーションのいずれかから MQSC コマンドを発行したが、応答を受け取っていない場合は、以下の質問が適用されます。- キュー・マネージャーがまだ動作していますか、
あるいはコマンドが異常終了の原因になりましたか。
異常終了を示すエラー・メッセージを探してください。異常終了が発生した場合は、 IBM MQ for z/OS ダンプを参照してください。
- 何らかのエラー・メッセージが出されましたか。
エラーの性質を示すエラー・メッセージが出されていないかどうかを調べます。
MQSC コマンドの入力に使用できるさまざまな方法については、 コマンドの発行を参照してください。
- コマンド・サーバーが実行されているか。
- IBM MQ キューに問題がありますか?サブシステム上のキューに影響を及ぼしている問題があるような場合は、 操作および制御パネルを使用してシステム・コマンド入力キューを表示してみてください。
- システムは応答しましたか? システムが応答する場合は、少なくとも 1 つのキューは動作しています。 この場合は、ステップ 6に進みます。
- システムは応答していませんか? サブシステム全体の問題である可能性があります。 このインスタンスでキュー・マネージャーをいったん停止し、再始動させます。 その時書き出されるエラー・メッセージに対応してください。 コンソールにアクションが必要なメッセージが示されていないかを確認します。 アーカイブ・ログ用のテープをマウントする要求など、 IBM MQに影響を与える可能性のあるすべての問題を解決します。 他のサブシステムまたは CICS 領域が影響を受けるかどうかを確認します。 DISPLAY QMGR COMMANDQ コマンドを使用して、システム・コマンド入力キューの名前を識別します。
- 再始動後も問題が発生しますか? お問い合わせ先: IBM ヘルプデスク( トラブルシューティング情報の収集を参照)。
- キューの一部は動作していますか?キューのサブセットのみで問題が発生していると思われる場合は、問題があると思われるローカル・キューの名前を選択し、 DISPLAY QUEUE および DISPLAY QSTATUS コマンドを使用して、キューに関する情報を表示します。
- キューは処理されていますか。
- CURDEPTH が MAXDEPTHの場合、キューが処理されていないことを示している可能性があります。 キューを使用するすべてのアプリケーションが正常に実行されていることを確認します (例えば、 CICS システム内のトランザクションが実行されていること、または Queue Depth High イベントに応答して開始されたアプリケーションが実行されていることを確認します)。
- キューが入力用にオープンしているかどうかを確認するには、コマンド
DISPLAY QSTATUS(xx) IPPROCSを使用します。 入力用にオープンされていなければ、アプリケーションを始動します。 - CURDEPTH が MAXDEPTHでない場合は、以下のキュー属性が正しいことを確認してください。
- トリガー操作が使用されている場合、トリガー・モニターは実行されていますか? トリガー・サイズが大きすぎませんか。 プロセス名は正しいですか。 すべてのトリガー条件が満たされていますか?
コマンド
DISPLAY QSTATUS(xx) IPPROCSを使用して、アプリケーションが同じキューを入力用にオープンしているかどうかを確認します。 トリガーのシナリオによっては、 キューが入力用にオープンされているとトリガー・メッセージが生成されない場合があります。 トリガー処理を起動させるためには、アプリケーションを停止します。 - キューは共用可能ですか。 そうでない場合は、別のアプリケーション (バッチ、 IMS、または CICS) が既に入力用にオープンしている可能性があります。
- キューは、読み取り (GET) および書き込み (PUT) が適切に行えるようになっていますか。
- トリガー操作が使用されている場合、トリガー・モニターは実行されていますか? トリガー・サイズが大きすぎませんか。 プロセス名は正しいですか。 すべてのトリガー条件が満たされていますか?
- 長時間実行中の作業単位がありますか
CURDEPTH がゼロではないが、メッセージを MQGET しようとすると、キュー・マネージャーが、使用可能なメッセージがないと応答する場合は、コマンド
DIS QSTATUS(xx) TYPE(HANDLE)を使用して、キューをオープンしているアプリケーションに関する情報を表示するか、コマンドDIS CONN(xx)を使用して、キューに接続しているアプリケーションに関する詳細情報を表示します。 - キューにアクセスしているタスクはいくつありますか。
キューにメッセージを書き込んだり、キューからメッセージを取得したりするタスクの数を確認するには、コマンド
DISPLAY QSTATUS(xx) OPPROCS IPPROCSを使用します。 キュー共有環境では、各キュー・マネージャーの OPPROCS と IPPROCS を確認します。 あるいは、 CMDSCOPE 属性を使用して、すべてのキュー・マネージャーを検査します。 キューからメッセージを読み取るアプリケーション・プロセスがない場合は、理由を判別してください。例えば、アプリケーションを開始する必要がある場合、接続が中断された場合、何らかの理由で MQOPEN 呼び出しが失敗した場合などです。 - このキューは共用キューですか。 その問題の影響を受けるのは共用キューだけですか。
共用キューをサポートするシスプレックスのエレメントに問題がないことを確認します。 例えば、 IBM MQ管理のカップリング・ファシリティー・リスト構造に問題がないことを確認します。
コマンド
D XCF, STRUCTURE, STRNAME=ALLを使用して、カップリング・ファシリティー構造体がアクセス可能であることを確認します。コマンド
D RRSを使用して、RRS がアクティブであることを確認します。 - このキューはクラスターの一部ですか。
キューがクラスターの一部であるかどうかを確認します ( CLUSTER 属性または CLUSNL 属性から)。 クラスターの一部である場合、 そのキューのホストとなっているキュー・マネージャーがクラスター内で活動状態であるかどうか確認してください。
- キューは処理されていますか。
- キューは正しく定義されていますかIBM MQ には、特定の事前定義キューが必要です。 これらのキューが 正しく定義されていないと、問題が発生する可能性があります。
- システム・コマンド入力キュー、システム・コマンド応答モデル・キュー、 および応答先キューが正しく定義されているかどうかを調べ、 MQOPEN 呼び出しが正常に行われたかどうかを確認します。
- システム・コマンド応答モデル・キューを使用しているなら、その定義が正しいかどうかを調べてください。
- クラスターを使用している場合、クラスター処理に関係するコマンドを使用するには、 SYSTEM.CLUSTER.COMMAND.QUEUE を定義する必要があります。
- その問題の影響を受けているのはリモート・キューまたはクラスター・キューだけですか問題がリモート・キューまたはクラスター・キューにのみ影響する場合は、以下のことを調べます。
- リモート・キューへのアクセスは行われていますか。 リモート・キューにメッセージを書き込むプログラムが正常に実行されたことを確認します ( z/OSを参照してください)。
- システム・リンクは活動していますか。 必要に応じて APPC コマンドまたは TCP/IP コマンドを使用して、2 つのシステムの間のリンクが活動状態であるかどうか調べます。 TCP/IP の場合は PING または OPING を使用し、APPC の場合は
D NET ID=xxxxx, Eを使用します。 - トリガーは動作していますか。 トリガー操作によって分散キューイング・プロセスを開始させるようにしているときは、 伝送キューでトリガー操作がオンにセットされていること、 およびそのキューが使用可能になっていることを確かめます。
- チャネルやリスナーは稼働していますか。 必要なら、チャネルやリスナーを手動で開始するか、チャネルの停止と再始動を試行します。 詳しくは、 分散キューイングの構成 を参照してください。 チャネル・イニシエーターとリスナーの始動に関するエラー・メッセージを探します。 IBM MQ for z/OS のメッセージ、完了コード、および理由コード 、および「 分散キューイングの構成 」を参照して、原因を判別してください。
- チャネルはどのような状況にありますか。 DISPLAY CHSTATUS (channel_name) コマンドを使用してチャネル状況を確認します。
- プロセスとチャネルの定義は正しいですか。 プロセス定義とチャネル定義を調べます。
分散キューイングの使用方法、およびチャネルの定義方法については、 分散キューイングの構成を参照してください。
- その問題の影響を受けるのは共用キューだけですか。
問題がキュー共有グループにのみ影響する場合は、 CSQ5PQSG ユーティリティーの VERIFY QSG 機能を使用します。 このコマンドは、 Db2 セットアップが、 Db2 キュー・マネージャー、構造、および共有キュー・オブジェクトのビットマップ割り振りフィールドとオブジェクト定義に関して整合していることを検査し、検出された不整合の詳細を報告します。
以下は、エラーのある VERIFY QSG レポートの例です。
CSQU501I VERIFY QSG function requested CSQU503I QSG=SQ02, DB2 DSG=DSN710P5, DB2 ssid=DFP5 CSQU517I XCF group CSQGSQ02 already defined CSQU520I Summary information for XCF group CSQGSQ02 CSQU522I Member=MQ04, state=QUIESCED, system=MV4A CSQU523I User data=D4E5F4C15AD4D8F0F4404040C4C5.... CSQU522I Member=MQ03, state=QUIESCED, system=MV4A CSQU523I User data=D4E5F4C15AD4D8F0F3404040C4C6.... CSQU526I Connected to DB2 DF4A CSQU572E Usage map T01_ARRAY_QMGR and DB2 table CSQ.ADMIN_B_QMGR inconsistent CSQU573E QMGR MQ04 in table entry 1 not set in usage map CSQU574E QMGR 27 in usage map has no entry in table CSQU572E Usage map T01_ARRAY_STRUC and DB2 table CSQ.ADMIN_B_STRUCTURE inconsistent CSQU575E Structure APPL2 in table entry 4 not set in usage map CSQU576E Structure 55 in usage map has no entry in table CSQU572E Usage map T03_LH_ARRAY and DB2 table CSQ.OBJ_B_QUEUE inconsistent CSQU577E Queue MYSQ in table entry 13 not set in usage map for structure APPL1 CSQU576E Queue 129 in usage map for structure APPL1 has no entry in table CSQU528I Disconnected from DB2 DF4A CSQU148I CSQ5PQSG Utility completed, return code=12 - アプリケーションまたは IBM MQ for z/OS の動作が遅いですか?低速アプリケーションは、アプリケーション自体、または IBM MQなどの基礎となるソフトウェアが原因で発生する可能性があります。アプリケーションの動作が遅いことの原因としては、ループが起こっていること、 あるいは使用できない何らかのリソースを待っていることが考えられます。
- この問題はシステム負荷がピークに達する時間に最もひどくなりますか。 また、パフォーマンス上の問題の可能性もあります。 使用しているシステムのチューニングが必要な場合もありますし、 能力の限界で動作していることも考えられます。 この種の問題は、おそらくシステム負荷がピークに達する時間 (通常は、 午前の中ごろと午後の中ごろ) に最悪になります ネットワークが複数のタイム・ゾーンにまたがっている場合は、システム負荷のピークが別の時間に発生するように見えることがあります。
- この問題はシステムの負荷が軽いときに起こりますか。 パフォーマンスの低下がシステム負荷の大小によらず、システム負荷の軽いときにも見られるなら、 おそらく、アプリケーション・プログラムの設計の悪さが原因です。 この問題は、特定のキューへのアクセスが起こったときにのみ、問題として表面化することがあります。
- IBM MQ for z/OS の動作が遅くなっていますか? 以下の症状は、 IBM MQ for z/OS の実行速度が遅いことを示している可能性があります。
- コマンドへのシステムの応答が遅い場合
- キューのサイズが繰り返し表示されることにより、 大量のキュー活動が予想されるアプリケーションでキューの処理が遅いことを示している場合
待機およびループの処理に関するガイダンスについては、 z/OSで実行速度が遅い、または停止したアプリケーションの処理、およびパフォーマンス上の問題の処理について、 z/OSを参照してください。
- アプリケーションまたは IBM MQ for z/OS が処理を停止しましたか?システムが予期せずに作業の処理を停止することには、いくつかの理由があります。 検査する問題領域には、以下のものがあります。
- キュー・マネージャーに問題がありますか? キュー・マネージャーはシャットダウンされる場合があります。
- アプリケーションに問題がありますか? アプリケーション・プログラミング・エラーは、プログラムが正常な処理から外れて分岐したり、アプリケーションでループが発生したりしていることを意味している可能性があります。 アプリケーションの異常終了が起こったことも考えられます。
- IBM MQに問題がありますか? キューが MQPUT または MQGET 呼び出しで使用不可になったか、送達不能キューが満杯になったか、 IBM MQ for z/OS が待ち状態またはループ状態になっている可能性があります。
- z/OS またはその他のシステムの問題がありますか? z/OS が待ち状態であるか、 CICS または IMS が待ち状態またはループ状態である可能性があります。 システムやシスプレックスのレベルで問題が存在する可能性もあり、 キュー・マネージャーやチャネル・イニシエーターに影響が及ぶ恐れがあります。 例えば、過度のページングなどの問題が考えられます。 また、DASD の問題、あるいは優先順位の高いタスクによるプロセッサーの使用量が高いことを示している場合もあります。
- Db2 または RRS に問題がありますか。 Db2 および RRS がアクティブであることを確認してください。
いずれのケースにおいても、以下の検査を実行して問題の原因を判別してください。
- エラー・メッセージを確認します。DISPLAY THREAD(*) コマンドを使用して、キュー・マネージャーが実行されているかどうかを確認します。 キュー・マネージャーが実行を停止した場合は、状態を説明している可能性のあるメッセージを探してください。 メッセージは、 z/OS コンソール、または操作パネルと制御パネルを使用している場合は端末に表示されます。 DISPLAY DQM コマンドを使用して、チャネル・イニシエーターが機能しているかどうか、およびリスナーがアクティブであるかどうかを確認します。 z/OS コマンド
を実行すると、応答が解決されていないメッセージがリストされます。 これらの応答のいずれかが関係しているかどうかを調べてください。 状況によっては (例えば、すべてのアクティブ・ログを使用した場合)、 IBM MQ for z/OS はオペレーターの介入を待機します。DISPLAY R,L - エラー・メッセージがない場合は、以下の z/OS コマンドを発行します。
ここで、DISPLAY A,xxxxMSTR DISPLAY A,xxxxCHINxxxxは IBM MQ for z/OS サブシステム名です。キュー・マネージャーやチャネル・イニシエーターが見つからないという意味のメッセージが返されてきたときは、 そのサブシステムが終了しています。 この状態の原因は、異常終了またはオペレーターによるシステムのシャットダウンの場合があります。
サブシステムが実行中の場合は、メッセージ IEE105Iを受け取ります。 このメッセージには CT=nnnn フィールドがあり、 そのサブシステムが使用したプロセッサー時間についての情報が含まれています。 このフィールドの値を記録し、同じコマンドをもう一度出してください。- CT= 値が変化していなければ、 サブシステムはプロセッサー時間をまったく使用していません。 この場合、そのサブシステムが待ち状態にある (あるいは、 実行する作業がない状態にある) ことが考えられます。 DISPLAY DQM のようなコマンドを発行して、出力が戻ってきた場合は、ハング状態ではなく、行うべき作業がないことを示しています。
- CT= 値が大幅に変化しており、表示するたびに同じことが起こる場合は、 そのサブシステムがビジーであるか、ループしていると考えられます。
- サブシステムが見つからないという応答が返ってくれば、 最初のコマンドを出したとき、そのサブシステムは終了の途中だったと思われます。 ダンプを書き出すようにしてあると、サブシステムが終了するまでに多少の時間がかかります。 終了の前に、コンソールにメッセージが書き出されます。 チャネル・イニシエーターが機能していることを確認するには、 DISPLAY DQM コマンドを発行します。 応答にチャネル・イニシエーターの動作が示されない場合は、 プロセッサーなどのリソースの不足が原因となっている可能性があります。 この場合は、RMF などの z/OS モニター・ツールを使用して、リソースに問題があるかどうかを判別してください。 リソースに問題がなければ、チャネル・イニシエーターを再始動します。
- 終了したキュー・マネージャーまたはチャネル・イニシエーターが異常終了したかどうかを確認する。キュー・マネージャーやチャネル・イニシエーターのアドレス・スペースが異常終了したことを伝えるメッセージがないか、 探してください。 IBM MQを終了させるシステム処置を示すメッセージが出された場合は、システム・ダンプが作成されたかどうかを調べてください。 詳しくは、 IBM MQ ダンプを参照してください。
- IBM MQ for z/OS がまだ実行されている可能性があるかどうかを確認します。また、 IBM MQ for z/OS がまだ実行されているが、実行に時間がかかっている可能性があることも考慮してください。 その動作が実際に遅くなっているなら、おそらく、パフォーマンス上の問題が起こっています。 これを確認するには、ステップ 10を参照してください。 次に行うことについてのアドバイスは、 パフォーマンス上の問題の処理を参照してください。