【テクニカル・上級編】BUFFERED属性によるI/O効率化とバッファ管理 – PL/Iの基本構文とデータ制御実践ガイド

PL/IのBUFFERED属性：基幹システムにおけるI/O効率化の真髄と移行への示唆

基幹システムの心臓部で長年脈打ってきたPL/I。その洗練された言語仕様は、現代のシステムアーキテクトにとっても、レガシー移行という過酷なミッションを遂行する上で、無視できない数々の知見を秘めています。特に、ファイルI/Oの効率化に深く関わる`BUFFERED`属性の理解は、パフォーマンスチューニングの要であり、移行時のリスクを低減させるための鍵となります。今回は、この`BUFFERED`属性に焦点を当て、そのメカニズム、実務での活用、そして将来の移行を見据えた深い洞察を、現場のリアルを交えながら語り尽くしましょう。

1. `BUFFERED`属性：なぜ、そしてどのようにI/Oを効率化するのか

まず、`BUFFERED`属性とは何でしょうか。これは、PL/Iの`FILE`定義において、レコードの入出力処理をどのように行うかを指定するものです。対義語は`UNBUFFERED`属性です。

`UNBUFFERED`: データを読み書きする際に、プログラムが要求したタイミングで直接、物理的なI/Oデバイス（ディスクやテープ）との間でデータの移動を行います。これは、例えば`GET`文でデータを読み取ろうとしたら、すぐにディスクから1レコード分がメモリにロードされる、といった動作です。シンプルですが、I/O操作は比較的コストが高い処理であるため、頻繁にI/Oが発生するとシステム全体のパフォーマンスを著しく低下させる可能性があります。特に、大量のレコードを逐次処理するバッチ処理などでは、この「I/O待ち」がボトルネックとなりがちです。

`BUFFERED`: こちらは、プログラムと物理I/Oデバイスの間に「バッファ」と呼ばれるメモリ領域を設けます。
読み込み時: プログラムが`GET`文でデータを要求しても、すぐにディスクから読み込むわけではありません。まず、バッファに空きがあれば、ディスクから一定量のデータ（通常はブロックサイズ分）をまとめてバッファに読み込みます。プログラムは、このバッファからデータを取得します。バッファが空になった場合にのみ、次のブロックがディスクから読み込まれます。
書き込み時: プログラムが`PUT`文でデータを書き込んでも、すぐにディスクに書き込まれるわけではありません。データはまずバッファに格納されます。バッファがいっぱいになったり、ファイルがクローズされたり、あるいは明示的にフラッシュ操作（後述）が行われたりしたタイミングで、バッファの内容がまとめてディスクに書き出されます。

この`BUFFERED`属性の肝は、「まとめて読み書きする」という点にあります。ディスクI/Oは、CPU処理に比べて非常に遅い処理です。`UNBUFFERED`では、1レコード読み込むたびにディスクアクセスが発生する可能性がありますが、`BUFFERED`では、1ブロック（例えば4KBや8KB）まとめて読み書きすることで、I/O回数を劇的に削減できます。これにより、CPUはI/O待ちでアイドル状態になる時間を減らし、より多くの処理を実行できるようになります。結果として、物理的なI/O回数が減少し、システム全体の処理速度が向上するのです。

しかし、これにはトレードオフも存在します。バッファリングのために追加のメモリ消費が発生するということです。基幹システムでは、メモリリソースは貴重な資源であり、無計画なバッファリングはメモリ枯渇のリスクを高めます。しかし、適切に設計された`BUFFERED`ファイルは、I/O性能の向上という見返りにより、そのメモリ消費を大きく上回るメリットをもたらします。

2. 実践：`BUFFERED`属性を活かすPL/Iコード例

では、具体的なPL/Iコードで、`BUFFERED`属性の指定と、それを用いたI/O処理を見てみましょう。

