PL/Iの「見えない小数点」を制する：PIC ‘V’ の演算メカニズムと現場の鉄則
メインフレームの現場で長年バッチ改修を重ねていると、新人のエンジニアから「なぜか計算結果の桁が合わない」「コンパイルは通るのに実行時に変な値になる」という相談をよく受けます。その多くが、PL/I特有のデータ記述、特に `PICTURE` 句における `’V’`（仮想小数点）の扱いを曖昧に理解していることが原因です。
COBOLの `PIC` とは似て非なるこの仕組み。今日は、コンパイラが裏で何をしているのか、現場の視点から紐解いていきましょう。
—
1. PIC ‘V’ は「物理的なメモリ」ではない
まず、大前提として知っておいてほしいのは、`PIC ‘S9(5)V99’` と定義したからといって、メモリ上に小数点用のバイトが確保されるわけではない、ということです。
PL/Iの `V` は、あくまで「コンパイラに対する解釈のガイド」です。コンパイラは、この記述を見て「この変数の下位2桁は小数部として扱い、演算時には自動的に桁合わせ（アライメント）を行え」という命令を生成します。
つまり、`123.45` という値は、内部的には `12345` という整数値として扱われます。この「見えない境界線」を意識できるかどうかが、バグのないコードを書くための分かれ道です。
—
2. コンパイラによる自動シフトの仕組み
例えば、`FIXED DECIMAL` 同士の演算を行う場合、PL/Iコンパイラは以下の手順を踏みます。
1. 位置合わせ: 演算対象の各変数の `V` の位置を確認する。
2. 正規化: 演算のために、内部的に値をシフトし、`V` の位置を揃える。
3. 演算実行: 揃えた状態で加減算を行う。
4. 格納: ターゲットとなる変数の `PIC` に合わせて、再度シフトして値を格納する。
この「自動シフト」は非常に便利ですが、代入先の桁数が足りない場合、あるいは演算の過程で中間結果が最大精度を超えた場合、容赦なく切り捨て（Truncation）が発生します。特に古いマイグレーション案件では、この桁落ちが「いつの間にか金額が合わない」という形で現れます。
—
3. 実践コード：安全な演算と注意点
では、実際に現場でよく使う実装パターンを見てみましょう。`BUILTIN` 関数を適切に使うことが、計算ミスを防ぐ近道です。
1
/ —————————————————————— /
/ PIC ‘V’ を使用した演算例 /
/ —————————————————————— /
PROCEDURE OPTIONS(MAIN);
DCL W_TANKA FIXED DEC(7, 2) INIT(1234.56); / 1234V56 /
DCL W_SURYO FIXED DEC(5, 0) INIT(100); / 100V /
DCL W_KINGAKU FIXED DEC(11, 2) INIT(0); / 結果用 /
/ 計算処理：コンパイラが自動的に W_SURYO を V99 に合わせてシフトする /
W_KINGAKU = W_TANKA W_SURYO;
/
- 注意点:
- 除算を行う際は、DECIMAL関数を使用して精度を指定しないと、
- 予期せぬ桁落ちが発生することがあるため注意が必要。
/
DCL W_WARI FIXED DEC(5, 4) INIT(0.1234);
DCL W_RESULT FIXED DEC(9, 2);
/ 明示的に精度を指定して計算を保護するパターン /
W_RESULT = DECIMAL(W_KINGAKU W_WARI, 9, 2);
PUT SKIP LIST(‘計算結果:’, W_RESULT);
END;
—
4. 現場で生き残るための「鉄則」
最後に、トラブルシューティングで私が若手に必ず伝える3つの鉄則を共有します。
- ON FIXEDOVERFLOW を活用せよ:
計算結果が変数の領域を溢れた場合、デフォルトではエラーにならず、警告なしに桁落ちすることがあります。開発環境では `ON FIXEDOVERFLOW BEGIN; … END;` を仕込んで、桁溢れを即座に検知できるようにしておくのがベテランの作法です。
- VSAM読み込み時は「再定義」を疑え:
VSAMファイルから読み込んだデータを `PIC` 変数にマップする際、定義がズレていると `V` の位置が物理的な数値の途中に食い込みます。文字データとして読み込み、必要なタイミングで `FIXED` 型へ変換する手法も、大規模システムでは安全策として推奨されます。
- 「見えない小数点」をデバッガで覗く:
`IBM Debug Tool` などを使用する際は、必ず16進数（HEX）表示で値を確認してください。`V` は表示されませんが、内部表現（パック10進数）を確認すれば、どこでシフトが起きているかが一目瞭然です。
PL/Iは、型システムと演算ルールが非常に強力です。だからこそ、言語仕様を「なんとなく」で使わず、コンパイラが裏でどんなロジックを動かしているのかを想像する。それが、時代が変わっても「あの人に任せれば大丈夫」と言われるエンジニアへの第一歩です。
何か具体的なコードで「ここで挙動がおかしい」という箇所があれば、いつでも相談してください。一緒にデバッグしましょう。
