| ドキュメントのダウンロード | サイトマップ | 用語集 | |
|
|||
| bea ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > Tuxedo > COBOL を使用した Tuxedo アプリケーションのプログラミング > エラーの管理 |
|
COBOL を使用した Tuxedo アプリケーションのプログラミング
|
エラーの管理
ここでは、次の内容について説明します。
システム・エラー
BEA Tuxedo システムでは、TP-STATUS IN TPSTATUS-REC を使用して、ルーチンが失敗した場合にプロセスに情報が渡されます。すべての ATMI 呼び出しは、TP-STATUS にエラーの内容を示す値を設定します。サービス・ルーチンを終了させるために使用する TPRETURN や TPFORWAR など、呼び出し元に戻らない関数の場合、成功か失敗かを確認する唯一の方法は要求元の TP-STATUS 変数です。
APPL-RETURN-CODE は、ユーザ定義の条件だけを通知します。APPL-RETURN-CODE には、TPRETURN 時に APPL-CODE IN TPSVCRET-REC の値が設定されます。TPRETURN エラーまたはトランザクション・タイムアウトが発生しない限り、APPL-RETURN-CODE IN TPSTATUS-REC の値に関係なく、APPL-RETURN-CODE に値が設定されます。
TP-STATUS に返されるコードは、エラーの種類を示します。次の表は、そのエラーの種類を示しています。
表 11-1 TP-STATUS エラーの種類
アボート・エラー
アボートの原因となるエラーについては、致命的なトランザクション・エラーを参照してください。
BEA Tuxedo のシステム・エラー
BEA Tuxedo のシステム・エラーは、問題がアプリケーション・レベルではなくシステム・レベルで発生していることを示します。BEA Tuxedo のシステム・エラーが発生すると、エラーの原因を示すメッセージが中央イベント・ログに書き込まれ、TP-STATUS に TPESYSTEM が返されます。詳細については、中央イベント・ログを参照してください。これらのエラーは、アプリケーションではなくシステムで発生するので、エラーの修正についてはシステム管理者に問い合わせてください。
通信ハンドルのエラー
通信ハンドルのエラーは、通信ハンドルの数が上限値を超えている場合、または無効な値を参照している場合に発生します。非同期呼び出しや会話型呼び出しでは、未処理の通信ハンドルの数が上限値を超えると、TPELIMIT が返されます。操作に対して無効な通信ハンドルの値が指定されている場合は、TPEBADDESC が返されます。
通信ハンドルのエラーが発生するのは、非同期呼び出しまたは会話型呼び出しを行った場合だけです。同期呼び出しでは、呼び出し記述子は使用されません。非同期呼び出しでは、通信ハンドルを使用して対応する要求に応答が対応付けられます。会話型送受信用のルーチンは、通信ハンドルを使用して接続を識別します。つまり、接続を開始する呼び出しでは、通信ハンドルを使用できることが大切です。
通信ハンドルのエラーのトラブル・シューティングは、アプリケーション・レベルで特定のエラーを調べて行います。
上限値に関するエラー
システムでは、コンテキスト (または BEA Tuxedo アプリケーションへの対応付け) ごとに未処理の通信ハンドル (応答) を 50 個まで使用できます。この上限値はシステムで定義されているので、アプリケーションで再定義することはできません。
会話型接続を同時に行う場合の通信ハンドルに関する制限は、応答時の制限ほど厳しくありません。上限値は、アプリケーション管理者がコンフィギュレーション・ファイルに定義します。アプリケーションが実行中ではない場合、管理者はコンフィギュレーション・ファイルの RESOURCES セクションの MAXCONV パラメータを変更できます。アプリケーションが実行中の場合も、MACHINES セクションは動的に変更できます。詳細については、『BEA Tuxedo コマンド・リファレンス』の tmconfig、wtmconfig(1) を参照してください。
無効な記述子によるエラー
通信ハンドルは無効になることがあります。無効な通信ハンドルが参照されると、次の場合に TP-STATUS にエラーが返されます。
通信ハンドルが無効になるのは、以下のような場合です。
会話に関するエラー
会話型サービスで不明なハンドルが指定されると、TPSEND、TPRECV、および TPDISCON ルーチンは TPEBADDESC を返します。
会話型接続の確立後に TPSEND と TPRECV が TPEEVENT エラーで失敗した場合、イベントが発生します。TPSEND でデータを送信できるかどうかは、発生したイベントによって決まります。システムは、TPSTATUS-REC の TPEVENT メンバの TPEEVENT を返します。行われる処理は、発生したイベントによって異なります。
会話型イベントの詳細については、7-14 ページの「会話型通信イベント」を参照してください。
複製オブジェクトに関するエラー
処理の結果として複製オブジェクトが生成されるような操作が試みられると、TP-STATUS に TPEMATCH エラー・コードが返されます。次の表は、TPEMATCH エラー・コードを返すルーチンとその原因を示しています。
これらのルーチンの詳細については、『BEA Tuxedo COBOL リファレンス』を参照してください。
一般的な通信呼び出しのエラー
一般的な通信呼び出しのエラーは、呼び出しが同期または非同期で行われたかどうかに関係なく、どのような通信呼び出しでも発生する可能性があります。TP-STATUS には、TPESVCFAIL、TPESVCERR、TPEBLOCK、または TPGOTSIG が返されます。
TPESVCFAIL および TPESVCERR エラー
TPCALL または TPGETRPLY を呼び出した結果、通信の応答部分が失敗すると、TP-STATUS に TPESVCERR または TPSEVCFAIL が返されます。TPRETURN に渡された引数でエラーが判別され、この呼び出しで実行する処理が決定されます。
引数の処理中に TPRETURN でエラーが発生すると、システムはエラーを元の要求元に返し、TP-STATUS に TPESVCERR を設定します。受信側では、TP-STATUS の値を調べてエラーの発生を確認します。システムでは、TPRETURN 呼び出しからのデータ送信は行われず、TPGETRPLY でエラーが発生した場合は、呼び出しハンドルが無効なものと見なされます。
TPRETURN で TPESVCERR エラーが発生していない場合、TP-RETURN-VAL に返された値で呼び出しが成功したか失敗したかを判断できます。アプリケーションで、TP-RETURN-VAL に TPFAIL が指定されると、システムは TP-STATUS に TPESVCFAIL を返し、呼び出し元にデータ・メッセージを送信します。TP-RETURN-VAL に TPSUCCESS が設定されると、呼び出し元に制御が正常に戻り、TP-STATUS は設定されず、呼び出し元がデータを受信します。
TPEBLOCK および TPGOTSIG エラー
TPEBLOCK および TPGOTSIG エラー・コードは、メッセージの要求側に返される場合も応答側に返される場合もあるので、すべての通信呼び出しに対して返される可能性があります。
ブロッキング状態が発生している場合に、要求を同期または非同期に送信するプロセスでブロッキング状態を無視するように TPPNOBLOCK が設定されていると、システムは TPEBLOCK を返します。たとえば、システムのキューがすべていっぱいになっている場合、要求が送信されるとブロッキング状態になります。
TPCALL がブロッキング状態を示していない場合は、通信の送信部分だけに影響します。要求の送信に成功すると、その呼び出しが応答を待っている間にブロッキング状態が存在したとしても、TPEBLOCK は返されません。
TPNOBLOCK を設定して呼び出しを行った場合、TPGETRPLY が応答を待っている間にブロッキング状態が発生すると、TPGETRPLY に TPEBLOCK が返されます。この状況は、メッセージがその時点で使用できない場合などに発生します。
TPGOTSIG エラーは、シグナルによってシステム・コールに割り込みが発生したことを示します。このような状況は、実際にはエラーではありません。TPSIGRSTRT が設定されていると、呼び出しは失敗せず、TP-STATUS に TPGOTSIG エラー・コードが返されます。
無効な引数によるエラー
無効な引数によるエラーは、ルーチンに渡された引数が無効であることを示しています。引数を取る ATMI 呼び出しは、無効な引数が渡されると失敗します。呼び出し元に制御が戻る呼び出しの場合、関数は失敗して、TP-STATUS に TPEINVAL が設定されます。TPRETURN または TPFORWAR の場合、要求を開始して結果を待っている TPCALL または TPGETRPLY に対して、TP-STATUS に TPESVCERR が設定されます。
ルーチンに有効な引数だけを渡すようにすると、無効な引数によるアプリケーション・レベルでのエラーを修正できます。
エントリがないために発生するエラー
レコード・タイプを識別するためのデータ構造体やシステム・テーブルにエントリがないと、エラーが発生します。エントリ・タイプのエラーを示す TPENOENT の意味は、そのエラーを返す呼び出しによって異なります。次の表は、このエラーを返す呼び出しとエラーのさまざまな原因を示しています。
表 11-2 エントリがないために発生するエラー
オペレーティング・システムのエラー
オペレーティング・システムのエラーは、オペレーティング・システム・コールが失敗したことを示します。TP-STATUS に TPEOS が返されます。UNIX システムの場合、失敗したシステム・コールを識別する整数値がグローバル変数 Uunixerr に返されます。オペレーティング・システム・エラーを修正するには、システム管理者に問い合わせてください。
パーミッション・エラー
呼び出し元プロセスに、アプリケーションに参加するために必要なパーミッションが設定されていない場合、TPINITIALIZE 呼び出しは失敗して、TP-STATUS に TPEPERM が返されます。パーミッションは、コンフィギュレーション・ファイルに設定されるもので、アプリケーションには設定されません。このエラーが発生した場合は、アプリケーション管理者に問い合わせて、必要なパーミッションがコンフィギュレーション・ファイルに設定されていることを確認してください。
プロトコル・エラー
ATMI 呼び出しが間違った順序で行われた場合、または間違ったプロセスを使用して行われた場合、プロトコル・エラーが発生します。たとえば、アプリケーションに参加する前に、クライアントがサーバとの通信の開始を試みると、このエラーが発生します。また、イニシエータではなくトランザクションのパーティシパントによって TPCOMMIT が呼び出された場合も、このエラーが発生します。
ATMI 呼び出しを正しい順序で正しく使用すると、アプリケーション・レベルでプロトコル・エラーを修正できます。
プロトコル・エラーの原因を特定するには、次の事柄を確認してください。
プロトコル・エラーでは、TP-STATUS に TPEPROTO 値が返されます。
詳細については、『BEA Tuxedo COBOL リファレンス』の「COBOL アプリケーション・トランザクション・モニタ・インターフェイスの紹介」を参照してください。
キューに関するエラー
特定のキューへの登録またはキューからの取り出しに失敗した場合、TPENQUEUE(3cbl) または TPDEQUEUE(3cbl) ルーチンは TP-STATUS に TPEDIAGNOSTIC を返します。処理が失敗した原因は、ctl レコードを介して返される診断値によって判別できます。有効な ctl フラグについては、『BEA Tuxedo COBOL リファレンス』の TPENQUEUE(3cbl) または TPDEQUEUE(3cbl) を参照してください。
リリース間の互換性に関するエラー
アプリケーション・ドメインに参加する BEA Tuxedo システムのリリース間で互換性に問題がある場合、BEA Tuxedo システムは TP-STATUS に TPERELEASE を返します。
たとえば、TPNOTIFY(3cbl) ルーチンを呼び出す際に、呼び出し元がターゲット・クライアントから承認メッセージを受け取るまでブロックすることを示す TPACK フラグが設定されている場合、ターゲット・クライアントが TPACK 承認プロトコルがサポートされていない旧バージョンの BEA Tuxedo システムを使用していると、TPERELEASE エラーが返されます。
リソース・マネージャ・エラー
リソース・マネージャ・エラーは、TPOPEN(3cbl) および TPCLOSE(3cbl) を呼び出したときに発生し、TP-STATUS に TPERMERR が返されます。リソース・マネージャを正しくオープンできなかった場合、TPOPEN でこのエラー・コードが返されます。同じように、リソース・マネージャを正しくクローズできなかった場合、TPCLOSE でこのエラー・コードが返されます。BEA Tuxedo システムでは、移植性を保つために、この種類のエラーでは詳細な情報は返されません。リソース・マネージャ・エラーの正確な内容を判断するには、リソース・マネージャに問い合わせる必要があります。
タイムアウト・エラー
BEA Tuxedo システムでは、タイムアウト・エラーがサポートされており、アプリケーションがサービス要求またはトランザクションを待つ時間に制限があります。BEA Tuxedo システムでサポートされている設定可能なタイムアウト機構は、ブロッキング・タイムアウトとトランザクション・タイムアウトの 2 種類です。
ブロッキング・タイムアウトは、アプリケーションがサービス要求に対する応答を待つ時間の上限値を指定します。アプリケーション管理者は、コンフィギュレーション・ファイルにシステムのブロッキング・タイムアウトを設定します。
トランザクション・タイムアウトは、トランザクション (サービス要求が行われる場合もあり) の有効期間を定義します。アプリケーションのトランザクション・タイムアウトを定義するには、TPBEGIN に T-OUT 引数を渡します。
通信呼び出しでは、ブロッキング・タイムアウトまたはトランザクション・タイムアウトのいずれかが返され、TPCOMMIT ではトランザクション・タイムアウトだけが返されます。いずれの場合も、トランザクション・モードのプロセスで呼び出しが失敗して TPETIME が返された場合は、トランザクション・タイムアウトが発生しています。
デフォルトでは、プロセスがトランザクション・モードではない場合、ブロッキング・タイムアウトが実行されます。
プロセスがトランザクション・モードではない場合に、非同期呼び出しでブロッキング・タイムアウトが発生すると、ブロックされている通信呼び出しは失敗します。ただし、呼び出し記述子は有効なままであり、再度呼び出しを行う場合に使用できます。ほかの通信には影響ありません。
トランザクション・タイムアウトが発生すると、非同期トランザクション応答の通信ハンドル (TPNOTRAN フラグが指定されていないもの) は無効になり、参照できなくなります。
呼び出しがトランザクション・モードで行われていない場合、または TPNOBLOCK が設定されていない場合、TPETIME は通信呼び出しでブロッキング・タイムアウトが発生したことを示します。
注記 TPNOBLOCK が設定されている場合、ブロッキング状態が存在すると呼び出しは直ちに戻るので、ブロッキング・タイムアウトは発生しません。
タイムアウト・エラーの処理の詳細については、トランザクションについてを参照してください。
トランザクション・エラー
トランザクション、および致命的なエラーと致命的ではないエラーについては、トランザクションについてを参照してください。
型付きレコードのエラー
プロセスに対する要求または応答が不明なタイプのレコードで送信された場合、型付きレコードのエラーが返されます。要求データ・レコードの送信先のサービスでレコード・タイプが認識されない場合、TPCALL および TPACALL 呼び出しは TPEITYPE を返します。
プロセスで認識されるレコード・タイプは、コンフィギュレーション・ファイルとプロセスにリンクされている BEA Tuxedo システム・ライブラリの両方で識別されるものです。これらのライブラリは、プロセスで認識される型付きレコードを識別するデータ構造体を定義および初期化します。プロセスごとにライブラリを作成するか、またはレコード・タイプが定義されたアプリケーション固有のファイルのコピーをアプリケーションで用意することができます。アプリケーションでは、レコード・タイプ・スイッチと呼ばれるレコード・タイプ・データ構造体をプロセスごとに設定できます。詳細については、『BEA Tuxedo のファイル形式とデータ記述方法』の tuxtypes(5) および typesw(5) を参照してください。
呼び出し元で認識されないか、または使用できないレコードで応答メッセージが送信されると、TPCALL および TPGETRPLY 呼び出しは TPEOTYPE を返します。呼び出し元で使用できないレコードの場合、そのレコード・タイプはタイプ・スイッチに含まれています。ただし、返されたタイプは応答の受信用に割り当てられたレコードと一致せず、また呼び出し元は異なるレコード・タイプを使用することはできません。呼び出し元は、TPNOCHANGE を設定して、このような状況を示します。その場合、厳密なタイプ・チェックが行われ、違反が見つかると TPEOTYPE が返されます。デフォルトでは、緩やかなタイプ・チェックが行われます。その場合、呼び出し元で認識される限り、最初に割り当てられたタイプ以外のレコード・タイプが返されることもあります。応答の送信では、応答レコードは呼び出し元で認識できるものでなければなりません。また、厳密なタイプ・チェックが指定されている場合は、それに従う必要があります。
アプリケーション・エラー
アプリケーション内では、TPRETURN の rcode 引数を使用して、呼び出し元のプログラムにユーザ定義のエラーに関する情報を渡すことができます。また、APPL-RETURN-CODE には、TPRETURN 時に APPL-CODE IN TPSVCRET-REC の値が設定されます。TPRETURN(3cbl) の詳細については、『BEA Tuxedo COBOL リファレンス』を参照してください。
エラー処理
アプリケーションのロジックは、戻り値がある呼び出しのエラー条件を調べ、エラー発生時に適切な処理を行うように設計します。
次のコード例は、エラーの一般的な処理方法を示しています。この例では、ATMICALL(3) は、一般的な ATMI 呼び出しを表しています。
コード リスト 11-1 エラー処理
. . .
CALL "TPINITIALIZE" USING TPINFDEF-REC
USR-DATA-REC
TPSTATUS-REC.
IF NOT TPOK
error message, EXIT PROGRAM
CALL "TPBEGIN" USING TPTRXDEF-REC
TPSTATUS-REC.
IF NOT TPOK
error message, EXIT PROGRAM
Make atmi calls
Check return values
IF TPEINVAL
DISPLAY "Invalid arguments were given."
IF TPEPROTO
DISPLAY "A call was made in an improper context."
.. .
ATMICALL(3) リファレンス・ページに説明されている
すべての場合のエラーを含めます。ほかの戻りコードは使用できません。
そのため、それらをテストする必要はありません。
.. .
(続く)
TP-STATUS の値は、各問題の詳細を示し、どのレベルで問題の解決が可能かを示しています。アプリケーションで、ある処理に特定のエラー条件が定義されている場合、APPL-RETURN-CODE IN TPSTATUS-REC の値にも同じことが言えます。
トランザクションについて
以下の節では、各種のプログラミング機能がトランザクション・モードでどのように動作するかについて説明します。まず、トランザクション・モードのコーディングで従うべき基本的な通信規則について説明します。
通信規則
トランザクション・モードで実行するコードを記述する場合は、以下の基本的な通信規則に従います。
トランザクション・エラー
以下の節では、トランザクションに関連するエラーについて説明します。
致命的ではないトランザクション・エラー
トランザクション・エラーが発生すると、TP-STATUS に TPETRAN が返されます。ただし、このようなエラーの意味は、そのエラーを返す呼び出しによって異なります。次の表は、トランザクション・エラーを返す呼び出しと、考えられるエラーの原因を示しています。
表 11-3 トランザクション・エラー
致命的なトランザクション・エラー 致命的なトランザクション・エラーが発生した場合、アプリケーションでは、イニシエータで TPABORT を呼び出してトランザクションを明示的にアボートしなければなりません。そのため、トランザクションにとって致命的なエラーを認識することが大切です。次の 3 つの場合、トランザクションは失敗します。
トランザクションにとって致命的なプロトコル・エラーが発生するのは、トランザクションの不正なパーティシパントから TPCOMMIT が呼び出された場合だけです。このエラーは、アプリケーション内で開発段階に修正できます。
イニシエータまたはパーティシパントで障害が発生した後、またはトランザクションがタイムアウトになった後で、TPCOMMIT が呼び出されると、暗黙的なアボート・エラーになります。その場合、コミットは失敗するので、トランザクションをアボートする必要があります。
通信呼び出しで TPESVCERR、TPESVCFAIL、TPEOTYPE、または TPETIME が返された場合、TPABORT を呼び出してトランザクションを明示的にアボートしなければなりません。トランザクションを明示的にアボートする前に、未処理の通信ハンドルを待つ必要はありません。ただし、これらの通信ハンドルは、呼び出しがアボートされた後は無効と見なされるので、トランザクション終了後にこれらのハンドルへのアクセスを試みると、TPEBADDESC が返されます。
TPESVCERR、TPESVCFAIL、および TPEOTYPE の場合、トランザクションがタイムアウトにならない限り、引き続き通信呼び出しを行うことができます。これらのエラーが返された場合、トランザクションは「アボートのみ」にマークされます。これ以降の処理の結果を保持するには、TPNOTRAN を設定して通信用の関数を呼び出します。このフラグを設定すると、「アボートのみ」にマークされたトランザクションで実行された処理は、トランザクションがアボートしてもロールバックされません。
トランザクション・タイムアウトが発生しても通信を続けることはできますが、次のような通信要求を行うことはできません。
したがって、非同期呼び出しを行うには、TPNOREPLY、TPNOBLOCK、または TPNOTRAN を設定する必要があります。
ヒューリスティックな判断に関するエラー
TPCOMMIT 呼び出しは、TP-COMMIT-CONTROL の設定に応じて、TPEHAZARD または TPEHEURISTIC を返します。
TP-COMMIT-CONTROL に TP-CMT-LOGGED を設定すると、2 フェーズ・コミットの第 2 フェーズの実行前にアプリケーションに制御が移ります。その場合、第 2 フェーズ中に発生したヒューリスティックな判断がアプリケーションで認識されないことがあります。
TPEHAZARD または TPEHEURISTIC は 1 フェーズ・コミットで返すことができます。ただし、これが可能なのは、トランザクションに関与しているリソース・マネージャが 1 つだけで、1 フェーズ・コミットでこのリソース・マネージャがヒューリスティックな判断を返すか、なんらかの障害の発生を示す場合です。
TP_COMMIT_CONTROL に TP_CMT_COMPLETE を設定すると、リソース・マネージャがヒューリスティックな判断を通知する場合は TPEHEURISTIC が返され、リソース・マネージャがなんらかの障害を通知する場合は TPEHAZARD が返されます。TPEHAZARD は、コミットの第 2 フェーズ (または 1 フェーズ・コミット) でパーティシパントになんらかの障害が発生し、トランザクションが正常終了したかどうかがわからない状況を示します。
トランザクション・タイムアウト
トランザクション・エラーで説明したように、BEA Tuxedo アプリケーションでは、ブロッキング・タイムアウトとトランザクション・タイムアウトの 2 種類のタイムアウトが発生します。以下の節では、各種のプログラミング機能へのトランザクション・タイムアウトの影響について説明します。タイムアウトの詳細については、トランザクション・エラーを参照してください。
TPCOMMIT 呼び出し
TPCOMMIT を呼び出した後でタイムアウトが発生した場合、トランザクションはどのような状態になるでしょうか。トランザクションがタイムアウトになり、そのトランザクションがアボートされたことがシステムで認識されると、システムは TP-STATUS に TPEABORT を設定して、そのような状況の発生を通知します。トランザクションの状態が不明な場合は、エラー・コードに TPETIME を設定します。
トランザクションの状態が明確ではない場合、リソース・マネージャに問い合わせる必要があります。まず、トランザクションによって行われた変更が適用されたかどうかを確認します。これにより、トランザクションがコミットされたか、またはアボートされたかを判断できます。
TPNOTRAN
トランザクション・モードのプロセスで、TPNOTRAN を設定して通信呼び出しを行うと、呼び出されたサービスは現在のトランザクションに参加できません。サービス要求の成功や失敗は、トランザクションの結果に影響しません。トランザクションは、サービスから応答が返されるのを待つ間にタイムアウトになる場合もあります。これは、そのサービスがトランザションに参加しているかどうかには関係ありません。
TPNOTRAN の使用方法の詳細については、TPRETURN および TPFORWAR 呼び出しを参照してください。
TPRETURN および TPFORWAR 呼び出し
トランザクション・モードで実行中にプロセスを呼び出すと、TPRETURN および TPFORWAR は、トランザクションのサービス部分をそのトランザクションの完了時にコミットまたはアボートできる状態にします。同じトランザクションでサービスを何度も呼び出すことができます。システムは、トランザクションのイニシエータによって TPCOMMIT または TPABORT が呼び出されない限り、トランザクションを完全にはコミットまたはアボートしません。
サービス内で行われた通信呼び出しのすべての未処理のハンドルが取得されるまで、TPRETURN または TPFORWAR を呼び出すことはできません。TP-RETURN-VAL に TPSUCCESS を設定して、未処理のハンドルで TPRETURN を呼び出すと、プロトコル・エラーが発生し、TPGETRPLY を待機中のプロセスに TPESVCERR が返されます。そのプロセスがトランザクション・モードになっている場合、呼び出し元は「アボートのみ」にマークされます。トランザクションのイニシエータが TPCOMMIT を呼び出した場合も、トランザクションが暗黙的にアボートされます。TP-RETURN-VAL に TPFAIL を設定して、未処理のハンドルで TPRETURN を呼び出すと、TPGETRPLY を待機中のプロセスに TPESVCFAIL が返されます。トランザクションへの影響は同じです。
トランザクション・モードで実行中に TPRETURN を呼び出すと、TPRETURN で発生したプロセス・エラー、またはアプリケーションによって TP-RETURN-VAL に設定された値で示されるエラーにより、トランザクションの結果に影響することがあります。
TPFORWAR を使用すると、ある時点までは要求が正しく処理されていることを示すことができます。アプリケーション・エラーが検出されない場合、システムは TPFORWAR を呼び出します。アプリケーション・エラーが検出された場合、システムは TPFAIL を設定して TPRETURN を呼び出します。TPFORWAR を正しく呼び出さないと、システムはその呼び出しをプロセス・エラーと見なし、エラー・メッセージを要求元に返します。
tpterm( ) 関数
TPTERM 呼び出しは、アプリケーションからクライアント・コンテキストを削除します。
クライアント・コンテキストがトランザクション・モードになっている場合、呼び出しは失敗して、TP-STATUS に TPEPROTO が返されます。クライアント・コンテキストは、トランザクション・モードでアプリケーションの一部として残ります。
呼び出しが成功すると、現在の実行スレッドはアプリケーション内に存在しなくなるため、クライアント・コンテキストは、トランザクションと通信したりトランザクションに参加できなくなります。
リソース・マネージャ
ATMI 呼び出しを使ってトランザクションを定義すると、BEA Tuxedo システムによって内部呼び出しが実行され、トランザクションに参加している各リソース・マネージャにグローバル・トランザクション情報が渡されます。TPCOMMIT や TPABORT を呼び出すと、各リソース・マネージャに対して内部呼び出しが行われ、呼び出し元のグローバル・トランザクションのために行われていた作業がコミットまたはアボートされます。
グローバル・トランザクションが開始された場合 (明示的でも暗黙的でも)、アプリケーション・コードでリソース・マネージャのトランザクション呼び出しを明示的に呼び出すことはできません。このトランザクション規則に従わないと、不安定な結果が生じます。TPGETLEV 呼び出しを使用すると、リソース・マネージャのトランザクション呼び出しを呼び出す前に、グローバル・トランザクション内に既にプロセスがあるかどうかを確認できます。
リソース・マネージャによっては、トランザクションの整合性レベルなど、特定のパラメータをプログラマが設定できるものがあります。その場合、リソース・マネージャ間のインターフェイスで使用可能なオプションを指定します。そのようなオプションは、次の 2 つの方法で使用できるようになります。
詳細については、リソース・マネージャのマニュアルを参照してください。
オプションの設定方法はリソース・マネージャによって異なります。たとえば、BEA Tuxedo システムの SQL リソース・マネージャの場合、set transaction 文を使用して、BEA Tuxedo システムによって既に開始されているトランザクションに対する特定のオプション (整合性レベルとアクセス・モード) が決まります。
トランザクションのサンプル・シナリオ
以降の節では、次のトランザクションについて説明します。
呼び出し元と同じトランザクションでのサービス呼び出し
トランザクション・モードになっている呼び出し元が、現在のトランザクションに参加するために別のサービスを呼び出した場合、次のようになります。
AUTOTRAN が設定された別のトランザクションでのサービス呼び出し
TPNOTRAN を設定して通信呼び出しを行い、呼び出されたときにトランザクションが自動的に開始するようにサービスが設定されている場合、呼び出し元プロセスと呼び出されたプロセスはどちらもトランザクション・モードになります。ただし、この 2 つは別々のトランザクションを構成します。この状況では、次の処理が行われます。
図 11-1 AUTOTRAN が設定された TPFORWAR と TPRETURN のトランザクションでの役割
新しい明示的なトランザクションを開始するサービスの呼び出し
TPNOTRAN を設定して通信呼び出しを行い、呼び出されたサービスが自動的にトランザクション・モードにならないように設定されている場合、TPBEGIN、TPCOMMIT、および TPABORT を明示的に呼び出すと、サービスで複数のトランザクションを定義できます。その結果、TPRETURN が呼び出される前にトランザクションを完了できます。
この状況では、次の処理が行われます。
BEA Tuxedo システムで提供されるサブルーチン
BEA Tuxedo システムで提供されるサブルーチン TPSVRINIT および TPSVRDONE は、トランザクションで使用される場合は特定の規則に従う必要があります。
BEA Tuxedo システム・サーバは、初期化時に TPSVRINIT を呼び出します。特に、TPSVRINIT は、呼び出し元プロセスがサーバになった後、サービス要求の処理を開始する前に呼び出されます。TPSVRINIT で非同期通信を実行した場合、関数が戻る前にすべての応答が取得されなければなりません。この処理が行われなかった場合、システムは保留中の応答があっても無視して、サーバを終了します。TPSVRINIT でトランザクションを定義した場合、関数が戻る前にすべての非同期応答を取得して、トランザクションを終了しなければなりません。この処理が行われなかった場合、システムは未処理の応答が残っていてもトランザクションをアボートし、それらの応答をすべて無視します。その場合、サーバは正常に終了します。
BEA Tuxedo システム・サーバ用ルーチンは、サービス要求の処理が完了した後、ルーチンを終了する前に TPSVRDONE を呼び出します。この時点で、サーバのサービス宣言は取り消されますが、サーバ自体はアプリケーションから分離していません。TPSVRDONE で通信を開始した場合、この関数は未処理の応答をすべて取得してから戻る必要があります。この処理が行われなかった場合、システムは保留中の応答があっても無視して、サーバを終了します。TPSVRDONE 内でトランザクションを開始した場合、トランザクションはすべての応答を取得してから終了しなければなりません。この処理が行われなかった場合、システムは応答が残っていてもトランザクションをアボートし、応答を無視します。この場合もサーバは終了します。
中央イベント・ログ
中央イベント・ログには、BEA Tuxedo アプリケーションで発生する重要なイベントが記録されます。これらのイベントに関するメッセージは、アプリケーション・クライアントとサービスが USERLOG(3cbl) ルーチンを介してログに出力されます。
中央イベント・ログの分析は、アプリケーションで行う必要があります。USERLOG(3cbl) に記録するイベントに関しては、厳密なガイドラインを定義しておきます。ほとんど問題にならないようなメッセージを記録しないようにすると、アプリケーションのデバッグが簡単になります。
Windows 2000 プラットフォームの中央イベント・ログの設定の詳細については、『Windows NT での BEA Tuxedo システムの使用』を参照してください。
ログの名前
アプリケーション管理者は、コンフィギュレーション・ファイルに、各マシン上のエラー・メッセージ・ファイル名の接頭辞として使用する絶対パス名を定義します。USERLOG(3cbl) ルーチンは、月、日、年を表す mmddyy の形式で日付を生成し、この日付をパス名の接頭辞に付加して中央イベント・ログの完全なファイル名を構成します。毎日、新しいファイルが作成されます。そのため、中央イベント・ログに数日間にわたってメッセージが送信された場合、メッセージはそれぞれ異なるファイルに書き込まれます。
ログ・エントリの形式
ログ・エントリは、次の要素から構成されます。
各メッセージの本文の前には、そのメッセージのカタログ名と番号が付きます。
たとえば、mach1 (uname コマンドから返される名前) という UNIX マシン上で、セキュリティ・プログラムが午後 4:22:14 に次のような呼び出しを行ったとします。
01 LOG-REC PIC X(15) VALUE "UNKNOWN USER ".
01 LOGREC-LEN PIC S9(9) VALUES IS 13.
CALL "USERLOG" USING LOG-REC LOGREC-LEN TPSTATUS-REC.
このログ・エントリは、次のようになります。
162214.mach1!security.23451:UNKNOWN USER
この例では、セキュリティのプロセス ID は 23451 です。
前述のメッセージが、アプリケーションではなく BEA Tuxedo システムによって生成された場合は、次のようになります。
162214.mach1!security.23451:COBAPI_CAT:999: UNKNOWN USER
この例では、メッセージのカタログ名は COBAPI_CAT、メッセージ番号は 999 です。
プロセスがトランザクション・モードのときにメッセージが中央イベント・ログに送られると、ユーザ・ログ・エントリのタグにはそのほかの要素が付加されます。これらの要素は、リテラル文字列の gtrid と、それに続く 3 桁の long 型の 16 進数で構成されます。これらの整数はグローバル・トランザクションを一意に識別するもので、グローバル・トランザクション識別子、つまり gtrid と呼ばれます。この識別子は主に管理上の目的で使用されます。また、中央イベント・ログでメッセージの前に付加されるタグの中に挿入されます。システムがトランザクション・モードで中央イベント・ログにメッセージを書き込むと、ログ・エントリは次のようになります。
162214.mach1!security.23451: gtrid x2 x24e1b803 x239:
UNKNOWN USER
イベント・ログへの書き込み
イベント・ログにメッセージを書き込むには、次の手順に従います。
01 TPSTATUS-REC.
COPY TPSTATUS.
01 LOGMSG PIC X(50).
01 LOGMSG-LEN PIC S9(9) COMP-5.
. . .
CALL "TPOPEN" USING TPSTSTUS-REC.
IF NOT TPOK
MOVE "TPSVRINIT: Cannot Open Data Base" TO LOGMSG
MOVE 43 LOGMSG-LEN
CALL "USERLOG" USING LOGMSG
LOGMSG-LEN
TPSTATUS-REC.
. . .
この例では、TPOPEN(3cbl) が -1 を返した場合、メッセージが中央イベント・ログに送られます。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
