05.4ABENDリカバリーを行う(ESTAE)

By 神居 - Posted: 2009/12/28 Last updated: 2009/12/28 - Leave a Comment
印刷用ページの表示 印刷用ページの表示

ESTAEは、プログラム独自のリカバリー環境を作成するためのAPIです。リカバリーとは、プログラムが異常終了する際に行われる一連の回復手順です。ESTAEを使用すれば、プログラムは異常終了の発生を受け取り、必要な診断情報を集め、必要に応じた回復処理が行えます。異常終了させずに、プログラムの実行を再開させることもできます。
同様のサービスにはSPIE/ESPIEがありますが、ESTAEはプログラム割込みに限定されず、すべての異常終了についてトラップすることができます。


ESTAEによるABENDリカバリー環境の作成

ESTAEを使用した簡単なサンプルです。メインラインの処理で何らかのABENDが発生すると、ESTAE出口ルーチン(リカバリー出口ルーチン)TRAPABNDが実行されます。SPIE/ESPIEと異なり、ABEND時のレジスターが保持されているわけではないので、呼び出された外部サブルーチンとしてのハウスキープの処理が必要です。
ABENDコードはSDWACMPCフィールドに入っています。xxxyyyの3バイトで、xxxがSYSTEM ABENDコード、yyyがUSER ABENDコードを示します。001000ならS001、000001ならU0001です。サンプルではABENDコードがS0C7の場合、ABENDせずにメインラインのラベルBADDATAから再開し、S0C7でなければ、ABENDコードとABENDしたプログラム内オフセットをメッセージ出力して、ABENDしています。

プログラムチェック割込みだけをトラップするならSPIE/ESPIEの方が簡単ですが、その他のシステムアベンドなども含めてすべての異常終了をトラップするにはESTAEを使用します。ESTAEマクロでは、リカバリー(回復)ルーチン、リカバリールーチンへ渡すパラメーター、その他のオプションを指定します。
ABENDが発生した際に制御を受けるのが、回復ルーチンです。回復ルーチンにはSDWAが渡されます。このSDWAにABEND時の詳細な情報が入っています。ABEND時や最終割込み時のPSW、レジスターの内容、プログラムアドレス、さまざまなステータス情報などです。SDWAが渡されない場合もあります。この場合、GR0に12が設定されています。GR1にはSDWAの代わりにABENDコードが、TCBCMPフィールドの内容で格納されています。
リカバリールーチンは回復可能と判断したら、リトライ(再試行)ルーチンを設定します。再試行ルーチンは、リカバリールーチンがOSに戻った後、元のプログラムを再び実行させる開始点です。呼び出されてどこかへ戻るサブルーチンではなく、プログラムの実行を継続する再開点と考えていいでしょう。再試行ルーチンを実行してABENDを回避するには、SETRPマクロに再試行ルーチンのアドレスとRC=4を指定します。レジスターに特定の値を入れて制御を渡したい場合は、SDWASRSVの対応するレジスター番号のフィールドに置き換える値を入れ、RETREGS=YESを併せて指定します。リカバリー(回復)ルーチンはABENDしたタスクの新たなIRBルーチンとして実行されますが、リトライ(再試行)ルーチンは元のプログラムのRB(PRB)で実行されます。なおSETRPマクロでDUMPパラメーターを指定することで、ダンプの採取をコントロールできます。例えABENDを回避する場合でも、調査のためにダンプを出力する場合、SETRPマクロでDUMP=YESとすれば回復時にダンプがSYSABENDあるいはSYSUDUMP DD文に定義したデータセットに出力されます。ただしMSPでは再試行の場合はダンプは採取されないので、リカバリー出口ルーチン内でSNAPマクロなどにより自分で出力しなければなりません。

一般のプログラムではESTAEを使う必要は必ずしもありませんが、OSのABENDダンプではなく、もっとプログラムに特化した独自の診断情報を集めたい場合などには便利な機能です。
空間に固有なリソース以外のシステム共通のリソースを使うプログラムの場合は、必ずESTAEでABENDをリカバリーすべきです。実際にABENDを回避せずに、異常終了するにしてもESTAEは必須と言っていいでしょう。この場合、ESTAEのリカバリー出口ルーチンは、プログラムの回復ではなく、プログラムが使用したリソースの解放のために使います。空間に固有なリソースはABENDしてもOSがクリーンアップしてくれますが、CSAなどの共通域のストレージなど、OSがクリーンアップしてくれないリソースは確保したプログラムの責任できちんと掃除をする必要があります。

サンプルでは無条件にSDWAを使用していますが、実戦で使うプログラムの場合はSDWAの有無を判別すべきです。実際にはSDWAが渡されないケースは通常ではまずなくて、リージョン内の仮想記憶がSDWAも作れないほど一杯であるような状況ぐらいと思います。私は実戦でSDWAが渡されなかった経験はありませんでした。しかし予期しない事が起きるのがソフトウェアでもありますから、実際に通ることはないであろうにしても、SDWAが提供されたかどうかは判定しなければなりません。実際にSDWAが渡されなかった場合、恐らくはその空間にとっては危機的なメモリー不足の状況でしょうから、絶対解放が必要なリソースのクリーンアップだけして、速やかにパーコレート(リトライを要求せずにOSに戻る)すればいいでしょう。

Posted in 中級編 • • Top Of Page