仮想小数点の深淵：PL/I `PICTURE ‘V’` が隠蔽する演算の真実
メインフレームの現場で長く生きていると、若手エンジニアから「なぜデータ定義に存在しないはずの小数点に、コンパイラはこれほどまでに固執するのか」という問いを投げかけられることがある。
PL/Iの `PICTURE ‘V’`（仮想小数点）。これは単なるフォーマット指定ではない。COBOLの `PIC V` と同列に語られがちだが、PL/Iにおけるそれは、コンパイラが生成する算術演算コードの「設計図」そのものである。今回は、この `V` が裏側でどのようにCPUを動かし、現代のマイグレーションにおいてどのような地雷原となるかを解き明かそう。
—
1. `V` は物理的存在にあらず、論理的な「位取り」の指標である
まず前提として、`PIC ‘S9(7)V99’ COMP-3` と定義した変数の中に、小数点は存在しない。メモリ上には単なるパック10進数としてビットが並んでいるだけだ。
PL/Iコンパイラは、この `V` を見て演算命令の前後で「位取り（Scaling）」を自動的に調整するコードを生成する。例えば、小数点位置が異なる変数同士の加算が行われる際、コンパイラは内部的に `CVB` (Convert to Binary) や `SRP` (Shift and Round Packed) 命令を駆使し、ハードウェアレベルで位合わせを行う。
1
DCL AMOUNT_A PIC ‘S9(5)V99’ COMP-3; / 物理的には 4バイト /
DCL AMOUNT_B PIC ‘S9(7)V9’ COMP-3; / 物理的には 5バイト /
DCL RESULT PIC ‘S9(9)V99’ COMP-3;
/ コンパイラはここで、AMOUNT_AとAMOUNT_Bの位取りを一致させるための
隠れたシフト演算を生成する。このオーバーヘッドを意識できるかが
バッチ処理の性能チューニングの分かれ目となる。 /
RESULT = AMOUNT_A + AMOUNT_B;
2. マイグレーション時の「符号反転バグ」という罠
JavaやC#への移行時、この `V` の挙動を安易に `BigDecimal` や `double` にマッピングしてはならない。特に致命的なのは、パック10進数の符号ビットの解釈だ。
PL/Iでは、`PIC` 指定と実際のデータの内容が一致していない場合、あるいは不正なデータ（IBM汎用機では `0C` や `0F` 以外の符号）が混入した場合、コンパイラが生成したコードは無慈悲に `S0C7` (Data Exception) を投げる。
一方で、Java等への移行先では「数値として読める限りは許容する」という甘い実装がなされることが多く、結果として「メインフレームでは落ちていた不正データが、新環境では謎の計算結果を吐き出す」という最悪のバグを生む。
- 対策: 移行時には、全ての `PIC` 定義に対して `TESTBIT` 的なバリデーション層を設けるか、`DB2` の `CHECK CONSTRAINT` を活用して、アプリケーション層に到達する前に不正な符号を排除するアーキテクチャを必須とすべきだ。
—
3. ポインタ操作と `DEFINED` による裏技的メモリ操作
上級者は、`BASED` 変数と `ADDR` 関数を使い、この仮想小数点構造を「強引に再定義」することがある。これは `CICS` の通信領域（COMMAREA）の解析などで多用される手法だが、極めて危険だ。
1
DCL RAW_DATA CHAR(10) BASED(P_PTR);
DCL 1 STRUCTURE_MAP BASED(P_PTR),
2 FIELD_VAL PIC ‘S9(7)V99’ COMP-3;
/ 物理的なオフセットを直接操作する際は注意が必要。
Vの定義位置を勘違いしてポインタをずらすと、
パック10進数の下位ニブル(符号部)が数値部と誤認され、
計算結果が10倍、あるいは1/10になるという悲劇が起きる。 /
このようなコードがある場合、マイグレーション時にはその変数が「本当に数値として扱われているか」それとも「単なるバイト列のバッファか」を静的解析ツール以上に、泥臭いダンプ解析で確認する必要がある。
—
4. アーキテクトへの提言：ダンプ解析の極意
`S0C7` アベンドが発生した際、初心者は `PSW`（プログラムステータスワード）で命令アドレスを確認して終わる。だが、真のスペシャリストは 「その瞬間のパック10進数の全ニブル」 を目視する。
1. 符号の確認: `C` (正) か `D` (負) か `F` (符号なし/符号未定義) か。
2. 位取りの確認: `V` の位置が期待通りか。
3. コンパイラ最適化の影響: `OPTIMIZE(3)` をかけている場合、計算順序が最適化され、中間結果が `PIC` の桁数を超えてしまい、符号が消失（オーバーフロー）することがある。
PL/Iの `V` は、汎用機が積み上げてきた「正確な計算」の歴史そのものだ。現代の言語に移行する際、この「小数点以下の厳密さ」を単なる浮動小数点に置き換えることは、基幹システムの信頼性をドブに捨てることに等しい。
移行プロジェクトのリーダーたる者は、コードの行数ではなく、「コンパイラが裏でどんな演算命令を吐いているか」 を常にイメージしてほしい。それができれば、どんな巨大なレガシーシステムも、恐れるに足りないはずだ。
