PL/Iの「DECIMAL関数」が握る、基幹システムの精度と命運
メインフレームのコードを読み解いていると、たまに溜息が出るほど美しいロジックに出会う一方で、後続のエンジニアを絶望させる「呪い」のようなコードにも遭遇する。その代表格が、`FIXED BINARY`（2進固定小数点）から`FIXED DECIMAL`（パック10進数）への変換、いわゆる「型変換の迷宮」だ。
特に、勘定系や決済系のバッチ処理において、`DECIMAL(source, p, q)` 関数を不用意に使うことは、時限爆弾を埋め込むことに等しい。今日は、この関数の背後にあるコンパイラの挙動と、マイグレーション時に陥りやすい罠について、現場の視点から紐解いていこう。
—
1. DECIMAL関数の「p」と「q」という名の境界線
まず基本を押さえよう。`DECIMAL(X, p, q)` は、単なるキャストではない。`p`（精度）と `q`（位取り）の指定は、IBMのPL/Iコンパイラに対して「どの程度のメモリ領域を確保し、どこで小数点位置を固定するか」という、物理レイヤーに近い制約を突きつける行為だ。
/i
DCL BIN_VAL FIXED BIN(31) INIT(123456);
DCL DEC_VAL FIXED DEC(7, 2);
/ 内部的にはパック10進数(COMP-3)として扱われる /
DEC_VAL = DECIMAL(BIN_VAL, 7, 2);
/ 結果: 1234.56 となる。ここで重要なのは、p=7, q=2の制約を外れると
即座に FIXEDOVERFLOW が発生するリスクがあることだ。 /
現場で最も恐ろしいのは、計算過程での「桁あふれ」だ。`FIXED BIN` から `FIXED DEC` に変換する際、`p` の値が元の値の桁数を包含できていない場合、コンパイラは実行時に `SIGFIXED`（FIXEDOVERFLOW）例外を投げる。JavaやC#のように勝手に切り捨ててくれるような甘えは許されない。汎用機は、計算の整合性が取れないと判断した瞬間、容赦なくアベンド（ABEND）し、ダンプを吐き出す。
2. コンパイラ最適化と「パックデシマルの符号」の罠
マイグレーション時に特に注意すべきなのが、`DECIMAL` 関数の挙動とDB2（SQL）とのインターフェースだ。
PL/Iの `FIXED DECIMAL` は内部的に「パック10進数（COMP-3）」で表現される。これは最下位バイトのニブル（4ビット）に符号情報（`C`=正, `D`=負）を持つ形式だが、外部データや他言語から流れてきたデータが、稀に「正の符号」として `F` や `A` を持っていることがある。
/i
/ 独自ルーチンでバイナリ操作を行う場合のエッジケース /
DCL PTR POINTER;
DCL BASED_DEC FIXED DEC(5,0) BASED(PTR);
/
もしポインタ操作で外部データを強引にパックデシマルとして解釈する場合、
符号が ‘C’ 以外（例: ‘F’）だと、PL/Iの算術演算で予期せぬ挙動を示す。
特にCICS環境でのオンライン更新時、DB2へ値を渡す前に
DECIMAL関数で再精査しないと、不正なパック形式としてSQLCODE -802が発生する。
/
この「符号反転バグ」は、ダンプ解析で最も骨が折れるポイントの一つだ。ダンプ上の値が論理的に正しくても、バイト単位で見ると符号が異なっている。これを防ぐには、データを受け取った直後の「正規化」が必須となる。
3. マイグレーション時の設計思想：Java/C#への架け橋
もし君が今、PL/IからJava/C#への移行をリードしているなら、以下の点に留意してほしい。
1. 暗黙の型変換を排除せよ: PL/Iは「コンテキストに応じた暗黙の型変換」が非常に強力だが、これはJavaの `BigDecimal` では全く挙動が異なる。PL/Iの `DECIMAL(X, p, q)` に対応するロジックを移行する際は、必ず `RoundingMode` と `Precision` を明示的に設定したクラスを設計し、PL/Iの仕様をコードに焼き付ける必要がある。
2. 固定小数点演算の再現: `FIXED BIN` はCPUのレジスタ演算で高速だが、`FIXED DEC` はソフトウェア（ライブラリ）による演算になる。移行先で `double` や `float` を使って「何となく計算が合う」状態にするのは、精度の欠落を招く禁じ手だ。必ず `java.math.BigDecimal` を使用せよ。
3. ABENDへの敬意: PL/Iの `ON FIXEDOVERFLOW` ブロックで行っていたエラーハンドリングは、移行先では例外処理（`try-catch`）に置き換わる。しかし、汎用機のように「その場でリカバリして処理を続行する」という設計は、分散環境では整合性破壊の元になる。どのタイミングでトランザクションをロールバックするか、設計レベルでの見直しが不可欠だ。
最後に：スペシャリストの心得
PL/Iは、プログラマに「機械を制御している」という実感を強く与えてくれる言語だ。`DECIMAL` 関数ひとつとっても、それが単なる数値変換ではなく、メモリアドレス上の数バイトの操作を指していることを忘れてはならない。
レガシー移行は、コードの書き換えではない。「なぜこの桁数なのか」「なぜこの符号なのか」という、先人たちが何十年もかけて積み上げた「ビジネスの制約」を、現代のアーキテクチャに再定義する作業だ。
ダンプを読み、コンパイラの最適化オプションを疑い、ビット単位の真実を追う。それこそが、この世界で生き残るシステムアーキテクトの矜持だと私は思う。もし変換ロジックで迷ったら、まずは実行時の `SYSUDUMP` を覗き、そのバイト列が何を語っているか、耳を傾けてみてほしい。答えは必ず、そこにある。
