パック10進数（COMP-3）の深淵：PL/Iにおける `FIXED DECIMAL` の実像とマイグレーションの罠
メインフレームの現場で長年システムを見守ってきたアーキテクトであれば、夜間バッチの数値演算における1円の狂いも許されない厳格な世界をよくご存じだろう。COBOLにおける `COMP-3`、そしてPL/Iにおける `FIXED DECIMAL(p, q)`。これらは、金融計算で避けて通れない「10進演算（Decimal Arithmetic）」をハードウェアレベルで支える基幹の要である。
JavaやC#といったモダン言語の浮動小数点数（`float`/`double`）や、単なる固定長バイナリ（`int`/`long`）に慣れ親しんだ世代のエンジニアが、レガシーマイグレーションの現場で最初に躓くのが、このパック10進数の内部表現とアライメント、そして符号の扱いだ。
今回は、PL/Iプログラムにおける `FIXED DECIMAL(p, q)` のメモリ上の実態を暴き、コンパイラの最適化、アベンド解析、さらにはDB2やCICSが絡むエッジケース、そしてモダン環境への移行設計に至るまで、実務に直結する知見を深く掘り下げていこう。
—
1. メモリ上の実像：なぜ `FIXED DECIMAL` なのか
PL/Iの `FIXED DECIMAL(p, q)`（属性としては `DECIMAL FIXED` とも記述される）は、IBMアーキテクチャ（System/390, z/Architecture）の「パック10進数形式」に直接マッピングされる。
- p（精度 / Precision）: 全体の桁数（1〜31）
- q（スケール / Scale）: 小数点以下の桁数
パック10進数は、1バイト（8ビット）の中に2つの10進数字（ニブル / 4ビットずつ）を詰め込み、最後の1ニブルに符号（Zone/Sign）を置くフォーマットである。例えば、`FIXED DECIMAL(5, 2)` の変数が持つ数値 `+123.45` は、メモリ上で以下のように表現される。
[ 01 ][ 23 ][ 45 ][ 1C ] (16進数表現のイメージ)
↑ ↑ ↑ └ 符号 (C = 正、D = 負、F = 符号なし/デフォルト正)
桁1 桁3 桁5
桁2 桁4 小数
この構造により、バイナリ変換による「丸め誤差」が一切発生しない。金融系システムが何十年もの間、このデータ型に全幅の信頼を置いてきた理由はここにある。
ベース変数とポインタによる動的操作の危険な魅力
PL/Iの強力な機能の一つに、`POINTER` と `BASED` ストレージクラスを用いた動的メモリ操作がある。通信電文や可変長レコードを解析する際、以下のようにパック10進数を直接マッピングすることがある。
DCL 1 PACT_RECORD BASED(P_REC_PTR),
3 ACCT_NO CHAR(8),
3 TRANS_AMT FIXED DECIMAL(11,2) COMP-3; / 6バイトのパック領域 /
Dcl P_REC_PTR PTR;
ここで注意すべきは、アライメント（境界調整）である。PL/Iコンパイラはデフォルトで効率的なメモリアクセスのために変数を特定の境界（2バイト、4バイト、8バイト境界）に配置しようとする。しかし、`BASED` 変数や構造体をポインタ経由で不正なアドレス（奇数アドレスなど）に割り当てると、z/ArchitectureのCPUは S0C4（Protection Exception） や S0C7（Data Exception） を容赦なくスローする。特に通信エリアのオフセット計算を誤ったポインタ操作は、夜間バッチの最も厄介なバグの温床となる。
—
2. コンパイラオプションと演算時の暗黙的変換コスト
PL/Iコンパイラ（Enterprise PL/I）は非常に高度な最適化を行うが、データ属性が異なる変数同士の演算が混ざると、裏で大量のコードが生成される。
例えば、`FIXED DECIMAL` と `FIXED BINARY`（いわゆる `COMP` や `COMP-4`）を混在させた演算を記述した場合を考えてほしい。
DCL V_DEC FIXED DECIMAL(9,2);
DCL V_BIN FIXED BIN(31);
DCL V_RES FIXED DECIMAL(9,2);
V_RES = V_DEC + V_BIN; / ここにコンパイラの暗黙的変換の罠がある /
コンパイラは `V_BIN` を一時的に10進数に変換（CVB/CVD命令の対比ような内部ルーチン）してから加算を行う。大規模なバッチ処理のループ内でこれが何百万回も実行されると、CPUサイクルの無駄遣い（パフォーム低下）だけでなく、桁あふれ（Overflow）のチェック処理によって予期せぬオーバーヘッドを生む。
最適化オプションの勘所
コンパイラオプションで `OPTIMIZE(2)` や `OPT(FULL)` を指定する際、算術演算のシームレスな最適化はありがたいが、元のデータ定義が曖昧だと、コンパイラが予測不能なレジスタ割り当てを行い、ダンプ解析を困難にさせることがある。アーキテクトとしては、算術演算の左右のオペランドのデータ属性は常に一致させるコーディング標準を徹底すべきである。
—
3. アベンド解析の現場：S0C7 (Data Exception) の深層
メインフレームの運用保守において、最も恐れられ、かつ最も頻繁に遭遇するのが S0C7アベンド だ。これは、CPUがパック10進数として不正なデータを読み込んで演算しようとした瞬間に発生する。
なぜS0C7は起きるのか？
1. 初期化不良: `UNSPEC` や `STRING` 組み込み関数で領域をクリアした際、全ビット `0x00` やスペース（`0x40`）のまま `FIXED DECIMAL` として演算に使用した。
2. 外部ファイル・DBの文字化け: 移行期における文字コード（EBCDICとASCII）のミスマッチや、未定義の空白文字がパック領域に流れ込んだ。
3. 符号ニブルの破壊: 最後の4ビットが `C`, `D`, `F` 以外の不正な値（例: `A` や `E` など）に変質した。
ダンプリーディングの実践
SYSUDUMPやCEEDUMPを手にしたとき、私たちはPSW（Program Status Word）のアドレスから該当するPL/Iのステートメントを特定し、ストレージダンプ（Storage Dump）から問題の変数の領域を特定する。
パック10進数の領域に `404040404040`（スペースのEBCDIC表現）が入り込んでいるのを見つけた瞬間、「あぁ、また未初期化のワークエリアか」と溜息をつくのがレガシーエンジニアの日常である。PL/Iでは、変数の宣言時に `INIT` 属性を付与するか、コンパイラオプションの `INIT` を有効にしておくことが、S0C7に対する最高の防衛策となる。
—
4. エッジケース：埋め込みSQL (DB2) と CICSオンライン処理
基幹システムのPL/Iは、単体で動くことは少なく、DB2やCICSと密に結合している。ここでパック10進数は独自の挙動を示す。
DB2ホスト変数としての振る舞い
DB2のテーブル定義で `DECIMAL(p, q)` または `NUMERIC(p, q)` と定義されている列は、PL/I側では必ず `FIXED DECIMAL(p, q)` としてホスト変数にマップする必要がある。
Dcl 1 EMP_REC,
3 EMP_ID CHAR(5),
3 EMP_SAL FIXED DECIMAL(9,2); / DB2の DECIMAL(9,2) と完全一致させる /
/ SQL埋め込み /
EXEC SQL
SELECT SALARY INTO :EMP_SAL
FROM EMPLOYEE
WHERE EMP_ID = :EMP_ID;
もしここで桁数や小数点位置（p, q）の定義を誤ると、DB2プリコンパイラやランタイム（DSNX…）はエラーを返すか、最悪の場合、サイレントに切り捨て（Truncation）が発生し、データベースの数値が静かに破損する。移行設計では、DBの型定義とPL/Iの変数宣言の完全なマトリクス検証が不可欠である。
CICSにおけるコミット境界とパック10進数
CICSの通信エリア（DFHCOMMAREA）や一時記憶キュー（TSQ）を介してデータをやり取りする際、領域のレイアウトがズレると、パック10進数の符号位置が別のデータの先頭文字に侵食し、オンライン画面が突如としてS0C7でクラッシュするというドラマ（悪夢）が起きる。特にCOBOLからPL/Iへ、あるいはその逆の混成環境において、コンパイラの構造体パディング（境界合せ規則）の違いによるズレは、ベテランアーキテクトをも悩ませるポイントだ。
—
5. レガシーマイグレーションの設計視点：Java / C# への脱却
現在、多くの企業がメインフレームからの脱却（ダウンサイジング / クラウド移行）を進めている。ここで最大の難所の一つが、この `FIXED DECIMAL(p, q)` の移行である。
Javaに移行する場合、自然な選択肢は `java.math.BigDecimal` である。
// Javaにおける FIXED DECIMAL(9,2) のマッピング例
BigDecimal empSal = new BigDecimal(“0.00”);
マイグレーションにおける注意点
1. 丸めモード（Rounding Mode）の差異:
メインフレームのハードウェア演算は「切り捨て（Truncate）」や「代数的一般丸め」がハードウェア仕様に依存する。Javaの `BigDecimal` では、明示的に `RoundingMode` を指定しないと、予期せぬ丸め例外（`ArithmeticException`）が発生するか、結果の末尾が微妙にズレる。
2. パフォーマンスの懸念:
バイナリ演算（`int`/`long`）に比べ、`BigDecimal` はオブジェクト生成と多倍長演算のコストがかかる。膨大な件数を処理するバッチ基盤をJavaで再構築する場合、適切なメモリ管理とプリミティブ型への置き換え可能性（許容される誤差の範囲内での `long` 活用など）のトレードオフをアーキテクトが慎重に見極める必要がある。
3. データファイルのコンバージョン:
VSAMやSequentialファイルに格納された生データのパック10進数（COMP-3）を、オープン系で読めるようにアンパック（Unpack）し、さらにEBCDICからASCII（UTF-8）へ変換するETLパイプラインの設計は、移行プロジェクトの成否を分ける。バイナリレベルのパーサを自作するのか、既存のミドルウェア製品を活用するのか、熟練の判断が求められる。
—
結びにかえて
PL/Iの `FIXED DECIMAL(p, q)` とパック10進数表現は、単なる古いデータ型ではない。それは、ハードウェアの限界と効率を極限まで引き出し、企業の信頼を数十年間にわたって支え続けてきたエンジニアリングの結晶である。
その背後にあるメモリ構造、アライメント、コンパイラの挙動、そしてエラーハンドリングの哲学を理解せずに、単なる「古い文法」として機械的にモダン言語へ置き換えようとすれば、必ずや本番稼働後のデータ不整合という名のしっぺ返しを喰らうことになる。
システムアーキテクトたる者、表面的ではなく、そのバイナリの1バイト、符号の1ニブルに宿る意味を見据えた上で、堅牢な移行アーキテクチャを構築してほしい。