FILE: EMPLOYEE.DAT
DESCRIPTION: 従業員データを格納するファイル
レコード長: 100バイト
ブロックサイズ: 4096バイト (例)

/
EMPLOYEE_FILE: PROCEDURE OPTIONS(MAIN);

DCL IN_FILE FILE RECORD SEQUENTIAL
ENV(FBA BLKSIZE(4096))
BUFFERED; / ここでBUFFERED属性を指定 /

DCL 1 EMPLOYEE_RECORD,
2 EMP_ID PIC(9) COMP3, / 従業員ID (パック10進数) /
2 EMP_NAME PIC(50) VARYING, / 従業員名 /
2 EMP_DEPT PIC(10) CHAR, / 所属部署 /
2 FILLER PIC(35) CHAR; / 残り部分 /

DCL EOF_FLAG BIT(1) INIT(‘0’B); / ファイル終端フラグ /

/ ファイルオープン /
OPEN FILE(IN_FILE) INPUT;

/ ファイル終端までレコードを読み込む /
DO WHILE (EOF_FLAG = ‘0’B);
/ 読み込み処理 /
/ 読み込み要求時、バッファにデータがあればそれを返し、

なければディスクからブロック単位でバッファへ読み込む。
物理I/Oはバッファが空になった時のみ発生するため効率的。

/
READ FILE(IN_FILE) INTO(EMPLOYEE_RECORD) IGNORE(0);

/ READ文でEOFに達した場合、システムはEOF_FLAGを’1’Bに設定する。

このチェックはREAD文の直後に行われる。

/
IF AT(IN_FILE) THEN
EOF_FLAG = ‘1’B;
ELSE
/ 読み込んだレコードに対する処理 (例: 名前を表示) /
PUT SKIP LIST(‘Employee Name: ‘ || SUBSTR(EMP_NAME, 1, LENGTH(EMP_NAME)));
END;
END;

/ ファイルクローズ /
CLOSE FILE(IN_FILE);

PUT SKIP LIST(‘End of processing.’);

RETURN;

END EMPLOYEE_FILE;

この例では、`IN_FILE`を`BUFFERED`属性で定義しています。`READ`文でレコードを読み込むたびに、必ずしもディスクアクセスが発生するわけではありません。OSのI/Oサブシステムが、ディスクから読み込んだブロックをメモリ上のバッファに保持し、プログラムからの要求に応じてバッファからデータを返します。バッファが空になった場合にのみ、次のブロックがディスクから読み込まれます。これにより、レコード数が多い場合でも、ディスクアクセス回数を大幅に削減できるのです。

逆に、書き込み処理でも`PUT`文の度にディスクに書き込まれるのではなく、バッファがいっぱいになるまでメモリ上で保持されます。

3. `BUFFERED`属性と動的メモリ操作・ポインタ

PL/Iの強力な機能の一つに、ベース変数とポインタを用いた動的なメモリ操作があります。`BUFFERED`属性とこれらを組み合わせることで、さらに高度なI/O制御が可能になります。

例えば、ファイルから読み込んだデータを、そのまま別のファイルに書き込むのではなく、メモリ上で加工してから書き込みたい場合を考えてみましょう。`BUFFERED`ファイルから読み込んだデータは、まずバッファに格納されます。プログラムはこのバッファの内容を直接操作することはできませんが、`GET`文でレコード単位で変数に読み込んだ後、その変数をポインタで参照し、必要に応じてメモリ上のデータを操作することができます。

DCL IN_FILE FILE RECORD SEQUENTIAL BUFFERED ENV(FBA BLKSIZE(4096));
DCL OUT_FILE FILE RECORD SEQUENTIAL BUFFERED ENV(FBA BLKSIZE(4096));

DCL IN_RECORD_BUFFER CHAR(100); / 読み込み用バッファ /
DCL OUT_RECORD_BUFFER CHAR(100); / 書き込み用バッファ /

