Oracle TMA TCP for IMSのモニタリング

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

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

•	Oracle TMA TCP for IMSの運用

•	Oracle 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』を参照してください。

•	/SEC OTMA security-level

すべてのメッセージのセキュリティをチェックするには、security-levelにFULLを指定します。

リクエスト時にのみセキュリティをチェックするには、security-levelにPROFILEを指定します。

セキュリティのチェックを無効にするには、security-levelにNONEを指定します。

•

/DIS OTMA

OTMAのステータスを表示します。

•

/STO OTMA

OTMAのメッセージングを停止します。

•

/STA OTMA

OTMAのメッセージングを有効にします。

•	/DIS TMEMBER name TPIPE ALL

クライアントのステータスを表示します。

•	/STO TMEMBER name TPIPE ALL

個々のクライアントがサービスにアクセスできないようにします。

•	/STA TMEMBER name TPIPE ALL

個々のクライアントを有効にし、サービスへのアクセスを許可します。

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製品が、定義されたローカル・ゲートウェイ(ポート)ごとのTCP/IPリスナーを確立します。

•	リクエストに応じて、リモート・ゲートウェイとの発信セッションが確立されます。

•	TMA TCP for IMS製品は、z/OSコンソールに処理待ち用の要応答オペレータ書出し(WTOR)を出力し、オペレータ・コマンドの入力が可能な状態にします。

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

通常の運用

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

•	リモート・システムから開始された新規の着信セッションのリクエストが受け付けられます。

•	必要に応じて、新規の発信セッションがリクエストされ、リモート・システムとの間で確立されます。

•	TMA TCP for IMS製品がリモート・システムからのリクエストやレスポンスがないかTCP/IPネットワークをモニターします。

•	着信リクエストがTCP/IPネットワークを介してリモート・システムから送信され、対応するIMSサーバー・トランザクションに中継されます。

•	IMSのクライアントやサーバーのトランザクションからリクエストやレスポンスがないか、IMSがポーリングされます。

•	IMSクライアント・トランザクションから発行された発信リクエストが、TCP/IPネットワークを介して対応するリモート・システムに中継されます。

•	TMA TCP for IMS製品がリクエストの進行状況をモニターして、(必要に応じて)レスポンスが指定時間内に受信されたことを確認します。

•	オペレータ・コマンド(処理待ちコマンドWTORに対する応答として入力)が処理されます。

オペレータ・コマンド

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

リスト5-1 WTORに応答するときの構文

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コマンドが受信され受け付けられると、次の処理が行われます。

1.	TMA TCP for IMSゲートウェイが新しい着信接続の(リモート・システムからの)リクエストの受付けを停止します。

2.	処理中のトランザクションが完了するまで待たずに、アクティブな着信セッションと発信セッションが停止します。

3.	メッセージ・ログとサーバー・レスポンス・ログのデータセットが閉じます。

4.	TMA TCP for IMSゲートウェイが終了し、z/OSに制御が戻ります。

SHUTDOWNコマンド

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

リスト5-2 終了処理開始の構文

R nn,SHUTDOWN

 

クライアント開始の停止

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

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

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

注意:	この機能を使用するには、構成ファイルのSYSTEM文(デフォルトはNO)にCLIENTSHUTDOWN==YESを指定する必要があります。そうでない場合、TMA TCP for IMSは、停止処理を開始するリモート・クライアント・リクエストを無視します。

リスト5-3 クライアント開始の停止の構文

F jobname TERM=type

 

jobname

TMA TCP for IMSに割り当てられたz/OSのジョブ名です。

TERM=type

システムの停止方法です。typeの値は次のとおりです。

STOP

通常の停止です。TERM=STOPを指定した場合、TMA TCP for IMSは、オペレータがz/OSコンソールからSHUTDOWNコマンドを入力したときと同じように、通常の停止処理を開始します。

DUMP

ダンプを出力して異常終了します。TERM=DUMPが指定された場合、TMA TCP for IMSはU3166の異常終了を発行します。SYSUDUMP DD文がJCLに含まれている場合は、標準的なz/OSダンプが生成されます。

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のメッセージが記録されていても、ログは上書きされます。

メッセージ・フォーマット

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

リスト5-4 メッセージ・ログのフォーマット

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

 

mm-dd-yyyy

mmは、メッセージが記録された月(1～12)です。

ddは、メッセージが記録された日(1～31)です。

yyyyは、メッセージが記録された年です。

hh:mm:ss

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

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

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

図5-1 msgid

BEAnnnntというフォーマットのメッセージIDであり、nnnnは一意のメッセージ番号、tはメッセージのタイプです。

ssss

メッセージが関連付けられているTCP/IP接続のソケット番号です。メッセージがTCP/IP接続に関連付けられていない場合、このフィールドは空白です。

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がレスポンスを受信することがあります。これは次の状態になったときに発生する可能性があります。

•	リクエストがIMSに送信されてから、まだレスポンスが受信されていない段階でTMA TCP for IMSゲートウェイが再起動された場合。この場合には、TMA TCP for IMSが次回以降に再起動されるときに、レスポンスが通常どおり受信されるようになります。

•	リクエストがIMSに送信されてから、まだレスポンスが受信されていない段階で、リモート・ゲートウェイとのTCP/IP接続が切断された場合。

•	リクエストがIMSに送信されてから、まだIMSからのレスポンスが受信されていない段階で、タイムアウトになり中断された場合。

•	IMSサーバー・トランザクションが、レスポンスの必要がないリクエストに対してレスポンスを戻した場合。

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

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

注意:	サーバー・レスポンスのログ・ファイルのデータセット属性は、アーキテクチャごとに固定です。詳細は、Oracle Oracle Tuxedo Mainframe Adapter for TCPインストレーション・ガイドを参照してください。