メインフレームの現場から：PL/I `PIC ‘V’` が織りなす仮想小数点と、Java/C#マイグレーションの深き罠
こんにちは。長年、金融や流通の基幹システムでIBMメインフレームの番人をしてきたシステムアーキテクトだ。
PL/Iという言語は、古くは1960年代に生まれたにもかかわらず、その言語仕様の懐の深さと、ハードウェア（z/Architecture）の特性に極限まで最適化されたデータ制御機構ゆえに、現代のオープン系エンジニアを時に絶望の淵に追い込む。
今回は、その中でもバッチ処理の計算精度やデータ移行の成否を握る核心、`PIC ‘V’` による仮想小数点（Implied Decimal Point）の制御について、コンパイラの内部挙動やマイグレーションの現場で踏む地雷の観点から徹底的に紐解いていこう。
—
1. 仮想小数点 `V` とは何か？ なぜ物理的に保持しないのか
COBOLの `PIC 9(5)V99` と同様に、PL/Iのピクチャー句でも `V` はデータ実体を伴わない「仮想的な小数点」を定義する。
例えば、`DCL WS_AMT_A FIXED DEC(7,2) INIT(1234567);` と宣言された変数があったとする。
ここで `(7,2)` は「全体で7桁、うち小数点以下が2桁」を意味し、内部的には `PIC ‘9(5)V99’` として解釈される。
+—————————+
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | <-- 7バイト（パック10進数なら4バイト）
+---------------------------+
^ ^
上位5桁（整数部） 下位2桁（小数部）
↑
（ここにVがあるものとみなす）
なぜわざわざ物理的な小数点を持たせないのか？
それは、IBMメインフレームのハードウェア命令（Decimal Arithmetic Instructions：ZAP, AP, SP, MP, DPなど）が、純粋な整数（固定小数点数）として高速に演算を行う設計になっているからに他ならない。浮動小数点（FLOATING POINT）特有の丸め誤差を排除し、金融計算における「1円の狂いも許されない厳密性」と「商用計算のパフォーマンス」を両立させるための、先人たちの知恵の結晶なのだ。
—
2. 演算時の桁合わせルールとコンパイラ（Enterprise PL/I）の挙動
PL/Iが優れているのは、異なる精度やスケールを持つ変数同士の演算であっても、コンパイラが自動的に適切なスケーリング（桁合わせ）コードを生成してくれる点だ。しかし、この「暗黙の自動スケーリング」が、時に予期せぬアベンド（ABEND）やデータ切り捨てを引き起こす。
以下のPL/Iコード例を見てほしい。
———————————————————————-
- 仮想小数点を持つ変数間の演算と桁あふれ・丸めの制御例
———————————————————————-
SAMPLE_CALC: PROC OPTIONS(MAIN);
DCL WS_PRICE FIXED DEC(7,2) INIT(12345.67); / 単価: 整数5桁, 小数2桁 /
DCL WS_QTY FIXED DEC(5,0) INIT(100); / 数量: 整数5桁, 小数0桁 /
DCL WS_TOTAL FIXED DEC(9,4); / 金額: 整数5桁, 小数4桁 /
DCL WS_DISP PIC ‘$ZZZ,ZZ9.99’; / 編集用ピクチャー /
/ 1. 乗算時のスケール自動調整 /
/ WS_PRICE(7,2) WS_QTY(5,0) の結果は、数学的には小数2位となるが、 /
/ PL/Iの規則では、精度の和とスケールの和が計算結果に適用される。 /
WS_TOTAL = WS_PRICE WS_QTY;
PUT SKIP LIST (‘CALCULATED TOTAL:’, WS_TOTAL);
/ 2. 異なるスケール間への代入と丸め（ROUNDビルトイン関数）の重要性 /
/ 演算結果を元の小数2桁に戻す際、四捨五入が必要なケース /
BEGIN;
DCL WS_ROUNDED_AMT FIXED DEC(7,2);
/ 単純代入だと、受側の小数部に合わせて切り捨て（TRUNCATION）される /
/ 厳密な金融計算では ROUNDビルトイン関数を明示的に使用すべきである /
WS_ROUNDED_AMT = ROUND(WS_TOTAL, 2);
WS_DISP = WS_ROUNDED_AMT;
PUT SKIP LIST (‘ROUNDED TOTAL :’, WS_DISP);
END;
END SAMPLE_CALC;
アーキテクトの眼：コンパイラオプションの罠
Enterprise PL/Iコンパイラを使用する際、`TRUNC(BIN)` や `LIMITS` などのオプション設定が、仮想小数点演算のオーバーフロー挙動に直接影響を与える。
特に、マイグレーション先（Java等）の BigDecimal のスケール変更や丸めモード（`HALF_UP` vs `DOWN`）の差異を検証する際、PL/I側がどのような中間レジスタで計算を行い、どのタイミングでパッキングを解いているかをコンパイラリスト（LISTING）の生成コード（Object Code）レベルで追う必要がある。
—
3. 現場で遭遇したエッジケースとトラブルシューティング
ここからは、実務の現場で私を何度も冷や汗まみれにしてきた「仮想小数点にまつわる暗黒面」をいくつか共有しよう。
① 埋め込みSQL（DB2）における DECIMAL 型の不一致
メインフレームのDB2において、列定義が `DECIMAL(9,2)` のカラムに対し、PL/I側で `FIXED DEC(7,2)` や `FIXED DEC(9,4)` でホスト変数を受け渡す際、仮想小数点の位置（スケール）が一致していないと、DB2プリコンパイラはエラーを出さないにもかかわらず、実行時にSQLCODE -302（値の切り捨てまたはレンジエラー）が発生する。
特に、DB2のホスト変数構造体（DCLGENで生成されたもの）のスケールを変更し忘れてバッチ本番稼働を迎え、夜間バッチが仲良く全滅したインシデントは数え切れない。
② CICSオンラインにおけるパックデシマルの内部符号反転バグ
CICSの通信領域（COMMAREA）やストレージ（GETMAIN領域）を介してデータをやり取りする際、送信側と受信側でピクチャーの定義（特に `V` の位置や全体長）がズレていると、ストレージ上でバイナリデータが誤った解釈をされる。
特に、パックデシマル（COMP-3）の最下位ニブル（4ビット）に格納される符号（`C`, `D`, `F` など）の直前に仮想小数点が存在するため、ポインタ等を使って生メモリ（POINTER / BASED変数）を直接操作するような低レイヤーの処理を書いている場合、スケールの認識違いによってデータが化け、アベンド（ASRA / 0C7 アベンド：データ例外）を引き起こす典型的な原因となる。
—
4. Java / C# へのマイグレーション（レガシー移行）における設計指針
「PL/IのシステムをJava（Spring Boot）やC#（.NET Core）にリライトする」というプロジェクトをテックリードとして率いる際、この `PIC ‘V’` の概念をどうモダン言語に落とし込むかが成否の分かれ道となる。
1. 浮動小数点（`float` / `double`）の採用は厳禁
- 言うまでもないが、二進浮動小数点は誤差を生むため、金融・基幹システムでは即座に不採用とすべき。
2. `java.math.BigDecimal` のスケール（Scale）と丸めモード（RoundingMode）の徹底
- PL/Iの `FIXED DEC(p,q)` は、そのまま Java の `BigDecimal`（scale = q）に直訳できる。
- しかし、代入時や演算時の暗黙の丸め挙動（PL/Iはデフォルトで切り捨て `TRUNC` が働く場合が多い）と、Javaの `BigDecimal` の挙動（演算時にスケールが自動拡張される等）の差異を吸収するため、移行先の共通ライブラリ側で「PL/I互換の演算・丸めラッパー関数」を定義することが不可欠だ。
—
おわりに
PL/Iの `PIC ‘V’` は、単なるデータのフォーマット指定ではない。それは、ハードウェアの制約とビジネスロジックの厳密さを極限まで調停するための、メインフレーム時代からの洗練されたアーキテクチャの一部なのだ。
オープン系への移行が進む現在であっても、レガシーが抱える「なぜそのようなデータ構造になっているのか」という設計思想の背景を理解していなければ、移行後のバグや数値の不整合に頭を悩ませ続けることになる。
基幹システムのモダナイゼーションを成功させるカギは、新しい言語の習得以上に、古い言語の挙動を骨の髄まで理解することにある――私はそう確信している。