DCL IN_RECORD_PTR POINTER; / 読み込みバッファへのポインタ /
DCL OUT_RECORD_PTR POINTER; / 書き込みバッファへのポインタ /

/ ファイルオープン /
OPEN FILE(IN_FILE) INPUT;
OPEN FILE(OUT_FILE) OUTPUT;

/ ポインタをバッファにセット /
IN_RECORD_PTR = ADDR(IN_RECORD_BUFFER);
OUT_RECORD_PTR = ADDR(OUT_RECORD_BUFFER);

DO WHILE (…); / ファイル終端までループ /
READ FILE(IN_FILE) INTO(IN_RECORD_BUFFER);

/ 読み込んだデータを加工 (例: 特定のフィールドをクリア) /
/ ポインタを使ってメモリ上のデータを直接操作 /
/ SUBSTR関数などでも可能だが、ポインタはより低レベルな操作を可能にする /
/ 例: EMP_NAMEフィールド (バイト10から60) をクリア /
CALL SET_FIELD_TO_BLANKS(IN_RECORD_PTR, 10, 50); / 仮のサブルーチン /

/ 加工したデータを別のバッファにコピー /
OUT_RECORD_BUFFER = IN_RECORD_BUFFER;

/ 加工済みのデータを書き込み /
PUT FILE(OUT_FILE) DATA(OUT_RECORD_BUFFER);

END;

/ ファイルクローズ /
CLOSE FILE(IN_FILE);
CLOSE FILE(OUT_FILE);

ここで注意すべきは、PL/Iのポインタは、C言語のようなポインタ演算（`ptr++`のような操作）を直接サポートしているわけではないということです。ポインタはメモリ上のアドレスを保持する変数であり、`ADDR()`関数で変数のアドレスを取得し、`OFFSET()`関数でオフセットを付与するなどの操作を行います。`BASED`変数を介してポインタと連携させ、動的にメモリ領域を確保・操作するシナリオも考えられます。`BUFFERED`ファイルから読み込んだデータブロック全体をポインタで参照し、そのブロック内の特定のオフセットにあるフィールドを操作する、といった高度なテクニックも理論上は可能です。ただし、これは非常に高度なテクニックであり、誤った操作はシステムのアベンド（ABEND）に直結します。

4. コンパイラオプションによる最適化の落とし穴

PL/Iコンパイラは、コードのパフォーマンスを向上させるための様々な最適化オプションを提供しています。`BUFFERED`属性とこれらのオプションの組み合わせは、パフォーマンスの劇的な改善をもたらす可能性がある一方で、予期せぬ副作用を生むこともあります。

例えば、コンパイラがループ内のI/O処理を最適化し、バッファリングをさらに強化するようなコードを生成することがあります。しかし、この最適化が、プログラムのロジック（特に、I/O操作と並行して行う他の処理）と干渉してしまうケースも稀にあります。

/ 例: ループ内でI/Oと計算を同時に行う /
DO I = 1 TO 1000;
READ FILE(IN_FILE) INTO(RECORD);
IF AT(IN_FILE) THEN GOTO END_LOOP;

/ 読み込んだレコードを使った複雑な計算 /
COMPUTATION_RESULT = PERFORM_COMPLEX_CALC(RECORD);

/ 計算結果を別のバッファに書き込み /
PUT FILE(OUT_FILE) DATA(COMPUTATION_RESULT);
END;
END_LOOP:

このようなコードで、コンパイラがI/O処理と計算処理の順序を入れ替えたり、バッファリングを過度に最適化したりすると、期待通りの結果が得られなくなる可能性があります。特に、`BUFFERED`ファイルと`UNBUFFERED`ファイルを混在させる場合や、プログラム内でファイルの状態（バッファリングされているか否か）を細かく制御する必要がある場合に、コンパイラオプションによる最適化が思わぬバグを生むことがあります。

