PL/I「PICTURE」の深淵と、Java移行における泥沼の回避術
メインフレームの心臓部で数十年生き抜いてきたPL/Iのコードを眺めていると、時折、設計者の執念を感じる記述に出会う。その筆頭が`PICTURE`（PIC）句だ。
「単なる編集用マスク」と侮ってはいけない。PL/IのPICは、データ定義と表示形式を不可分なものとして一体化し、コンパイラがその場で機械語レベルの編集命令を生成する。一方、Javaの`DecimalFormat`や`String.format`は、実行時にオブジェクトを生成し、ロケールを考慮しながら文字列を構築する。この「静的コンパイルによる直結」と「動的なオブジェクト生成」のギャップが、移行プロジェクトで最も血を流すポイントとなる。
1. PIC編集の「魔力」とJavaでの再現限界
PL/Iの`PIC ‘ZZ,ZZ9.99’`のような記述は、数値のゼロ抑制（Zero Suppression）だけでなく、符号の扱い、浮動小数点との混在、さらには内部的なパック10進数（COMP-3）の変換をシームレスに行う。
特に厄介なのは、「符号の反転」だ。メインフレームの帳票出力プログラムで、負の値を`’999-‘`のような形式で出力している場合、Java側で単純に`abs()`してマイナス記号を付与するだけでは、ビジネスロジックの要件（例えば、ゼロの場合は空白にするのか、あるいは特定のエッジケースで符号がどう振る舞うか）を満たせないことがある。
PL/Iのコード例
/i
/ 内部的にはパック10進数で保持された金額データ /
DCL AMOUNT FIXED DECIMAL(7,2) INIT(-123.45);
DCL EDIT_FLD PICTURE ‘ZZ,ZZ9.99-‘;
/ コンパイラが効率的な編集機械語を生成 /
EDIT_FLD = AMOUNT;
/ 出力結果: ‘ 123.45-‘ /
2. Java移行における設計の勘所
Javaへ移行する際、この挙動を完璧に再現するには、`java.text.DecimalFormat`のインスタンスを使い回すだけでは不十分だ。高負荷なバッチ処理であれば、スレッドセーフではない`DecimalFormat`を`ThreadLocal`で管理するか、あるいはプリミティブな文字配列操作（`char[]`）による自前実装を検討する必要がある。
特に、パック10進数の内部符号バグは、移行エンジニアを絶望させる。EBCDIC上の符号（`X’C’`や`X’D’`）が、ASCII/Unicode環境での変換時に化けるケースだ。DB2から取得した値をJavaの`BigDecimal`にマッピングする際、符号ビットが適切に処理されているか、単体テストで網羅できる範囲を超えた「運用データ」の深淵を覗く覚悟が必要だ。
3. ダンプ解析と最適化の視点
PL/Iプログラムが`S0C7`（データ例外）でアベンドしたとき、原因の多くはPIC定義と実際のデータ値の乖離にある。パック10進数の領域に非数値が入っている場合、コンパイラが生成した編集用コードは容赦なく例外を吐く。
Java移行後、もし同様のバグを再現しようとすると、`NumberFormatException`が飛ぶことになるが、メインフレームなら「メモリダンプからレジスタ内の値を特定し、なぜその値が入ったのか」を追跡できる。しかし、Javaのヒープダンプやスレッドダンプで同様の追跡を行うには、高い習熟度が必要だ。
推奨する移行アプローチ
- 共通ライブラリ化: 編集ロジックをプロジェクト固有の`Formatter`クラスに集約し、JUnitで全パターンを網羅する。
- 符号の明示的処理: `BigDecimal`を使用する際は、必ず`signum()`をチェックし、PL/IのPIC仕様と合致する符号付与ロジックをハードコーディングで分離する。
- パフォーマンスチューニング: 数千万件のレコードを扱うバッチにおいて、`DecimalFormat`の多用はGC（ガベージコレクション）を圧迫する。必要に応じて、数値から直接`byte[]`を生成するような「低レイヤー」な編集メソッドを用意することも、スペシャリストとしての矜持だ。
結論：レガシーは「仕様」ではなく「歴史」である
PL/IのPIC句をJavaに移植するということは、単に文字列のフォーマットを合わせる作業ではない。それは、何十年も前に書かれた「そのプログラムが許容していたデータの曖昧さ」までをも新システムに引き継ぐか、あるいは厳格に排除するかという政治的決断を伴う。
アーキテクトに求められるのは、最新のJavaライブラリの知識だけではない。メインフレームのコンパイラが生成していた機械語の挙動を脳内でシミュレートし、移行先のシステムが「正しく動く」こと以上に「正しく異常を検知できる」設計に仕上げることだ。
次にコードをリファクタリングする際、その1行が「単なる数値変換」ではなく、基幹システムの信頼性を担保する「防壁」であることを思い出してほしい。技術は変わっても、システムが守るべき論理の堅牢さは不変なのだから。
