RETURN、STOP RUN、EXITなど、言語によって様々ですが、処理の終わりを示す命令を実行することでプログラムは終了します。プログラムの終了によって、タスクもその役割が終了します。タスクが開始するとき、ユーザープログラムが終わった後には、OSの終了処理プログラムが引き続き実行されるようになっています。ユーザープログラムが使用したメモリー領域などは確実に後始末して解放しなければならないのです。

正常終了と異常終了

終了には、正常終了（Normal Termination）と異常終了（Abnormal Termination）の2種類があります。正常終了はユーザープログラム自身によるもので、一通りの処理が終わり、最後の命令を実行することによるものです。 異常終了は、プログラムのバグ、誤ったパラメーターや入力データなどにより不正なデータを使って命令を実行したり、あるいはデバイスのI/Oエラーが発生したなどの理由から、OSによってプログラムが強制的に終了させられることを指します。また、処理の途中でエラーを見つけ、これ以上継続できないような場合、プログラムが自ら強制終了をOSに要求することもあります。異常終了はABEND「アベンド」とも呼ばれ、OSによって異常終了させられる場合がシステムアベンド、プログラムが自ら異常終了を行う場合がユーザーアベンドです。
MVSではプログラムが正常終了であっても異常終了であっても同じメカニズムで終了処理を行って資源を解放します。異常終了の場合はもちろん、正常終了であってもプログラムが使った資源を解放している保証はないからです。見た目の終わり方は違っても、内部での後始末処理としては同じ事を行う必要があります。例えば獲得したままで未返却のメモリーを解放する、OPENしたままのデータセットをCLOSEする、などです。

完了コード

プログラムは処理を終えると、呼び出し元へ戻ります。たいていの場合、処理が正しくできたかどうかを示すため、復帰コードによって通知します。EXEC文のPGMパラメーターで指定されたプログラムなど、最初に実行されるプログラムの戻り先はOSであるMVSになります。この場合の復帰コードは完了コード（CC：Completion Code）とも呼ばれ、正常終了の状態を示します。
異常終了に伴う完了コードがABENDコードです。ABENDコードは、システムアベンドではSxxx（xは16進数001～FFF）、ユーザーアベンドではUnnnn（nは10進数0000～4095）となります。このABENDコードによって異常終了の原因を判別します
OSのユーティリティなど、指定された処理が上手くできなかったときは、4、8、12など0以外の完了コードで終了します。理由をプログラムのメッセージや実行結果リスト、あるいはマニュアルなどで調べ、必要な対応行います。ただし0以外の完了コードであっても、ABENDさせられたのでなければ、OSの上ではあくまでも正常終了であるということを理解して下さい。「プログラムは正しく処理されれば0の戻りコードで終了する。したがって、0でなければ異常終了である。」と勘違いしないようにします。戻りコードが0か否かは人間から見た正常・異常の判断基準であって、MVSの判断基準ではありません。MVSは戻りコードに関係なく、ABENDの形態で終了しなければ異常終了として扱いません。したがって、戻りコードが0でなくても、ABENDしない限りは正常終了です。このことはJCLでステップを条件付きで実行するためのパラメーター、CONDなどを使うときに必要となります。

アベンド・リカバリー

回復（Recovery）は異常終了におけるフェーズの1つで、簡単に言えばABENDをなかったことにする仕組みです。特にオンライン・リアルタイム処理などでは1つのトランザクションが原因でエラーになったとしても、全体を異常終了させるわけにはいきません。また、MVS自身にエラーが発生しても、システム全体の運用に関わる重大なものでなければ、OSとしての制御を継続しなければなりません。そこでMVSでは回復機能を提供して、ソフトウェアやハードウェアにエラーが発生してもタスクがプログラムの実行を継続できるようにしています。ただし回復機能に関しては使う・使わないはプログラムで選択できます。COBOLやPL/I言語などのプログラムでは、診断やデバッグのオプション機能によって間接的に利用することになります。なお資源の後始末を行う終了処理に関しては選択の余地はなく、どんなプログラムにも適用される必須の機能です。

RTM

終了処理と回復機能を提供するのがMVSのRTM（Recovery Termination Manager）です。異常終了の場合、RTMはエラー情報を収集した上で回復が要求されているかを確認します。回復があらかじめ要求されている場合、ユーザープログラムが用意した回復ルーチン（リカバリールーチン）を呼び出します。
回復ルーチンでは、エラーとなった原因を調べ、プログラムとしてどのように処理を続けるかを決めます。オンライン処理などでは、例えばデータが悪い場合、そのトランザクションを排除して、オンライン処理そのものは引き続き行う、と言ったことが考えられます。プログラム・ロジックのエラーの場合、回復しても同じエラーが繰り返し発生する可能性があるため、回復せずに異常終了として処理させることもできます。いずれの場合でもエラーの箇所や関連するデータなどの診断情報は回復ルーチンで出力することができます。

ハードウェアに関する回復機能

高度な信頼性が求められるメインフレームでは、CPU、メモリー、チャネル、DASDなどの各種のデバイスを含め、ハードウェア自身が非常に高い品質を持ちます。その上で万一故障や誤動作が発生しても、ハードウェア自身が誤りを訂正します。訂正や修復ができない場合は障害部分を局所化し、残った正常なハードウェアで可能な限りシステムの処理を継続できるようになっています。 とは言っても、OSとしてMVSはハードウェア障害に何も関知しないわけではありません。障害部分を切り離したり、エラーの状況を記録したり、ソフトウェア面からのリカバリー処理などを行います。以下にその1部を紹介します。

機械チェック割込み

一部の入出力エラーを除き、CPU、メモリー、チャネルなどにハードウェア・エラーが起きると、ハードウェアは機械チェック割込みによってそれをMVSに通知します。これを受けてMVSはそのエラーをSYS1.LOGRECデータセットに記録することができます。ハードウェアは基本的に自身による誤りの訂正、機能の回復を行いますが、回復できない場合、MVS自身が障害となった資源を認識し、必要に応じてMVSから切り離して残りの資源での運用を継続します。

MIH（Missing Interrupt Handler）

「ミーハー」とも呼ばれているI/Oタイムアウトの監視です。入出力装置は要求されたI/Oに対して、必ず応答を返すことになっていますが、ハードウェア異常によって応答を返せなくなることもあり得ます。そこで通信処理などと同様に、決められた監視時間を超えても入出力割込みが発生しなければタイムアウトとして処理します。これによって完了しないI/Oを永遠に待ち続ける、などと言ったことが起きないようになっています。

MVSには強力な終了処理と回復の機能が実装されているおかげで、バグやエラーなどの発生で処理が中断されたときであっても、プログラムが中途半端にリソースを残したまま終わってしまっても、使用していたシステム資源は必ず解放されます。プログラムで使っていたメモリー領域、保持したままの排他制御、割り当てられたデータセットなどは、MVSによって確実に解放される仕組みになっており、ユーザープログラムがどんな状態で異常終了したとしても、元通りに戻しシステムを運転していくために、さまざまな工夫がなされています。 

次回はデータセットとレコードについてお話しします。