重要なのは、コンパイラオプションを安易にONにするのではなく、その挙動を理解した上で、テストを重ねて適用することです。 移行プロジェクトにおいては、既存のバッチ処理が特定のコンパイラオプション設定下で動作していることを確認し、移行先の環境で同等のオプション設定を適用することが、互換性を維持する上で不可欠です。

5. アベンド（ABEND）発生時のダンプ解析：`BUFFERED`属性との関連

基幹システムの運用において、アベンド（異常終了）は避けたい事象です。`BUFFERED`属性に関連するアベンドは、主に以下のような原因で発生し得ます。

バッファオーバーラン/アンダーラン: プログラムがバッファの範囲を超えてデータを読み書きしようとした場合。特にポインタ操作を誤った場合に発生しやすい。
不正なI/O操作: ファイルがオープンされていないのに`READ`/`PUT`を実行したり、`INPUT`モードで`PUT`を実行したりした場合。
デッドロック: 複数のプロセスが`BUFFERED`ファイルを同時に更新しようとして、互いのバッファ解放を待ち続けてしまう場合。
ディスクI/Oエラー: 物理的なディスク障害や、ディスク容量不足。

アベンドが発生した場合、その原因究明にはダンプ解析が不可欠です。`BUFFERED`ファイルに関連するアベンドでは、以下の点に注目してダンプを解析します。

1. ファイル制御ブロック (FCB) の確認:
各ファイルには、その状態（オープン状況、バッファリングモード、バッファアドレス、ブロックサイズなど）を管理するFCBが存在します。ダンプ中で該当ファイルのFCBを特定し、これらの情報が期待通りになっているかを確認します。`BUFFERED`属性が正しく設定されているか、バッファのアドレスは有効か、などがポイントです。

2. バッファ領域の内容:
もしアベンドがバッファ操作に関連すると疑われる場合、ダンプ上でバッファ領域の内容を確認します。不正なデータや、期待しないフォーマットのデータが格納されていないかなどを調べます。

3. I/O関連のシステムコール/サブルーチン:
PL/IのI/O処理は、OSのI/Oサブシステムを介して行われます。アベンド発生直前のシステムコールや、PL/IのI/Oルーチン（例: `SYSIN`や`SYSOUT`を介した標準I/O処理、または`SYS$I/O`などの低レベルI/Oルーチン）の呼び出し履歴を確認することで、何が原因でエラーが発生したかの手がかりが得られます。

4. ポインタ/ベース変数の値:
ポインタやベース変数を用いた動的メモリ操作が関与している場合、それらの値が不正なメモリ領域を指していないかを確認します。ダンプ中でポインタ変数のアドレス値を確認し、そのアドレスが有効な範囲内にあるか、期待するデータ構造を指しているかを検証します。

`BUFFERED`属性は、I/O回数を減らしパフォーマンスを向上させる一方で、プログラムとOSのI/Oサブシステムとの間に複雑なレイヤーが追加されることを意味します。このレイヤーを正しく理解し、ダンプ解析でその状態を正確に把握することが、アベンド解決の鍵となります。

6. パックデシマル（COMP3）の内部符号反転バグ：`BUFFERED`属性との複合的な影響

PL/Iでよく利用されるパックデシマル（`PIC S9(…) COMP3`）は、数値を効率的に格納するためのデータ形式です。しかし、このデータ形式には、特に内部符号の反転という、非常に厄介なバグが存在することが知られています。

このバグは、特定のコンパイラバージョンや、特定の操作（例えば、パックデシマル変数を文字列として扱った場合や、特定のビット操作を行った場合など）によって誘発されることがあります。パックデシマルは、各バイトに2つの10進数桁を格納し、最後のバイトの最下位4ビットで符号（正は`C`、負は`D`）を表します。この符号部分が、予期せず反転してしまうことがあるのです。

`BUFFERED`属性とこのパックデシマルバグが複合すると、さらに問題が複雑化します。

