PL/Iの深淵：RECORD I/Oにおける「BLKSIZE」最適化とバッファ管理の流儀
やあ。今日もメインフレームの迷宮でバッチジョブの解析に追われている諸君、お疲れ様。
PL/Iという言語は、古くから「何でもできるが、何でもできすぎてしまう」と言われてきた。特にRECORD I/O周りは、JCLのDCBパラメータとランタイムのバッファ管理が密接に絡み合うため、ここを理解していないとバッチの実行効率はガタ落ちだし、最悪の場合はABENDの温床になる。
今日は、現場でよく遭遇する「データセット属性（FB/VB/U）とPL/IのENVIRONMENT属性の正しい付き合い方」について、少しばかり深い話をしよう。
—
1. なぜ「予約語がない」ことがPL/Iを難しくも強力にするのか
PL/Iを触り始めた若手がまず驚くのが、「予約語が存在しない」という事実だ。例えば `IF` や `THEN` という名前の変数さえ定義できてしまう。これは自由度の極みだが、反面、コンパイラにはソース解析のオーバーヘッドが生じる。
しかし、実務で重要なのは「構文の自由さ」よりも「コンパイラが裏で何をしているか」だ。特にRECORD I/Oを行う際、`ENVIRONMENT`属性をどう指定するかで、OSのアクセス方式（QSAM/BSAM）とPL/Iランタイムのバッファリングがどう握手するか、その挙動が変わってくる。
—
2. BLKSIZEとLRECL：バッファ管理の「最適解」を探る
現場では、JCLの`BLKSIZE`を「とりあえず0（システム任せ）」にしているケースを見かけるが、大規模データセットを扱うなら、それは怠慢と言われても仕方がない。PL/I側で`ENVIRONMENT`属性を適切に指定することで、ランタイムのバッファオーバーヘッドを最小化できる。
以下のコードを見てほしい。これは固定長（FB）ファイルを効率的に読み込むための典型的なパターンだ。
/i
/ ファイル定義のベストプラクティス /
DCL IN_FILE FILE RECORD INPUT
ENVIRONMENT(
F / 固定長(Fixed)を示す /
BLKSIZE(27998) / 3390デバイスのトラック容量を考慮した値 /
RECSIZE(80) / LRECLに相当 /
BUFNO(5) / 物理I/Oを減らすためのバッファ数 /
);
DCL IN_REC CHAR(80);
/ 開く際はファイル属性を明示的に信頼する /
OPEN FILE(IN_FILE);
/ レコードの読み込みループ /
READ FILE(IN_FILE) INTO(IN_REC);
DO WHILE ( ^EOF_FLAG );
/ ここにビジネスロジックを展開する /
IF SUBSTR(IN_REC, 1, 4) = ‘DATA’ THEN DO;
/ 処理 /
END;
READ FILE(IN_FILE) INTO(IN_REC);
END;
CLOSE FILE(IN_FILE);
3. 実務で直面する「バッファ戦略」の勘所
上記の`BUFNO(5)`を見て、「なぜこんなにバッファを積むんだ？」と疑問に思うかもしれない。
実は、PL/Iのランタイムは、OSから要求されたバッファ領域を使い切ると、次のI/Oが完了するまでCPUを待機させる。バッファが一つしかなければ、処理の隙間がすべてI/O待ちになる。特にVB形式（可変長）でレコード長がバラついている場合、この待ち時間がバッチ全体のボトルネックになるんだ。
VB形式（可変長）を扱う際の注意点
VB形式で`ENVIRONMENT`を記述する場合、`RECSIZE`には最大レコード長を指定する。もしシステムが予測した以上の長さが来ると、即座に`RECORD`条件が発生し、プログラムは異常終了へ向かう。
/i
/ VB形式でのファイル定義例 /
DCL VAR_FILE FILE RECORD INPUT
ENVIRONMENT(V BUFSIZE(32760) BUFNO(10));
/ ON条件によるエラーハンドリング（保険として必須） /
ON RECORD(VAR_FILE) BEGIN;
PUT SKIP LIST(‘データ定義不整合発生：レコードが長すぎます’);
SIGNAL CONDITION(ERROR_ABEND);
END;
—
4. ベテランからのアドバイス：ONユニットとI/O制御
現場で「なぜか止まる」というコードをデバッグする際、最も多い原因は`ON ENDFILE`の使い方が中途半端なことだ。
PL/Iの`ON`ユニットは、スタックされる。ループ内で安易に`ON ENDFILE`を再定義すると、メモリリークや意図しない制御フローの遷移を招く。必ず、ファイルを開く直前に定義し、処理が終われば適切に解除するか、ブロックのスコープを意識して配置する癖をつけてほしい。
- POINT: `READ`する前に`EOF`フラグを初期化し、`READ`直後に`ENDIF`をチェックするフローを徹底せよ。
- POINT: VSAMを扱う際は、`ENVIRONMENT(VSAM)`を忘れずにつけること。これだけで、QSAMとは全く異なる、洗練されたバッファ管理アルゴリズムに切り替わる。
—
最後に
メインフレームのコードは、書いた時のロジックだけでなく、それが数年後、あるいは数十年後にどう動くかを想像して書くものだ。`ENVIRONMENT`属性の最適化は、単なるチューニングではない。それは、システムという巨大な機関車を、いかにスムーズに走らせるかという「エンジニアの美学」なんだ。
次にソースコードを開くときは、`DCL`文の一つ一つに、「なぜこの値を指定したのか」という意志を込めてみてくれ。それができるようになった時、君はもう一人前のメインフレーム・アーキテクトだ。
また何か壁にぶつかったら、いつでもここへ来なさい。深淵の先を一緒に覗いてやろう。
