IMSユーザー・ガイド

Oracle TMA TCP for IMSの監視

次のトピックで、Oracle Tuxedo Mainframe Adapter for TCP (IMS)(以後TMA TCP for IMSと呼ぶ)製品の運用と監視について説明します。

リモート・システムとの接続のテスト

TMA TCP for IMSを初めて起動する場合は、小規模で簡潔な構成を使用した、抑制された環境で起動する必要があり、そうすることで、システムを系統的にテストして、インストールと構成の妥当性を検証できます。

テストに適した構成は、IMSゲートウェイ(1ポート)と1つのリモート・ゲートウェイです。SOURCE配布ライブラリに、リモートのOracle Tuxedo Mainframe Adapterゲートウェイとの接続のテストに使用できるIMSのクライアント・トランザクションとサーバー・トランザクションのサンプルが何種類か収録されています。

リモート・ゲートウェイに対する発信セッションにできるだけ小さい数(0より高い数)を指定しておけば、初期化中にそのゲートウェイとの間で自動的に発信セッションを確立できます。これは、テスト用のトランザクションを使用せずに、発信の接続が確立できたかを検証するときに便利です。

双方向の接続を検証するには、構成の両側でクライアントとサーバーのテスト用のトランザクションを実行します。エラーが発生した場合は、構成の両側(つまりIMSゲートウェイおよびリモートのOracle Tuxedoゲートウェイ)から発行される診断メッセージを使用して、問題を特定し修正します。

TMA TCP for IMSのエラー・メッセージの説明は、「エラー・メッセージと情報メッセージ」の項を参照してください。

OTMAの監視およびトラブルシューティング

次のコマンドは、OTMAの接続に関する問題を監視したりトラブルシューティングする際に役に立つ、何種類かの使用可能なIMSコマンドです。これらのIMSコマンドの定義と構文については、『IMS/ESA Operator’s Reference』または『Open Transaction Manager Access Guide』を参照してください。

Oracle TMA TCP for IMSの運用

TMA TCP for IMS製品はJCLを実行して起動します。サンプルのJCLについては、「JCLおよびユーザー・イグジットのサンプル」の項を参照してください。

運用中に、TMA TCP for IMSはすべてのメッセージをメッセージ・ログ・データセット(DDNAME=MSGLOG)に記録します。メッセージ・ログは、TMA TCP for IMSの終了後に履歴を調べる際に最も役に立ちます。実行中にメッセージ・ログは出力のために開いたままになっているため、終了してデータセットが閉じるまで、(ISPF Browseなどを使用して)最近のメッセージは参照できません。

情報メッセージとエラー・メッセージについては、z/OSコンソールにも書き込まれるため、システム・オペレータがそれらのメッセージをリアルタイムで参照できます。構成ファイルにMSGLEVEL=4(通常のモード)を指定した場合、メッセージ・ログに書き込まれるすべてのメッセージは、z/OSコンソールにも表示されます。

初期化

初期化中に次の処理が行われます。

初期化中にエラーが検出された場合は、TMA TCP for IMSが該当するエラー・メッセージを発行し、初期化が失敗します。初期化が失敗した場合は、示されたエラーを解消し、TMA TCP for IMSを再起動します。

通常の運用

初期化が成功した場合は、次の処理が行われている間に、通常の運用が開始されます。

オペレータ・コマンド

通常の運用中に、TMA TCP for IMSは、コマンドの入力に使用できる処理待ち用のWTOR(メッセージID BEA2113I)を出力します。処理待ち用のWTORに単に応答する形(リスト5-1に示すフォーマット)でコマンドを入力します。

R nn,command

リスト5-1のnnはz/OSから割り当てられた応答IDで、commandはコマンドのテキストです。

セッション関連のメッセージの発行

通常の運用中には、セッション関連のイベントに関するメッセージのみが発行されます。これらにはTCP/IP接続を確立するリクエスト、2つのゲートウェイ間のセッションを確立するリクエスト、セッションの切断およびセッションの終了が含まれます。したがって、通常の運用中には、コンソールのトラフィックの発生量が最小限に抑えられます。TCP/IP接続に関連するメッセージには、4桁のTCP/IPソケットID(メッセージIDの直後に続く)が格納されます。

終了方法

通常の運用は、SHUTDOWNコマンドが受信されるまで継続されます。通常の状態では、SHUTDOWNオペレータ・コマンドを(入力待ちコマンドWTORから)入力すると、TMA TCP for IMSは停止します。

SHUTDOWNコマンドが受信され受け付けられると、次の処理が行われます。

SHUTDOWNコマンド

SHUTDOWNコマンドを使用して、オペレータはTMA TCP for IMSの終了処理を開始できますが、このときの入力フォーマットはリスト5-2に示すとおりです。

R nn,SHUTDOWN

クライアント開始の停止

TMA TCP for IMS製品では、リモートのクライアント・リクエストまたはリモートのクライアント・リクエストに対するレスポンスによる停止を開始するように構成できます。これは、z/OSコンソールからのオペレータ・コマンドからではなく、リモート・システムからTMA TCP for IMSを停止する必要がある場合に役に立つことがあります。