ディスク上のデータ破損: `BUFFERED`ファイルにパックデシマルデータを書き込む際に、この符号反転バグが発生すると、ディスク上のファイルデータ自体が不正な値になってしまいます。後続のプログラムや、別のジョブでそのファイルを読み込んだ際に、期待しない計算結果や、さらなるアベンドを引き起こす原因となります。
メモリ上での誤読: `BUFFERED`ファイルからデータを読み込む際に、バッファ内のデータが既に符号反転している場合、プログラムはそれを正しい値として解釈しようとします。この誤った値が、後続の計算処理に影響を与えます。

このバグへの対策は、まずコンパイラのバージョンとPTF（プログラム一時修正）レベルを確認し、既知のバグが含まれていないか調査することです。それでも疑わしい場合は、以下の対策が考えられます。

明示的な符号チェックと変換: ファイルから読み込んだパックデシマルデータを、プログラム内で一旦`PIC +9(…)`のような表示形式に変換し、その表示形式で符号を確認・補正してから、再度パックデシマル変数に格納する、といったロジックを組み込みます。
`MOVE`文の挙動確認: パックデシマル変数間の`MOVE`文の挙動を注意深くテストします。場合によっては、`MOVE`ではなく、一旦表示形式を介した変換を行う方が安全なこともあります。
`BUFFERED`属性の再検討: 極めて稀ですが、`BUFFERED`属性とパックデシマルのI/O処理の組み合わせでバグが誘発される場合、一時的に`UNBUFFERED`属性に変更して、問題が解消するかどうかを確認することも、原因特定の一助となります。ただし、パフォーマンスへの影響は避けられません。

レガシー移行においては、このような、一見些細に見えるデータ形式のバグが、システム全体に影響を及ぼすことがあります。移行前の既存コードの徹底的なレビューと、詳細なテストが不可欠です。

7. 埋め込みSQL（DB2）やCICSオンライン処理のエッジケース対策

`BUFFERED`属性は、主にバッチ処理でのファイルI/Oでその効果を発揮しますが、基幹システムでは、データベースアクセス（埋め込みSQL）や、CICS（Customer Information Control System）によるオンライン処理との連携も考慮する必要があります。

7.1. 埋め込みSQL（DB2）との連携

PL/IプログラムからDB2にアクセスする場合、SQL文は通常、OSのDB2インターフェースを通じて実行されます。この際、DB2側でカーソルやバッファリングのメカニズムが利用されますが、PL/Iプログラム側で定義するファイル属性（`BUFFERED`かどうか）が、DB2のI/Oパフォーマンスに直接影響を与えることは、一般的にはありません。

しかし、間接的な影響は考えられます。例えば、PL/Iプログラムが大量のデータをファイルに書き出す処理（`BUFFERED`ファイルを使用）と、DB2にデータを挿入する処理（埋め込みSQLを使用）を並行して行っている場合。

リソース競合: `BUFFERED`ファイルI/OによるCPUやメモリ使用率の上昇が、DB2の処理に影響を与える可能性があります。
同期処理: PL/Iプログラムがファイル処理の完了を待ってからDB2処理を実行する場合、`BUFFERED`ファイルI/Oの完了が遅延すると、全体の処理時間も長くなります。

移行プロジェクトでPL/IプログラムをDB2連携のあるJava/C#などに移行する場合、ファイルI/O部分の`BUFFERED`属性によるパフォーマンス特性を理解し、Java/C#でのストリーム処理やデータベースコネクションプール、バッチ挿入などの機能で同等のパフォーマンスを達成できるように設計する必要があります。

7.2. CICSオンライン処理との連携

CICS環境下でのPL/Iプログラムは、通常、端末からのトランザクション要求に応答して実行されます。CICSにおけるファイルI/Oは、CICS自身のファイル管理機能（VSAMなど）や、DB2などを介して行われます。

