PL/Iの「BIT(n)」を制する者は、基幹システムのメモリを制す
汎用機の世界で長年PL/Iと対峙していると、「なぜ今さらBIT型なのか」と問われることがある。しかし、数十億レコードのトランザクションをさばくバッチや、リソースが極限まで制限されたCICSオンラインにおいて、BIT(n)の扱いは単なるデータ型の選択を超えた「システムアーキテクチャの要諦」だ。
今日は、JavaやC#へのマイグレーションを控えたテックリードの諸君に向けて、PL/IにおけるBIT操作の深淵と、それが引き起こす現実的なリスクについて語ろう。
—
1. なぜBIT(n)はメモリ効率の「最後の砦」なのか
PL/IのBIT(n)は、1ビット単位でメモリを占有する。例えば、8個のフラグを管理する際、`CHAR(1)`を8つ並べれば8バイト必要だが、`BIT(8)`ならわずか1バイトで済む。
/i
/ 8ビットのフラグ管理：メモリ節約の定石 /
DCL FLAG_BITS BIT(8) INITIAL(‘00000000’B);
/ 論理積(AND)を用いた特定のビットの抽出 /
IF (FLAG_BITS & ‘00000001’B) THEN DO;
/ 1ビット目がONの場合の処理 /
END;
この「1ビットの重み」を理解せず、移行先のJavaで無邪気に`boolean`の配列や`List
—
2. ポインタを用いた動的メモリ操作と「罠」
複雑なシステムでは、`BASED`変数と`POINTER`を駆使して、動的に割り当てられたメモリ領域をBIT列として解釈させることがある。ここで注意すべきは、境界整列（Alignment）とパディングだ。
/i
DCL BUFFER_PTR POINTER;
DCL 1 MY_DATA BASED(BUFFER_PTR),
2 FLAG_BYTE BIT(8),
2 DATA_VAL FIXED BIN(31);
/ 動的確保した領域をBITとして操作する際の危険性 /
ALLOCATE MY_DATA;
/ システムのダンプ解析で最も多いのが、このポインタ参照先のオフセットズレ /
コンパイラオプション（`ALIGN` vs `UNALIGNED`）の設定如何で、構造体のメモリ配置は劇的に変わる。特にCICSでの通信データ領域（DFHCOMMAREA）を扱う際、PL/I側の定義と他言語の構造がズレていれば、それは時限爆弾だ。ダンプ解析の際、`S0C4`（保護例外）が発生したら、まず真っ先にポインタのアドレスと、各メンバのオフセットがコンパイラオプション通りに並んでいるかを確認せよ。
—
3. 実務で遭遇する「悪魔の証明」：パックデシマルと符号反転
BIT操作とは少し逸れるが、基幹系移行で最もエンジニアを泣かせるのが、`PIC S9(n) COMP-3`（パックデシマル）の符号反転だ。PL/Iは内部的に非常に柔軟だが、DB2のホスト変数として渡す際に、末尾の符号ビット（`C`や`D`、`F`）が正しく認識されず、論理エラーを引き起こすケースが後を絶たない。
特に、メインフレーム特有の「符号付き0（負のゼロ）」の問題は、Javaの`BigDecimal`やC#の`decimal`への変換時に必ず検証項目となる。
/i
/ 埋め込みSQL実行時のホスト変数 /
EXEC SQL SELECT COL_VAL INTO :HOST_VAR FROM TABLE_A;
/ このHOST_VARがCOMP-3の場合、ダンプ上で末尾のニブルが
‘C’なら正、’D’なら負。このビット構成を意識しない移行は失敗する /
—
4. 移行を見据えたアーキテクトへの提言
PL/Iからモダン言語への移行を成功させるには、以下の3点を徹底してほしい。
1. コンパイラオプションの可視化: 現在のシステムが `OPTIMIZE(3)` なのか `(0)` なのか、また `RENT`（再入可能）なのかを正確に把握せよ。最適化レベルを上げると、デバッグ時のコードステップが飛び、ダンプ解析が困難になる。
2. ビット操作のラップ: PL/IのBIT論理演算を、安易に移行先の言語のビット演算子に直書きしてはならない。必ず「`IsFlagEnabled(byte, mask)`」のようなラッパー関数を通すこと。ロジックの意図が可視化され、保守性が劇的に向上する。
3. エッジケースの回帰テスト: 特にCICSの`EXEC CICS LINK`等でデータを引き継ぐ際、`BIT`や`COMP-3`の境界条件（最大値、最小値、符号反転）を網羅したテストデータを生成せよ。
PL/Iという言語は、ハードウェアの挙動を直接制御できる「美しき低レイヤー」の集合体だ。JavaやC#へ移行する今だからこそ、この言語が隠蔽していた「メモリという物理的制約」に対する敬意を忘れないでほしい。それが、レガシーを「負債」ではなく「資産」として次世代に継承する唯一の道である。
諸君のプロジェクトが、S0C7の悪夢に見舞われることなく、無事にメインフレームの重責から解放されることを切に願う。
