現場の知恵袋：BIT型属性の深淵と、メモリ効率がバッチ性能に与える「静かなる衝撃」
メインフレームの現場で長年設計を続けていると、若手から「なぜこの構造体はわざわざ`UNALIGNED`と書くのか？」という質問をよく受ける。PL/IはCOBOLのようなガチガチの予約語縛りがない自由な言語だが、その自由さは「メモリレイアウトをどう制御するか」というエンジニアの責任に直結している。
今日は、特にバッチ処理の性能を左右する`BIT(n)`型の扱いについて、現場の「痛い経験」を交えながら解説しよう。
—
1. なぜ「境界調整（ALIGNMENT）」が重要なのか
PL/Iには、メモリ配置を制御する `ALIGNED` と `UNALIGNED` という属性がある。デフォルトの属性はデータの型によって異なるが、`BIT`型の場合、明示的に制御しないと後で泣きを見ることになる。
- ALIGNED: データを境界（通常はバイトの先頭）に合わせる。アクセス速度は最速だが、パディング（詰め物）が入りメモリを大量に消費する。
- UNALIGNED: 境界を無視してビット単位で詰め込む。メモリ効率は最高だが、CPUがビット列をロードする際、シフト演算やマスク処理が発生するため、わずかながらアクセス負荷がかかる。
大規模な基幹システムにおいて、数百万件のレコードを扱うVSAMファイルや固定長ファイル（QSAM）の設計では、この「わずかな負荷」が、深夜のバッチウィンドウ（処理時間枠）を圧迫する要因になるのだ。
—
2. 実践的なコーディング例：メモリレイアウトの最適化
以下のコードを見てほしい。フラグ管理を詰め込んだ構造体の定義例だ。
/i
/ 構造体のメモリレイアウトを最適化する例 /
DCL 1 WORK_RECORD,
/ フラグ群をビット列で定義。UNALIGNEDにすることでメモリを節約 /
5 FLAG_AREA BIT(8) UNALIGNED,
/ 数値項目はALIGNED（デフォルト）にしてアクセス速度を優先 /
5 SEQ_NUM FIXED BIN(31) ALIGNED;
/ BUILTIN関数を活用した制御例 /
IF SUBSTR(FLAG_AREA, 1, 1) = ‘1’B THEN
DO;
/ 処理内容 /
END;
/ 予期せぬONユニットによる割り込み防止 /
ON ENDFILE(INFILE) BEGIN;
PUT SKIP LIST(‘データ終端に到達しました’);
END;
ここで重要なのは、`FLAG_AREA`のように多数のビットフラグを持つ場合、`UNALIGNED`を指定しないと、各ビットが1バイト（8ビット）を占有してしまう可能性があるということだ。メモリをケチるべきところは徹底的にケチる。これがメインフレームアーキテクトの矜持である。
—
3. VSAMアクセスと「レコードのズレ」という悪夢
実務で最も恐ろしいのは、「COBOLで定義されたファイルレイアウトとPL/Iの構造体の解釈が食い違う」というトラブルだ。
PL/Iの構造体で`ALIGNED`を不用意に使うと、本来のレコードレイアウトに勝手にパディングビットが挿入され、VSAMのキー項目やデータ項目が「1バイト右にズレる」という現象が発生する。これによって、あるはずのデータが読み込めなかったり、インデックスエラーが頻発したりする。
トラブルシューティングの鉄則:
1. COPY句（INCLUDEメンバ）の確認: 他言語と共有している場合は、必ず`UNALIGNED`属性を明示的に付与すること。
2. OFFSETの検証: `STORAGE`関数や`ADDR`関数を使って、実際のバッファが期待通りのオフセットになっているかデバッグ時に確認する習慣をつける。
—
4. 最後に：なぜ今、この知識が必要なのか
クラウド移行やレガシー刷新のプロジェクトであっても、データを扱う根本的なロジックは変わらない。メモリの1ビットを大切にする姿勢は、計算コストを下げ、結果としてシステムのランニングコストを削減する。
PL/Iは古臭い言語だと言われることもあるが、これほどまでにCPUの挙動を肌で感じながら制御できる言語は他にない。
もし君が今、バッチ処理の性能低下に悩んでいるなら、まずは構造体定義の`ALIGNED/UNALIGNED`を見直してみるといい。たった一行の修正が、何時間ものバッチ時間を短縮する鍵になるかもしれない。
現場からは以上だ。何かあれば、いつでもコードを持って相談に来なさい。
