現場で差がつくPL/I入出力術：RECORD vs STREAMの深淵を覗く
諸君、お疲れ様。今日も今日とてJCLの海を泳ぎ、VSAMの不機嫌に頭を抱えていることだろう。
PL/Iという言語は、古き良き時代の遺物のように見えて、その実、現代のJavaやPythonでは到底到達できない「ハードウェアを直接殴りに行くような制御」を可能にする、極めて実戦的な武器だ。
今日は、バッチプログラムのパフォーマンスの根幹を成す「RECORDモード」と「STREAMモード」の決定的な違いについて語ろうと思う。ここを理解していないと、数百万件のレコードを処理するバッチで、深夜に運用担当者を呼び出す羽目になるぞ。
—
1. 原理原則：なぜモードの選択が「命」なのか
PL/Iの入出力には、大きく分けて二つの流派がある。
- RECORDモード（READ/WRITE）: ファイルの「物理的構造」に直接アクセスする。VSAMのKSDSやRRDSを扱うならこれ一択だ。
- STREAMモード（GET/PUT）: データの「文字列表現」を扱う。レポート出力や、可変長のテキストファイルを読み込む際に重宝する。
多くの若手がやりがちなミスは、VSAMアクセスにSTREAMモードを使おうとすることだ。STREAMは内部で「データ変換（コンバージョン）」が走る。数値と文字の変換を繰り返せば、CPUコストは跳ね上がる。「VSAMはRECORD、帳票はSTREAM」。この鉄則を胸に刻め。
—
2. 実践コード：VSAMアクセスの標準形
まずは、RECORDモードを用いた堅牢な処理を見てみよう。ここでは`ON ENDFILE`の制御も肝だ。
/i
/ VSAMファイルからレコードを順次読み込む典型的な構造 /
MAIN_PROC: PROCEDURE OPTIONS(MAIN);
DCL VSAM_FILE FILE RECORD SEQUENTIAL INPUT;
DCL 1 INPUT_REC,
5 KEY_FLD CHAR(10),
5 DATA_FLD CHAR(90);
/ EOF（ファイル終了）時の制御フローを定義 /
ON ENDFILE(VSAM_FILE) BEGIN;
PUT SKIP LIST(‘ 処理終了：全レコードの読み込み完了 ‘);
/ 適切な終了処理へ飛ばすためのフラグ操作 /
EOF_FLAG = ‘1’B;
END;
DCL EOF_FLAG BIT(1) INIT(‘0’B);
OPEN FILE(VSAM_FILE);
DO WHILE(EOF_FLAG = ‘0’B);
READ FILE(VSAM_FILE) INTO(INPUT_REC);
IF EOF_FLAG THEN LEAVE;
/ ここにメインロジックを記述 /
/ BUILTIN関数による加工 /
IF VERIFY(INPUT_REC.KEY_FLD, ‘0123456789’) ^= 0 THEN
PUT SKIP LIST(‘エラー：数値以外のキーが含まれています’, INPUT_REC.KEY_FLD);
END;
CLOSE FILE(VSAM_FILE);
END MAIN_PROC;
現場のポイント：ONユニットの落とし穴
`ON ENDFILE`は、`READ`文が失敗した瞬間に制御を奪う。このとき、プログラムの実行状態は「不安定」になりかねない。`GOTO`でループを抜ける手法も古くからあるが、最近の保守では上記の例のように`EOF_FLAG`をフラグ管理する方が、後任者がデバッグしやすい。
—
3. STREAMモードの「隠れたコスト」
STREAMモードにおける`PUT EDIT`や`GET EDIT`は便利だ。フォーマットを意識せずとも、PL/Iが勝手にバッファと変換を管理してくれる。しかし、裏側では「内部バッファ」と「コード変換」という名の悪魔が潜んでいる。
STREAMモードは、データがバッファ内で「行単位」または「ページ単位」で組み立てられる。このため、大量のデータを吐き出す際、バッファリングが最適化されていないと、I/O待ちではなく「メモリコピー」に時間を食われる。
教訓：
大量のデータ移行でSTREAMモードを使うなら、`BUFFERED`属性を意識し、ファイル定義を最適化せよ。逆に、構造体が決まっているなら、迷わずRECORDモードで`STRUCTURE`を直接書き込め。これが一番速い。
—
4. 最後に：アーキテクトからの助言
メインフレームの保守開発において、「動けばいい」というコードは、数年後の自分自身を苦しめる時限爆弾になる。
1. BUILTIN関数を愛せ: `SUBSTR`, `VERIFY`, `INDEX`などは極めて最適化されている。自作のループで文字列を操作するのはやめろ。
2. RECORD構造を明確にしろ: `DCL 1`の構造体を整理するだけで、デバッグの効率は倍になる。
3. コンパイラが出す警告を無視するな: `W`レベルの警告は、将来の障害の予兆だ。
PL/Iは、記述すればするほどエンジニアの力量が露骨に出る言語だ。コードの裏側にある、バッファがどう動き、OSがどうI/Oを制御しているのか。常にその視点を忘れずにいてほしい。
何かあれば、またいつでも質問に来い。現場からは以上だ。