停止のリクエストは、IMSサーバー・リクエストのユーザー・リクエスト・データ、またはIMSサーバー・レスポンスのユーザー・レスポンス・データに、次のフォーマットで変更コマンドを埋め込むことによって行います。

コマンドのフォーマットはリスト5-3に従います。指定したjobnameが正しくない場合、TMA TCP for IMSは単にそのコマンドを無視し、通常のリクエストまたはレスポンスとして処理します。

F jobname TERM=type 

jobname

TERM=type

Oracle TMA TCP for IMSのメッセージ・ログ

TMA TCP for IMS製品では、発行されるすべてのメッセージを記録するためにメッセージ・ログ・データセットが使用されます。通常、メッセージ・ログ(DDNAME=MSGLOG)はディスクのデータセットに割り当てますが、必要に応じて別の宛先(sysout)に割り当てることもできます。

メッセージ・ログの主な目的は履歴として使用することです。つまり、TMA TCP for IMSのアクティビティを事後に確認する手段として使用します。メッセージ・ログは、TMA TCP for IMSが実行している間は常に出力のために開いたままになります。したがって、データセットが廃棄されたり、メッセージがz/OSによってバッファに格納されるため、メッセージを通常どおり対話的に(ISPF Browseを使用するなどして)表示することはできません。

構成ファイル内のSYSTEM文のMSGLEVELパラメータは、ログに書き込まれるメッセージのタイプを制御します。MSGLEVELに4を指定すると、すべての情報メッセージとエラー・メッセージが記録されます。MSGLEVELに2を指定すると、エラー・メッセージのみが記録されます。MSGLEVELに0(ゼロ)を指定すると、ログには何も記録されません。通常の状態では、MSGLEVELに4を指定する必要があります。

TMA TCP for IMS用のJCLのMSGLOG DD文にDISP=MODを記述すると、既存のログにメッセージを追加書きする(つまり、今までのTMA TCP for IMSの実行で記録されてきたメッセージを残す)ことができます。また、DISP=OLDまたはDISP=SHRを記述すると、今までのTMA TCP for IMSのメッセージが記録されていても、ログは上書きされます。

メッセージ・フォーマット(Message Format)

メッセージ・ログに書き込まれる各メッセージの全般的なフォーマットは、リスト5-4に示すとおりです。

mm-dd-yyyy hh:mm:ss msgid ssss text

mm-dd-yyyy

hh:mm:ss

mmは、メッセージが記録された時刻の分です。

ssss

text

ゲートウェイから発行されるメッセージの詳細は、「エラー・メッセージと情報メッセージ」の項を参照してください。

z/OSコンソールのメッセージ

TMA TCP for IMS製品はz/OSコンソールにもメッセージを出力するため、オペレータはTMA TCP for IMSの運用状況を監視し、対処が必要な状況になったときに対応できます。

基本的にTMA TCP for IMSはメッセージ・ログに記録するものと同じメッセージ(つまり情報メッセージとエラー・メッセージ)をコンソールに出力します。しかし、通常の運用中にはTMA TCPが発行する情報メッセージはほとんどないため、コンソールのトラフィックは最小限になります。

サーバー・レスポンスのログ・ファイル

TMA TCP for IMSがリモート・システムからクライアント・リクエストを受信すると、そのリクエストは、指定のIMSサーバー・トランザクションに配信するためのIMSメッセージ・キューに挿入されます。IMSサーバー・トランザクションはリクエストを処理し、TMA TCP for IMSに配信するためのIMSメッセージ・キューにレスポンスを挿入します(必要な場合)。レスポンスが受信されると、リクエスト元のリモート・システムに戻されます。

それぞれのIMSサーバー・リクエストとそれに伴うレスポンスには、TMA TCP for IMSの起動日時とシリアル番号から構成される、一意のリクエスト/レスポンスIDが格納されます。TMA TCP for IMSゲートウェイはリクエスト/レスポンスIDを使用して、各レスポンスと処理待ちのサーバー・リクエストを相互に関連付けます。

処理待ちのリクエストがないIMSサーバー・トランザクションから、TMA TCP for IMSがレスポンスを受信することがあります。これは次の状態になったときに発生する可能性があります。

レスポンスと処理待ちのリクエストを関連付けることがてきない場合(つまり、一致するリクエスト/レスポンスIDが見つからない処理待ちのリクエスト)、TMA TCP for IMSはサーバー・レスポンスのログ・ファイル(DDNAME=SVRLOG)にレスポンスを書き込みます。サーバー・レスポンスのログ・ファイルの情報は、手動でリカバリ手順を実施するときに役に立つことがあります。サーバー・レスポンスが記録されていることを示し、その理由(サーバー・リクエストが見つからない、またはレスポンスが予期されていない)を示すメッセージBEA2033Eも発行されます。

サーバー・レスポンスは、BEAサーバーのリクエスト/レスポンスのヘッダー(一意のリクエスト/レスポンスIDを格納)と、レスポンス・データという2つのレコードにそれぞれ記録されます。