【実務・中級編】ENDFILE条件によるファイル読み込み終了の制御 – PL/Iの基本構文とデータ制御実践ガイド

現場で差がつく!PL/IにおけるENDFILE処理の「正解」と「罠」

やあ。今日もレガシーシステムの迷宮で、ソースコードと格闘している諸君、お疲れ様。
メインフレームの世界に足を踏み入れた若手がまず最初に躓くポイントの一つが、PL/Iにおけるファイル読み込みの制御、特に `ON ENDFILE` 条件の扱いだ。

「とりあえず動くから」と適当に書いた `ON ENDFILE` が、実はバッチ処理の異常終了(ABEND)や、データ抜け、無限ループの温床になっているケースを私は数え切れないほど見てきた。今日は、現場で後輩に「これだけは守れ」と伝えている、堅牢な実装パターンを伝授しよう。

1. なぜ「ON ENDFILE」の制御が重要なのか

PL/Iの `ON ENDFILE` は、ファイルが物理的な終端に達した瞬間に制御を奪う「例外処理」だ。ここで重要なのは、「例外」が発生した後の制御フローが、メインのループ構造と独立しているという点にある。

初心者がやりがちなのは、`ON` ユニット内で強引に `GO TO` でループを抜け出そうとしたり、フラグの更新順序を間違えて最後の1レコードを処理し損ねたりすることだ。基幹システムのバッチでは、1件のデータロスも許されない。だからこそ、処理の「終い方」はスマートかつ確実でなければならない。

2. 実践的コーディング・パターン

以下に、VSAMファイルや順次ファイルを読み込む際の標準的なテンプレートを提示する。ポイントは、フラグ管理を徹底し、`SIGNAL` 文や `GO TO` に頼りすぎない構造にすることだ。

/i
/——————————————————————-/
/ プログラム名: SAMPLE_BATCH_READ /
/ 機能: 入力ファイルからレコードを読み込み、処理を行う /
/——————————————————————-/
SAMPLE_PROC: PROC OPTIONS(MAIN);

DCL IN_FILE FILE RECORD INPUT ENV(VSAM);
DCL EOF_FLG BIT(1) INIT(‘0’B); / 終了判定用フラグ /
DCL REC_AREA CHAR(100); / レコード受取領域 /

/ ENDFILEユニットの定義:フラグを立てて終了を通知する /
ON ENDFILE(IN_FILE) BEGIN;
EOF_FLG = ‘1’B;
END;

OPEN FILE(IN_FILE);

/ 最初の読み込み /
READ FILE(IN_FILE) INTO(REC_AREA);

/ 読み込みループ /
DO WHILE(^EOF_FLG);

/ ここにメインのロジックを記述 /
CALL PROCESS_RECORD(REC_AREA);

/ 次のレコードを読み込む /
READ FILE(IN_FILE) INTO(REC_AREA);
END;

CLOSE FILE(IN_FILE);

PUT SKIP LIST(‘バッチ処理が正常に終了しました’);

/ 内部サブプロシージャ /
PROCESS_RECORD: PROC(P_REC);
DCL P_REC CHAR(100) PARM;
/ 何らかのデータ変換・集計処理 /
END PROCESS_RECORD;

END SAMPLE_PROC;

3. ベテランが教える「現場の注意点」

① ONユニットの有効範囲を意識せよ

`ON ENDFILE` は宣言された箇所からブロック終了まで有効だが、サブルーチンを多用する場合、意図しない場所で条件が拾われないか注意が必要だ。原則として、ファイルを開く直前、あるいは `MAIN` プロシージャの冒頭で定義するのが最も安全だ。

② 「読み込み」と「フラグ」の順序

コード例を見て気づいたかもしれないが、`READ` をループの「前」と「中」に記述するこのパターン(先行読み込み)は、PL/Iにおける定石だ。これにより、`ON ENDFILE` が発生した瞬間にループ条件 `WHILE(^EOF_FLG)` が評価され、無駄な処理を走らせることなくクリーンに終了できる。

③ VSAM特有の注意

VSAMファイルの場合、ファイル状態(File Status)によるエラーハンドリングと `ENDFILE` を混同してはいけない。`ENDFILE` はあくまで物理的な終端。ファイルオープン失敗や、読み込み時の物理エラーは `ON ERROR` や `ON UNDEFINEDFILE` で別途制御する必要がある。これらを一緒くたに `ON ANY` で括るような怠惰なコーディングは、デバッグの際に地獄を見るぞ。

最後に

メインフレームのコードは、時に古臭く見えるかもしれない。しかし、この「きっちりとした例外制御」は、24時間365日止まらない基幹システムを支えるための、先人たちの知恵の結晶だ。

もし諸君が今、既存のスパゲッティコードの改修に挑んでいるなら、まずはこの「フラグを用いたクリーンな終了パターン」にリファクタリングすることから始めてみてほしい。コードが整理されれば、必ずバグの隠れ場所は減る。

何か困ったことがあれば、またいつでも聞いてくれ。現場からは以上だ。

タイトルとURLをコピーしました