浮動小数点数の奈落：TRUNC関数とレジスタ操作、そしてレガシー移行の罠
メインフレームの現場で長くシステムを見ていると、時折「なぜこんな動きをするのか」と頭を抱えたくなるような、しかしコンパイラの仕様を知っていれば膝を打つ現象に出くわす。
PL/Iという言語は、IBMが1960年代に「科学技術計算も事務処理も、そしてシステム記述もこれ一つで」という野望の元に生み出した、いわば全知全能の怪物だ。C言語のような厳格な予約語の縛りを持たず、文脈によって識別子が予約語にもなれば変数名にもなるという、コンパイラ泣かせの柔軟性を持っている。
今回は、そのPL/Iにおける浮動小数点数（FLOAT）の整数部切り出し、すなわち `TRUNC` 関数の挙動と、その裏で行われているハードウェアレベルのレジスタ操作、そしてJavaやC#へのモダンマイグレーションを見据えたアーキテクト的視点での深掘りをお届けしよう。
基幹システムの数字を扱う処理において、浮動小数点数の丸め誤差や切り捨て処理を軽く見ていると、のちに決算バッチで数円のズレを生んだり、最悪の場合は暗黙のデータ例外（S0C7やS0C4など）で深夜のアベンドを引き起こしたりする。この領域を極めることは、メインフレームアーキテクチャの急所を押さえることに他ならない。
—
1. TRUNC関数の本質と浮動小数点数の内部表現
PL/Iの `TRUNC` 組み込み関数は、引数として渡された数値の小数点以下を切り捨てる。だが、これが `FLOAT` 型（単精度あるいは倍精度）を対象とした場合、コンパイラは単に「小数点以下を消す」という甘い処理はしない。
IBM汎用機（z/Architecture）の浮動小数点レジスタ（FPR）上では、数は正規化された指数部と仮数部で表現されている。`TRUNC(X)` が実行されるとき、裏では以下のようなハードウェア命令の連鎖（あるいはそれに近いインライン展開）が走る。
1. 浮動小数点数をいったん整数レジスタ（GPR：General Purpose Register）へロード可能な形式に変換する。
2. 浮動小数点の指数部をマスクし、小数点を表すビット群を削ぎ落とす。
3. 必要に応じて2の補数表現への変換や、固定小数点（FIXED BINARY / FIXED DECIMAL）への領域アライメント調整を行う。
ここで問題になるのが、「浮動小数点数の精度の限界」である。例えば、非常に大きな桁数を持つ `FLOAT DEC(16)` や `FLOAT BIN(53)` の値を無理やり `FIXED BINARY(31)` に落とし込もうとした際、有効桁数からあふれた下位ビットがどう扱われるか。コンパイラの最適化レベル（`OPT(2)` や `OPT(3)`）によっては、この丸め処理がレジスタ上でアグレッシブに最適化され、期待値と1ビットのズレを生むことがある。
実用コード例：浮動小数点からの安全な切り出しと基底ポインタ操作
以下のPL/Iコードを見てほしい。単に `TRUNC` を呼ぶだけでなく、動的メモリ（ベース変数とポインタ）を組み合わせて、生データレベルでレジスタとメモリの整合性を担保する実践的なパターンだ。
1
/ ————————————————– /
/ 浮動小数点数の厳密な切り出しとポインタ操作サンプル /
/ ————————————————– /
TEST_TRUNC_MODULE: PROC OPTIONS(MAIN);
/ 浮動小数点変数の定義（倍精度） /
DCL W_FLOAT_VAL FLOAT DEC(16) INIT(123456789.987654);
/ 切り出し先の固定小数点変数 /
DCL W_INT_VAL FIXED BIN(31) INIT(0);
/ ポインタとベース変数の定義（動的領域マップ用） /
DCL P_MEM_AREA POINTER;
DCL 1 DUMMY_MAP BASED(P_MEM_AREA),
5 F_PART FLOAT DEC(16),
5 I_PART FIXED BIN(31);
/ ストレージの明示的な割り当て（GET STORAGE） /
ALLOCATE DUMMY_MAP SET(P_MEM_AREA);
/ 値のセット /
F_PART = W_FLOAT_VAL;
/ コンパイラの最適化に依存せず、TRUNC結果を確実に固定小数点へ /
/ ハードウェアのレジスタロードを意識した代入式 /
I_PART = FIXED(TRUNC(F_PART), 31);
DISPLAY(‘元の浮動小数点数 : ‘ || W_FLOAT_VAL);
DISPLAY(‘切り出し後の整数 : ‘ || I_PART);
/ 領域の解放 /
FREE DUMMY_MAP;
END TEST_TRUNC_MODULE;
このコードでは、`BASED` 変数と `POINTER` を用いることで、コンパイラが暗黙的に行うテンポラリ領域の割り当てをプログラマ側で意識し、レジスタとストレージ間のデータ転送コストを最小化している。バッチのループ内で何百万回も呼ばれるサブルーチンであれば、このオーバーヘッドの差がバッチ全体のElapsed Time（経過時間）に直結する。
—
2. アベンド（ABEND）発生時のダンプ解析とエッジケース
もし、この `TRUNC` 処理や数値変換の過程でデータ異常（例えば、すでにパッチ等で汚染された浮動小数点エリアや、初期化漏れの領域）を読み込んだ場合、何が起きるか。
システムは容赦なく ASRA (S0C7) データ例外 または ASRB (S0C1) ]?.異常 を吐き出して異常終了する。
特に恐ろしいのは、パックデシマル（`PACKED DECIMAL` / `COMP-3`）を浮動小数点経由で無理やりキャストしたり、その逆を行ったりする際に発生する内部符号反転バグだ。
パックデシマルの符号ズレとダンプの読み方
メインフレームのDUMP（SYSUDUMPやCEEDUMP）を解析する際、レジスタ（R0～R15）の値やストレージ上の16進数ダンプを確認することになる。
例えば、ゾーン部や符号部（`C`, `D`, `F` 等）が不正な値を持っている状態で `TRUNC` や算術演算をかけると、ハードウェアはプロセッサの例外割り込みを起こす。
- S0C7の兆候: PSW（Program Status Word）のインストラクションアドレスの直前命令が、`CVB`（Convert to Binary）や `CVD`（Convert to Decimal）、あるいは浮動小数点命令（`AE` や `DE` など）である場合、データフォーマットの不一致が原因であると即座に特定できる。
- 対策: 演算の前に必ず `NUMERIC` 組み込み関数や条件判定（例: `IF CHECK(variable)` 的な自前ルーチン）を挟むか、コンパイラオプションで `TRAP(ON)` を明示的に指定し、言語ランタイム側でトラップを捕捉できるように設計すべきである。
—
3. 埋め込みSQL（DB2）およびCICSオンラインにおける罠
この問題はバッチ処理にとどまらない。CICSオンラインや、DB2の埋め込みSQL（ホスト変数）が絡むと、事態はさらに複雑化する。
DB2のテーブル定義で `DECIMAL(15,2)` や `FLOAT` で定義されたカラムを、PL/I側の `FLOAT DEC` や `FIXED BIN` で受け取る際、マイグレーションやデータ型のミスマッチがあると、DB2プリコンパイラは警告を出さずに暗黙の型変換コードを生成することがある。
- CICSのエッジケース: 画面から受け取ったテキストデータ（`CHAR`）を `FLOAT` に変換し、それを `TRUNC` して内部処理カウンタとするようなレガシーロジックにおいて、画面からの入力抜け（スペースやLOW-VALUES）が混入すると、浮動小数点変換ルーチンがクラッシュする。
- 対策: CICSの通信領域（COMMAREA）やマップ定義（BMS）の段階で、数値項目に対する厳格なバリデーション（`VERIFY` 組み込み関数などを使用）を徹底し、未初期化や不正文字の混入を絶対に許さない防衛的プログラミングが不可欠である。
—
4. モダンマイグレーション（Java / C#への移行）におけるアーキテクチャ設計
さて、ここまで読んだアーキテクトやテックリードなら痛感しているはずだ。
「PL/Iで書かれたこの泥臭いレジスタ操作や浮動小数点の丸め処理を、そのままJava（`BigDecimal` や `double`）やC#にどう移植すればいいのか」と。
単純な自動変換ツール（トランスレータ）に頼ると、大抵痛い目をみる。Javaの `double` や `float` はIEEE 754に準拠しているが、Javaの丸めモード（`RoundingMode.HALF_EVEN` や `DOWN` など）と、PL/Iのコンパイラが生成する機械語命令の丸め挙動には微妙な差異が存在する。金融システムにおいて「1円のズレ」は致命傷であり、移行後のパラレルラン（新旧比較テスト）でこの差異が発覚してプロジェクトが炎上するケースを、私たちは何度も目撃してきた。
マイグレーション設計の指針
1. ビジネスロジックの抽象化:
移行先のJava/C#側では、単なるプリミティブ型としての `double` や `float` を直接使わせず、メインフレームの数値演算精度（特に固定小数点と浮動小数点の境界）を完全にエミュレートする共通ユーティリティクラス（例: `LegacyNumericUtil.trunc(…)`）を必ずラップとして用意すること。
2. テストオラクル（検証基盤）の構築:
移行元（PL/I）の実行結果と、移行先（Java等）の実行結果をバイナリレベルまたは16進数レベルで突合できる自動テストフレームワークを構築する。特に、極端な境界値（最大値、最小値、NaN近傍、無限大）における `TRUNC` の挙動を網羅的にテストケースに組み込む必要がある。
—
結びに代えて
PL/Iの基本構文やデータ制御、そして今回のテーマである `TRUNC` 関数の裏側にあるレジスタ操作は、単なる「古い技術の仕様」ではない。そこには、限られたハードウェア資源の中で最大のパフォーマンスと信頼性を絞り出そうとした、先人たちの執念とアーキテクチャの結晶が詰まっている。
レガシー移行を成功させるカギは、コードをただ機械的に読み替えることではなく、「そのコードがメインフレームのどのハードウェア文脈（レジスタ、ストレージ、割り込み）を前提として書かれているか」を完全にハックし、移行先のモダン環境でそれを正しく再定義することにある。
システムアーキテクトとしての腕の見せ所は、まさにこの「深淵なる仕様の通訳」にあるのだ。
