パック10進数の罠：PIC ‘S’ 符号付き数値の内部表現とモダン移行の急所
メインフレームの基幹システムで長年稼働してきたPL/Iプログラムの保守や、Java/C#へのマイグレーション（レガシー移行）に直面したとき、多くのエンジニアが最初に頭を悩ませるのが「データの裏側にあるビットと符号の解釈」だ。
特に `PIC ‘S’` で定義された符号付き数値、そしてそれを `COMP-3`（パック10進数）としてメモリ上に展開した際の挙動は、オープン系言語の常識が全く通用しない魔窟と言っていい。C言語の `int` や Java の `int`/`long` とは異なり、PL/Iの算術型は十進演算（Decimal Arithmetic）をベースにしており、ハードウェア（IBM Z）のS/370アーキテクチャレベルで最適化されている。
今回は、この `PIC ‘S’` 符号付き数値とパック10進数の内部表現の仕組みを極め、アベンド解析からモダンマイグレーションにおける致命的なバグを防ぐための知見を共有しよう。
—
1. ゾーン10進数とパック10進数の基本構造
PL/Iにおいて、`PIC ‘S9(4)’` のように定義された変数は、デフォルトでは ゾーン10進数（Zone Decimal / EBCDIC形式） としてメモリ上に保持される。これに対し、`COMP-3`（Computational-3）を指定すると、データは パック10進数（Packed Decimal） に圧縮される。
ゾーン10進数 (`PIC ‘S9(4)’` の場合)
1桁につき1バイト（8ビット）を使用する。上位4ビットがゾーン部（通常は `F`、正負の符号によって変わることもある）、下位4ビットが数値部（ニブル）となる。最後の1バイトのゾーン部には、符号（正なら `C`、負なら `D`、符号なしや初期値なら `F` など）が格納される。
例: `+1234` の場合 → `F1 F2 F3 C4` （4バイト）
パック10進数 (`PIC ‘S9(4) COMP-3’` の場合)
1バイトに2桁の数字（または1桁と符号）を「パック」して格納する。IBMメインフレームの `PACK` / `UNPK` 命令や、演算命令（`AP`, `SP` など）で直接処理される形式だ。
例: `+1234` の場合 → `01 23 4C` （3バイト）
ここで注目すべきは、最後の1バイトの下位ニブル（右端の4ビット）にある符号ニブルだ。
- 正数 (Positive): `C` （または `A`, `E`, `F` が生成されることもあるが、標準は `C`）
- 負数 (Negative): `D`
- 符号なし/ゾーン (Unsigned): `F`
この符号ビットの解釈を誤ると、数値が意図せず反転したり、DB2へのインサート時にSQLCODE -180やデータ例外（S0C7アベンド）を引き起こすトリガーとなる。
—
2. 実践：PL/Iにおけるデータ定義とポインタ操作のエッジケース
基幹システムのバッチプログラムでは、通信域（エリア）やファイルレコードのレイアウトを `UNSPEC` や `ADDR`、さらにはポインタを用いて直接操作することが多々ある。
以下に、ゾーン10進数とパック10進数を混在させ、内部のビットパターンを直接覗き見るようなPL/Iのコード例を示す。
//
/ パック10進数とゾーン10進数の内部表現を検証するサンプルプログラム /
//
TEST_CONV: PROC OPTIONS(MAIN);
DCL 1 W_AREA,
3 W_ZONE_VAL PIC ‘S9(4)’ INIT(+1234), / ゾーン10進数 (4バイト) /
3 W_PACK_VAL PIC ‘S9(4) COMP-3’ INIT(-1234); / パック10進数 (3バイト) /
/ ビットパターンを直接確認するための文字参照用変数 /
DCL DUMP_ZONE CHAR(4);
DCL DUMP_PACK CHAR(3);
/ ポインタとベース変数を用いた高度なメモリ操作 /
DCL P_ZONE POINTER;
DCL BASED_ZONE CHAR(4) BASED(P_ZONE);
DCL P_PACK POINTER;
DCL BASED_PACK CHAR(3) BASED(P_PACK);
/ 変数のアドレスを取得 /
P_ZONE = ADDR(W_ZONE_VAL);
P_PACK = ADDR(W_PACK_VAL);
PUT SKIP LIST(‘=== 内部表現ダンプ解析 ===’);
/ ゾーン10進数 (+1234) のEBCDIC表現を出力 /
/ 期待値: ‘123’ と 符号付き文字 ‘D’ または ‘C’ に相当するバイト列 /
PUT SKIP EDIT(‘ZONE (+1234) HEX: ‘, UNSPEC(W_ZONE_VAL)) (A, BITS(32));
/ パック10進数 (-1234) のHEX表現を出力 /
/ 期待値: ’01 23 4D’ -> HEX(01234D) /
PUT SKIP EDIT(‘PACK (-1234) HEX: ‘, UNSPEC(W_PACK_VAL)) (A, BITS(24));
/ 符号反転のシミュレーション（パック10進数の下位ニブルを書き換える） /
/ 注意: このようなハックは実務では推奨されないが、データ修復時に必要となる /
END TEST_CONV;
このようなコードで `UNSPEC` を叩くとき、コンパイラがどのようにデータを解釈しているかを把握していないと、マイグレーション時に痛い目をみる。
—
3. コンパイラオプションによる最適化の罠
IBM Enterprise PL/I コンパイラを使用する際、最適化レベル（`OPT(2)` や `OPT(3)`）や、データに関するサブオプション（例: `TRUNC` オプション）が、パック10進数の挙動に微妙な影を落とすことがある。
`TRUNC(STD)` vs `TRUNC(BIN)` / `TRUNC(OPT)`
`COMP`（二進数、すなわち `FIXED BINARY`）に関する設定である `TRUNC` は、十進数（`COMP-3`）そのものには直接影響しないように思われがちだ。しかし、算術演算の中で `COMP-3` から `FIXED BINARY` へ暗黙の型変換（キャスト）が発生する際、`TRUNC(OPT)` が有効になっていると、コンパイラは「ピクチャの桁数を超える値は絶対に入らない」という前提で機械語コードをアグレッシブに最適化する。
もし外部から流入した不正なデータ（例えば、パディングミスやCOBOL側の `COMP-3` 定義のズレによるゴミデータ）が混入していた場合、`TRUNC(OPT)`環境下ではハードウェア例外（S0C7: データ例外）の発生タイミングが変わったり、最悪の場合はサイレント・データコラプション（異常値のまま処理が続行される）を引き起こす。テックリードとしては、レガシーからの移行期には一時的に `TRUNC(STD)` を強制し、厳格なデータチェックを入れるべきである。
—
4. アベンド（S0C7）発生時のダンプ解析の極意
メインフレーム運用者にとって悪夢の代名詞である S0C7（Data Exception）。その大半は、不適切なパック10進数（`COMP-3`）の演算に起因する。
SYSUDUMPやCEEDUMPを解析する際、以下のポイントに注目せよ。
1. PSW（Program Status Word）のインストラクションアドレスを特定し、どのPL/Iステートメント、あるいは生成されたどのマシン語命令（`AP` (Add Packed), `MP` (Multiply Packed) など）で落ちたかを突き止める。
2. レジスタまたはストレージ・ダンプから、問題の `COMP-3` 変数が占める領域を特定する。
3. 符号ニブルのチェック:
- 正常な値であれば、右端の4ビットは `C`, `D`, `F` のいずれか（有効な符号）になっているはずである。
- もしここが `0` から `9` の数字であったり、不審なビットパターン（例: アライメントズレによる隣接データの巻き込み）になっている場合、それは「パックされていないデータ」あるいは「メモリ破壊」を意味する。
特に、CICSオンライン処理のエッジケースにおいて、画面からの入力電文（MAP）を `COMP-3` の領域に誤って文字（ゾーン形式）のままブランクパディングなしで突っ込んだり、REDEFINES（PL/Iの `Based変数` や `Union` 相当の構造）で不整合を起こすと、次の演算瞬間に一瞬でS0C7落ちする。オンラインのトランザクションがアベンドし、ログにダンプが吐き出された瞬間の絶望感は、ベテランなら誰もが知るところだろう。
—
5. Java / C# へのマイグレーションにおける設計上の急所
レガシーマイグレーションの現場で最も多い失敗が、「PL/Iの `PIC ‘S9(4) COMP-3’` は、Javaの `short` や `int` にそのまま置き換えればよい」という安易な設計だ。
ここには大きな落とし穴がある。
1. 十進演算の丸め誤差（Rounding）と桁あふれ:
オープン系言語の二進浮動小数点や整数演算は、COBOLやPL/Iの「十進演算（BCD演算）」とは丸めの挙動が異なる。特に金融系システムで必須となる「四捨五入（ROUNDED）」や「切り捨て」の厳密な再現において、単なる `int` や `BigDecimal` の扱いの違いから、1円の端数ズレ（合算誤差）が発生する。
2. 符号ニブルの消失と不正値のハンドリング:
Javaでバイナリファイルを読み込む際、古いメインフレームから出力されたパック10進数データをそのままパースしようとすると、右端の符号ニブル（`C` や `D`）の処理でつまずく。Java側で独自のバイトシフト演算（`b & 0x0F` で符号を判定し、`b & 0xF0` をシフトして数値化する処理）を実装するか、あるいは移行先のDB（OracleやPostgreSQL）のDecimal型に正しくロードするためのETLロジックを組む必要がある。
3. 埋め込みSQL (DB2 for z/OS) との連携:
PL/I内からDB2を叩く際、ホスト変数に `COMP-3` を使っている場合、DB2の内部データ型（DECIMAL型）と1対1でマッピングされる。これをオープン系のO/Rマッパー（HibernateやEntity Frameworkなど）に移行する際、データベース側のカラム定義（`DECIMAL(p,s)`）とJava側の `BigDecimal` のスケール（Scale）の定義が一致していないと、マイグレーション後にデータ落ちや切り捨てエラーが頻発する。
—
結びにかえて
PL/Iの `PIC ‘S’` と `COMP-3` は、単なる「データ型の指定」ではない。それは、限られたメモリとハードウェアの性能を極限まで絞り出すために先人たちが築き上げた、美しくもスパルタンなアーキテクチャの結晶である。
モダン言語へ移行するプロジェクトであっても、この「裏側のビットと符号の挙動」を理解しているか否かで、移行後の品質とトラブルシューティングのスピードは天と地ほどの差となって現れる。
「なぜこのデータは `D` で終わっているのか」「なぜこのポインタ操作でS0C7が起きるのか」。その問いに即座に答えられるエンジニアこそが、レガシーとモダンの架け橋を渡る真のシステムアーキテクトであると言えるだろう。
