世界最高峰のIBMメインフレームシステムアーキテクトとして、PL/Iの奥深さと、それが基幹システムの堅牢性をいかに支えてきたかについて語ることは、私にとって至上の喜びです。今回は、ファイル処理の終着点である`ENDFILE`条件に焦点を当て、そのONユニットが持つ意味、そして現場で遭遇しうるエッジケースやトラブルシューティングについて、私の経験と深い知見を交えながら解説していきましょう。
—
PL/IにおけるENDFILE条件とONユニット：基幹システムを支える堅牢な終了処理の極意
序章：ファイル終端は単なる終わりではない
基幹システムの夜間バッチ処理において、ファイル処理はまさにプログラムの血流です。日次、月次で膨大な量のデータファイルを読み込み、加工し、出力する。この一連の作業が滞りなく、そして正確に実行されることがシステムの生命線と言えるでしょう。
その中で、ファイル読み込みの「終わり」を示す`ENDFILE`条件は、単なる終端チェック以上の意味を持ちます。それは、プログラムが安全かつ確実に、それまでの処理を締めくくり、次のステップへと移行するための重要なチェックポイントであり、ときに「穏やかな死」を迎えるための儀式とも言えます。しかし、この「穏やかな死」の処理を誤れば、システム全体を巻き込むような致命的なエラー、すなわちABENDへと繋がりかねません。
PL/Iの`ON ENDFILE`ユニットは、この重要な局面をプログラマが意図した通りに制御するための強力なメカニズムです。今回は、その基本から、動的メモリ操作、コンパイラ最適化の妙、ABEND解析、そしてレガシー移行における注意点まで、深掘りしていきます。
PL/Iプログラムの基本構造とENDFILE条件の定石
まず、PL/Iにおける`ON ENDFILE`の基本を確認しましょう。
PL/Iのプログラムは、通常、`PACKAGE`や`PROCEDURE`を単位として構成されます。特にメインプログラムは`PROCEDURE OPTIONS(MAIN)`で定義され、その中で様々な処理が展開されます。
SAMPLE: PROCEDURE OPTIONS(MAIN);
/ —————————————————– /
/ ファイル定義 /
/ —————————————————– /
DECLARE INPUT_FILE FILE INPUT SEQUENTIAL BUFFERED RECORD;
DECLARE OUTPUT_FILE FILE OUTPUT SEQUENTIAL BUFFERED RECORD;
/ —————————————————– /
/ 読み込みレコードの定義 /
/ —————————————————– /
DECLARE 1 INPUT_RECORD,
2 FIELD_A CHAR(10),
2 FIELD_B FIXED BINARY(31);
/ —————————————————– /
/ ENDFILE条件のONユニット定義 /
/ —————————————————– /
ON ENDFILE(INPUT_FILE) BEGIN;
PUT SKIP LIST(‘INFO: INPUT_FILEの終端に到達しました。’);
CLOSE FILE(INPUT_FILE);
CLOSE FILE(OUTPUT_FILE);
GO TO END_PROGRAM; / 終了処理ラベルへジャンプ /
END;
/ —————————————————– /
/ ファイルオープン /
/ —————————————————– /
OPEN FILE(INPUT_FILE);
OPEN FILE(OUTPUT_FILE);
/ —————————————————– /
/ メイン処理ループ /
/ —————————————————– /
MAIN_LOOP: DO FOREVER;
READ FILE(INPUT_FILE) INTO(INPUT_RECORD);
/ ————————————————- /
/ ここにレコード処理ロジックを記述 /
/ 例えば、INPUT_RECORDの内容を加工してOUTPUT_FILEへ出力 /
/ ————————————————- /
WRITE FILE(OUTPUT_FILE) FROM(INPUT_RECORD); / 例としてそのまま出力 /
END;
END_PROGRAM:;
PUT SKIP LIST(‘INFO: プログラム処理を終了します。’);
RETURN;
END SAMPLE;
このコードの肝は、`ON ENDFILE(INPUT_FILE) BEGIN; … END;` のブロックです。これは、`INPUT_FILE`から`READ`を試み、そのファイルが既に終端に達していた場合に、PL/Iランタイムが自動的にこのブロック内の処理を実行することを保証します。従来の言語で見られるような、レコード読み込み後に戻りコードをチェックし、`IF`文で終端を判定して`GO TO`で処理を分岐させる、といった冗長な記述は不要です。PL/IのONユニットは、まさにイベントドリブンな例外処理の先駆けであり、プログラムの可読性と堅牢性を大幅に向上させます。
このユニット内で、通常はオープンしているファイルのクローズ処理や、その他の後処理（例えばデータベースのコミットや、集計結果の出力など）を実行し、最終的にプログラムの終了ラベルへジャンプ（`GO TO END_PROGRAM;`）することで、メインループから安全に脱出します。
ENDFILE条件処理の深化：動的メモリと複数ファイルへの配慮
単一のファイル処理であれば上記の基本で事足りますが、基幹システムにおいては、より複雑な状況が日常茶飯事です。
ベース変数とポインタを用いた動的メモリ操作との連携
大量のデータを扱う際、固定長のレコードバッファではメモリ効率が悪化したり、時にはオーバーフローのリスクを抱えたりします。このような場合、PL/Iの`BASED`変数と`POINTER`を用いた動的メモリ操作が非常に有効です。
SAMPLE_DYNAMIC: PROCEDURE OPTIONS(MAIN);
DECLARE INPUT_FILE FILE INPUT SEQUENTIAL BUFFERED RECORD;
DECLARE OUTPUT_FILE FILE OUTPUT SEQUENTIAL BUFFERED RECORD;
/ —————————————————– /
/ ベース変数とポインタの定義 /
/ —————————————————– /
DECLARE 1 DYNAMIC_RECORD BASED(RECORD_PTR), / ポインタRECORD_PTRに基底を持つレコード構造 /
2 FIELD_X CHAR(20),
2 FIELD_Y FIXED DECIMAL(15,0);
DECLARE RECORD_PTR POINTER; / レコードを指すポインタ /
DECLARE PREV_RECORD_PTR POINTER; / 前のレコードを指すポインタ (連結リストを想定) /
/ —————————————————– /
/ ENDFILE条件のONユニット定義 /
/ 動的メモリ解放処理を追加 /
/ —————————————————– /
ON ENDFILE(INPUT_FILE) BEGIN;
PUT SKIP LIST(‘INFO: INPUT_FILEの終端に到達しました。動的メモリ解放処理を開始します。’);
/ 連結リストを遡ってメモリを解放する例 /
DO WHILE(PREV_RECORD_PTR ^= NULL); / PREV_RECORD_PTRがNULLでない間繰り返す /
RECORD_PTR = PREV_RECORD_PTR; / 現在のポインタをPREV_RECORD_PTRに設定 /
PREV_RECORD_PTR = DYNAMIC_RECORD.PREV_PTR_FIELD; / 次の解放対象をPREV_PTR_FIELDから取得 /
FREE RECORD_PTR->DYNAMIC_RECORD; / 動的メモリを解放 /
END;
/ または、単純に最後のALLOCATEされた領域のみ解放するなら下記 /
IF RECORD_PTR ^= NULL THEN
FREE RECORD_PTR->DYNAMIC_RECORD; / 最後にALLOCATEした領域を解放 /
RECORD_PTR = NULL; / 解放後はポインタをNULLに設定することが非常に重要 /
CLOSE FILE(INPUT_FILE);
CLOSE FILE(OUTPUT_FILE);
GO TO END_PROGRAM_DYNAMIC;
END;
/ —————————————————– /
/ ファイルオープン /
/ —————————————————– /
OPEN FILE(INPUT_FILE);
OPEN FILE(OUTPUT_FILE);
/ —————————————————– /
/ メイン処理ループ (動的メモリ確保の例) /
/ —————————————————– /
MAIN_LOOP_DYNAMIC: DO FOREVER;
ALLOCATE DYNAMIC_RECORD; / 新しいレコード領域を動的に確保 /
READ FILE(INPUT_FILE) INTO(RECORD_PTR->DYNAMIC_RECORD); / 確保した領域に直接読み込み /
/ ————————————————- /
/ ここにレコード処理ロジックを記述 /
/ ————————————————- /
WRITE FILE(OUTPUT_FILE) FROM(RECORD_PTR->DYNAMIC_RECORD); / 加工後データを出力 /
/ 処理済みレコードのポインタを保持する (連結リスト構築の例) /
/ DYNAMIC_RECORD.PREV_PTR_FIELD = PREV_RECORD_PTR; /
/ PREV_RECORD_PTR = RECORD_PTR; /
END;
END_PROGRAM_DYNAMIC:;
PUT SKIP LIST(‘INFO: 動的メモリ処理プログラムを終了します。’);
RETURN;
END SAMPLE_DYNAMIC;
考察とトラブルシューティング:
- メモリリークの危険: `ENDFILE`条件発生時に`ALLOCATE`したメモリを`FREE`し忘れると、それはそのままメモリリークとなり、プログラムが確保したメモリ領域が解放されずに残存します。短時間のバッチでは問題にならないこともありますが、長時間稼働するプログラムや、`GETMAIN`を繰り返し行うプログラムでは、最終的にOSからのメモリ割り当て要求が失敗し、`GETMAIN`エラー（多くの場合`S878`や`S40D`などのABEND）を引き起こします。
- ダングリングポインタ: `FREE`した後もポインタが解放済みの領域を指し続けている状態を「ダングリングポインタ」と呼びます。解放済みの領域にアクセスしようとすると、不正な記憶域アクセス（`S0C4` ABENDなど）が発生する可能性があります。`FREE`後は必ず`RECORD_PTR = NULL;`のようにポインタを無効化することが重要です。
複数ファイル処理とONユニットのスタック
複数の入力ファイルを処理する場合、それぞれのファイルに対して`ON ENDFILE`ユニットを定義する必要があります。ここで注意すべきは、`ON`ユニットはスタック構造で管理されるという点です。
SAMPLE_MULTI_FILE: PROCEDURE OPTIONS(MAIN);
DECLARE FILE_A FILE INPUT SEQUENTIAL;
DECLARE FILE_B FILE INPUT SEQUENTIAL;
DECLARE REC_A CHAR(80);
DECLARE REC_B CHAR(80);
/ ファイルAのENDFILEユニット /
ON ENDFILE(FILE_A) BEGIN;
PUT SKIP LIST(‘INFO: FILE_Aの終端に到達。’);
CLOSE FILE(FILE_A);
GO TO CHECK_FILE_B; / 次のファイル処理へ /
END;
OPEN FILE(FILE_A);
MAIN_LOOP_A: DO FOREVER;
READ FILE(FILE_A) INTO(REC_A);
/ FILE_Aの処理 /
PUT SKIP LIST(‘FILE_A:’ || REC_A);
END;
CHECK_FILE_B:;
/ ファイルBのENDFILEユニット (新しいONユニットがスタックに乗る) /
ON ENDFILE(FILE_B) BEGIN;
PUT SKIP LIST(‘INFO: FILE_Bの終端に到達。’);
CLOSE FILE(FILE_B);
GO TO END_PROGRAM_MULTI;
END;
OPEN FILE(FILE_B);
MAIN_LOOP_B: DO FOREVER;
READ FILE(FILE_B) INTO(REC_B);
/ FILE_Bの処理 /
PUT SKIP LIST(‘FILE_B:’ || REC_B);
END;
END_PROGRAM_MULTI:;
PUT SKIP LIST(‘INFO: 全ファイル処理を終了します。’);
RETURN;
END SAMPLE_MULTI_FILE;
この例では、`FILE_A`の`ENDFILE`が発生した後に`FILE_B`の処理に移ります。この際、`FILE_A`の`ON ENDFILE`ユニットはアクティブなままですが、`FILE_B`に対する`ON ENDFILE`ユニットが新たに設定され、それが優先されます。もし`FILE_B`の処理中に誤って`FILE_A`に対して`READ`を試み、`FILE_A`が終端に達していた場合、最初に定義した`FILE_A`の`ON ENDFILE`ユニットが再び起動します。
`BEGIN…END`ブロック内で`ON`ユニットを定義すると、そのブロックのスコープ内でのみ有効となり、ブロックを抜けると元の`ON`ユニットが復元されます。これを理解しておかないと、予期せぬ`ON`ユニットが起動したり、逆に必要な`ON`ユニットが失われたりする可能性があります。
コンパイラオプションと最適化の影
PL/Iのコンパイラは、長年の進化の中で非常に洗練されてきました。特に`OPTIMIZE`オプションは、生成されるコードの実行効率を劇的に向上させます。しかし、その強力な最適化が、我々が想定するプログラムの挙動と微妙に異なる結果をもたらすことがあります。
`ENDFILE`条件のようなONユニットは、通常、I/O処理の際にランタイムが介入するポイントで確実に捕捉されます。しかし、極端な最適化が行われた場合、特にI/Oバッファリングや先行読み込み（Read-ahead）の挙動が複雑に絡み合うと、`ENDFILE`条件が捕捉されるタイミングが、ソースコード上の`READ`文の直後ではない可能性もゼロではありません。これは非常に稀なケースですが、パフォーマンス上の問題で`OPTIMIZE(3)`のような高レベルの最適化を適用する際には、デバッグモード（`TEST`オプション）で詳細な動作を確認することが推奨されます。
また、`CHECK`や`NOCHECK`のようなオプションも、デバッグ時の挙動に影響を与えます。`CHECK(CONVERSION, SIZE)`などが有効な場合、`ENDFILE`処理中に不正なデータ変換が発生すれば、即座に条件が捕捉され、デバッグが容易になります。本番環境では`NOCHECK`で実行効率を優先することが多いですが、問題発生時のトレーサビリティを考慮した設計が必要です。
アベンド（ABEND）発生時のダンプ解析とENDFILE処理
`ENDFILE`処理はプログラムの「穏やかな死」の儀式であると述べましたが、この儀式の中でエラーが発生すると、プログラムは「突然の死」、すなわちABENDを迎えることになります。
例えば、`ON ENDFILE`ユニット内で、クローズしようとしたファイルが既にクローズ済みであったり、動的に確保したメモリを誤って二重解放しようとしたり、あるいはデータベースのコミット処理でエラーが発生したりした場合、ABENDに直結する可能性があります。
ダンプ解析のポイント:
1. システムアベンドコード (System Completion Code): `S0C1`, `S0C4`, `S0C7`, `S878` など。`S0C4`は保護された記憶域へのアクセス違反、`S0C7`は数値データのフォーマット不正（パックデシマルやゾーンデシマルで非数値文字が含まれる）、`S878`はGETMAINエラー（メモリ不足）など、それぞれのコードがABENDのタイプを示唆します。
2. ユーザーアベンドコード (User Completion Code): `Uxxxx`形式のコード。PL/Iプログラム内で明示的に`CALL PLIDUMP(…)`や`CALL PLIXIT(‘Uxxxx’)`などを用いてABENDを発生させた場合に表示されます。
3. PSW (Program Status Word): ダンプの最上部付近に表示される`PSW`は、ABEND発生時の命令アドレス（`Instruction Address`）を含んでいます。このアドレスをロードモジュールマップと照合することで、どのPL/I文でABENDが発生したかを特定できます。
4. 汎用レジスタ (General Registers: GRs): `GR0`から`GR15`までのレジスタの値も重要です。特に`GR13`は`SAVE AREA POINTER`、`GR14`は`RETURN ADDRESS`、`GR15`は`ENTRY ADDRESS`を示すことが多く、呼び出し階層やエラー発生時の文脈を理解する上で不可欠です。
5. CEEDUMP: PL/Iのランタイム環境であるLanguage Environment (LE) が生成する`CEEDUMP`は、ABEND発生時のPL/Iスタックトレースや変数情報を出力してくれるため、原因特定に極めて有効です。`CEEDUMP`を解析することで、どの`PROCEDURE`のどの行でエラーが発生したかを、ソースコードレベルで特定できることが多々あります。
ダンプ解析は、まるで法医学者が現場に残された痕跡を辿るようなものです。PSWの0番目から8番目のビットが指し示す割り込みコードは、PL/Iプログラムがなぜその瞬間に息絶えたのかを雄弁に物語ってくれるでしょう。`ENDFILE`処理中のABENDは、しばしば後処理の不備や、その時点で参照されるべきではないデータへのアクセスが原因で発生します。
基幹システムにおけるエッジケースと罠
`ENDFILE`条件の範疇を少し超えるかもしれませんが、基幹システムの現場で遭遇する、ファイル処理やデータハンドリングにまつわる典型的なエッジケースにも触れておきましょう。
パックデシマル（Packed Decimal）の内部符号反転バグ
これは`ENDFILE`条件とは直接関係ありませんが、ファイル終端処理でよく遭遇する問題の一つです。特に外部システムから受け取ったファイルで発生しやすい現象です。
PL/Iの`FIXED DECIMAL`型、特にパックデシマル（`COMP-3`）形式では、数値の最下位バイトの右半分（下位4ビット）に符号ビットが格納されます。正数ならば`X’C’`、負数ならば`X’D’`、符号なしならば`X’F’`が一般的です。
しかし、稀にデータ入力のミスやシステム間の連携バグにより、この符号ビットが不正な値（例えば`X’F’`だったはずが`X’C’`に化ける、あるいは全く関係ない文字が入る）になることがあります。
例えば、最終レコードの金額フィールドが`’12345F’`であるべきところが、`’12345B’`（`X’B’`は符号として不正）のようになってしまうと、そのデータを`FIXED DECIMAL`変数に`READ`した途端、`S0C7` ABENDが発生します。`ON CONVERSION`条件を設定していても、数値変換の段階でエラーになるため、`ENDFILE`処理に入る前にプログラムが停止してしまうこともあります。
このような事態を防ぐためには、入力ファイルのデータクレンジングや厳密なバリデーションが不可欠です。特に、他システムからの連携ファイルでは、想定外のデータが混入する可能性を常に考慮し、`PICTURE`句を使った入力チェックや、`ON CONVERSION`ユニットでのきめ細かいエラーハンドリングを設計に盛り込むべきです。
埋め込みSQL (DB2) やCICSオンライン処理への応用
`ENDFILE`は主にシーケンシャルファイル処理の終端を扱うものですが、その背後にある「イベントドリブンな例外処理」という思想は、他の基幹システムコンポーネントにも共通して見られます。
- DB2 (埋め込みSQL):
DB2のカーソル処理において、データの終端に達すると`SQLCODE`が`+100`を返します。これはファイル処理における`ENDFILE`に非常に似ています。PL/Iプログラムでは`EXEC SQL WHENEVER NOT FOUND GO TO END_CURSOR;`のような`WHENEVER`文を用いて、`ENDFILE`と同様に宣言的に例外処理を記述します。`COMMIT`や`ROLLBACK`といったトランザクション制御と密接に連携し、ファイル処理以上の厳密な整合性が求められます。
- CICSオンライン処理:
CICS環境では、`HANDLE CONDITION`というメカニズムが存在します。例えば、`EXEC CICS HANDLE CONDITION ENDFILE(END_OF_BROWSE)`のように記述し、ファイルブラウズ（探索）の終端に達した場合に指定されたラベルへジャンプさせます。ただし、CICSの`HANDLE CONDITION`は`GO TO`ベースであり、PL/Iの`ON`ユニットのようにスタックで管理されるわけではないため、制御のフローにはより注意が必要です。エラーハンドリングも`RESP`値をチェックする形で、より細かく制御することが可能です。
ファイル処理の`ENDFILE`条件は、言わばバッチ処理における「穏やかな死」の迎え方です。しかし、DB2の`SQLCODE`やCICSの`HANDLE CONDITION`は、より切迫した「緊急事態」への対処を求められます。根本にある例外処理の哲学は同じですが、各環境の特性を深く理解し、それに応じた堅牢な設計を行うことが、基幹システムを安定稼働させる上で不可欠なのです。
まとめ：ENDFILEはプログラムの命運を握る
`ENDFILE`条件のONユニットは、PL/Iプログラムが安全に、そして確実にその責務を全うするための重要なメカニズムです。単にファイル終端を検出するだけでなく、その発生タイミングで実行されるべき後処理（ファイルのクローズ、動的メモリの解放、DBのコミット、ログ出力など）を確実に実行させることで、プログラムの堅牢性を担保します。
現代のレガシー移行プロジェクトにおいては、この`ENDFILE`条件の挙動が、移行先言語（JavaやC#など）で正確に再現されるかどうかが非常に重要になります。PL/IのONユニットが持つイベントドリブンな特性は、他の言語のtry-catch-finallyブロックや、特定の例外ハンドラにマッピングされることが多いですが、バッファリングやコンパイラ最適化による微妙な挙動の違いが、移行後のシステムで思わぬ不具合を引き起こす可能性も孕んでいます。
したがって、レガシー移行のシステムアーキテクトは、PL/Iの`ENDFILE`条件が「いつ」「どのような状況で」「どのような順序で」発火し、そのONユニット内で何が実行されているのかを、ソースコード、コンパイラリスト、そして時にはダンプを読み解きながら、深く理解しておく必要があります。それは、単なる言語仕様の理解を超え、汎用機のアーキテクチャとランタイムの挙動を極め尽くした者だけが到達できる境地と言えるでしょう。
基幹システムを支える我々にとって、この`ENDFILE`条件の奥深さを理解し、適切に利用することは、システムの信頼性と安定性を守るための、まさに「極意」なのです。
