仮想小数点の罠：PL/IのPICTURE ‘V’が引き起こす「見えない」演算エラーの深淵
メインフレームの現場で長く生きていると、若手エンジニアから「なぜか計算結果が100倍になる」「DB2から持ってきた値が化ける」という悲鳴混じりの相談を受けることがよくある。その原因の多くは、PL/Iにおける`PICTURE`句、特に仮想小数点を示す`V`の挙動に対する理解不足にある。
現代のJavaやC#のデベロッパーには馴染みのないこの「V」。コンパイラが裏でどのようなアライメント調整を行っているのか。基幹システムの信頼性を担保するスペシャリストとして、この「V」の魔術と、それが引き起こす阿鼻叫喚の現場事例を紐解いていこう。
—
1. PICTURE ‘V’：実体なき小数点の正体
PL/Iにおいて`PICTURE ‘999V99’`と宣言した場合、コンパイラはこれを5桁の数値として扱うが、メモリ上には小数点記号（`.`）は存在しない。これはあくまで「論理的な位置指定」だ。
/i
DCL AMT_WORK FIXED DEC(5,2); / 内部的には 999V99 と同じ /
AMT_WORK = 12345; / 結果は 123.45 として扱われる /
この`V`の恐ろしいところは、演算時や代入時にコンパイラが暗黙の「アライメント調整」を強いることだ。例えば、`FIXED DEC(5,2)`と`FIXED DEC(5,0)`を演算させれば、コンパイラは小数点位置を合わせるために内部でシフト演算を挿入する。
現場でのトラブル：パックデシマルと符号の反転
移行プロジェクトで最も厄介なのが、外部データ（特に他言語で作成されたフラットファイル）を読み込む際、`V`の位置を誤ったまま`DEFINED`や`BASED`変数でマップしてしまうケースだ。
/i
/ 危険なデータ定義の例 /
DCL 1 DATA_REC BASED(P_REC),
2 VAL_A FIXED DEC(5,2),
2 VAL_B FIXED DEC(3,0);
/ 実データが 12345 (末尾X’5C’で符号プラス) の場合 /
/ VAL_A は 123.45 と解釈されるが、VAL_B が混入すると… /
もし、符号ビット（パックデシマルの末尾ニブル）が想定外の場所に位置していれば、演算時に`SOC7`（データ例外）が発生する。あるいは、さらに悪いことに、符号ビットを数値の一部として解釈してしまい、計算結果が意図せず反転・増大する。このバグは、本番のバッチで数千万円単位の計算ミスを引き起こすまで気づかれないことが多い。
—
2. ポインタとBASED変数による動的メモリ操作の落とし穴
C言語のように`POINTER`型を駆使してメモリを直接操作する手法は、PL/Iの醍醐味だが、同時にアベンドの温床でもある。特に`OFFSET`変数や`BASED`変数を使用する際は、`V`によるアライメントがコンパイラの最適化オプション（`OPTIMIZE(3)`など）によってどう解釈されるか、リストファイル（`LIST`オプション）を出力して確認する癖をつけなければならない。
/i
DCL P_BUF PTR;
DCL X FIXED DEC(5,2) BASED(P_BUF);
/ メモリの境界整合性が取れていない場合、
システムは保護違反(0C4)ではなく、
静かに誤った値を演算結果に反映させる可能性がある /
特にDB2の埋め込みSQL（`EXEC SQL`）を使用する際、ホスト変数として`V`を含む`PICTURE`を定義すると、DB2側の`DECIMAL`型との間で暗黙の型変換が走り、パフォーマンスが劇的に低下する。基幹システムにおいては、「SQLのホスト変数には可能な限り`FIXED BIN(31)`あるいは精度を合わせた`FIXED DEC`を使用する」のが鉄則だ。
—
3. マイグレーションに向けたアーキテクチャ的提言
Javaへの移行を検討している読者へ。Javaの`BigDecimal`は、PL/Iの`FIXED DEC`と異なり、精度とスケールを明示的に指定しないと誤差を生む。
- PL/IのVは「論理」、JavaのBigDecimalは「精度とスケールのペア」：この概念を変換ロジックに落とし込む際、単なる型変換ではなく、バリデーションロジックを挟む必要がある。
- ダンプ解析の極意：`SYSUDUMP`を眺める際、`V`の位置がずれていることに気づくには、数値の16進数表現（X’12345C’等）を即座にパックデシマルとして脳内変換できる能力が必須だ。これができないうちは、マイグレーションの設計は任せられない。
—
結び：古き良き言語の矜持
PL/Iには「予約語」という概念が希薄だ。これは自由度が高い反面、変数の命名一つでコンパイラの解釈が変わりうる危険を孕んでいる。しかし、この「言語仕様の深淵」を理解し、コンパイラと対話するようにコードを書く技術は、現代のブラックボックス化したフレームワーク開発では到底得られない、システムアーキテクトとしての「職人芸」である。
次回のバッチ改修やマイグレーション調査で、もし皆さんが`SOC7`や不可解な数値計算に遭遇したなら、まず`PICTURE`宣言の`V`の位置を疑え。そして、コンパイラの生成するアセンブラコード（`LIST`オプション）を覗き込む勇気を持ってほしい。そこにこそ、真実が隠されている。