CICS環境では、`BUFFERED`属性の指定は、CICSが提供するファイル制御機構との相互作用によって、その挙動が変化する可能性があります。CICSは、トランザクションの応答性を最優先するため、内部で効率的なバッファリングメカニズムを持っています。PL/Iプログラムで`BUFFERED`属性を指定した場合、CICSのファイル管理とPL/IのI/Oルーチン、そしてOSのI/Oサブシステムが協調して動作しますが、その複雑さから予期せぬデッドロックやパフォーマンス低下を招くこともあります。

特に、オンライン処理では、レコードロックやトランザクションのコミット/ロールバックといった概念が重要になります。`BUFFERED`ファイルへの書き込みが、トランザクションのコミットまでディスクにフラッシュされない場合、そのデータは一時的にバッファに留まります。この間に他のトランザクションが同じデータにアクセスしようとすると、ロック競合やデータ不整合のリスクが生じます。

CICS環境での`BUFFERED`属性の利用は、慎重な設計とテストが必要です。一般的には、CICSのファイル制御機能に任せるのが基本ですが、どうしてもPL/IレベルでI/O効率を最適化したい場合は、以下のような対策が考えられます。

`FLUSH`命令の使用: PL/Iには、`FLUSH FILE(filename)`という命令があり、これによりバッファリングされているデータを強制的にディスクに書き出すことができます。オンライン処理で、ある程度のデータ処理後にディスクへの永続化が必要な場合に、この`FLUSH`命令を適切に配置することで、データの一貫性を保ちつつ、パフォーマンスを調整することが可能です。
レコードロックの考慮: `BUFFERED`ファイルであっても、CICSはレコードロック機構を提供します。プログラム内でロックを適切に取得・解放し、データ競合を防ぐ必要があります。
`FILE`定義の`ENVIRONMENT`オプション: CICS環境では、`ENVIRONMENT`オプションで`RECSIZE`, `KEYLEN`, `STRNO`などを指定して、VSAMファイルなどの特性を細かく制御します。これらの設定と`BUFFERED`属性の組み合わせも、パフォーマンスに影響を与えます。

レガシー移行において、CICS上のPL/IプログラムをJava/C#（Spring Boot, .NET Coreなど）で再構築する場合、CICSのトランザクション管理、ファイルアクセス、データベースアクセスといった機能を、最新のフレームワークやミドルウェアでどのように実現するかを設計する必要があります。`BUFFERED`属性の挙動や、それに伴うパフォーマンス特性、そしてCICS特有の同期・ロック機構などを、移行先の技術スタックで再現するための深い理解が求められます。

8. まとめ：`BUFFERED`属性は「信頼性」と「効率」のバランス点

`BUFFERED`属性は、PL/IにおけるファイルI/Oのパフォーマンスを劇的に向上させる強力なメカニズムです。しかし、その裏側には、バッファ管理、メモリ消費、そしてコンパイラやOSとの複雑な相互作用が存在します。パックデシマルの内部符号反転バグや、CICS環境での挙動など、一見すると`BUFFERED`属性とは無関係に見える問題も、その複合的な影響によって顕在化することがあります。

基幹システムのテックリードや、レガシー移行を担当するアーキテクトにとって、`BUFFERED`属性の深い理解は、単なるパフォーマンスチューニングにとどまりません。それは、

既存システムの挙動の解明: なぜこのシステムはこのようなI/Oパフォーマンスなのか？
移行リスクの低減: 移行先の技術スタックで、同等以上のパフォーマンスと信頼性をどう実現するか？
トラブルシューティング能力の向上: アベンド発生時に、どこから調査を始めるべきか？

といった、実務に直結する課題を解決するための羅針盤となります。

PL/Iの`BUFFERED`属性は、まさに「信頼性」と「効率」の絶妙なバランス点を探るための、先人たちが築き上げた知恵の結晶と言えるでしょう。この知見を、次世代システムへの橋渡しに活かしていくことが、我々アーキテクトに課せられた責務なのです。