現場の視点：PL/IのPIC編集をJavaへ――「単なる置換」で終わらせない移行の流儀
長年メインフレームの保守に関わっていると、必ずぶち当たる壁がある。それが「PL/IのPICTURE指定と、Javaの型変換の微妙なズレ」だ。
「`PIC ‘ZZZ,ZZ9.99’`なんて、`DecimalFormat`で一発だろ？」と高を括っていると、後から必ず泣きを見る。バッチ処理の帳票出力や、VSAMから読み出した生データの編集において、PL/Iが暗黙的に行っている「型変換の魔法」は、Javaの標準ライブラリだけでは再現しきれないケースが多いからだ。
今日は、ベテランの視点から、この移行における「落とし穴」と正しい実装の考え方を紐解いていこう。
—
1. なぜPL/IのPIC編集は「最強」なのか
PL/Iの強力な点は、宣言と同時に出力形式が確定する点にある。例えば、以下のコードを見てほしい。
/ ————————————————————- /
/ PL/Iによる数値編集の基本例 /
/ ————————————————————- /
DCL WS-AMOUNT FIXED DEC(7, 2);
DCL WS-EDIT-AMT PIC ‘ZZZ,ZZ9.99’;
WS-AMOUNT = 1234.56;
WS-EDIT-AMT = WS-AMOUNT; / ここで自動的に編集が行われる /
PUT SKIP LIST (WS-EDIT-AMT); / 出力: ” 1,234.56″ /
この`PIC ‘ZZZ,ZZ9.99’`における`Z`（ゼロ抑制）やコンマ挿入の挙動は、データが`FIXED DEC`であれば、コンパイラが最適なアセンブラ命令を生成して処理してくれる。Javaへの移行時にこれを`DecimalFormat`で変換する場合、単にフォーマットパターンを合わせるだけでは不十分だ。特に、「ゼロ抑制の制御」と「符号の扱い」において、メインフレームの仕様とJavaの挙動には無視できないギャップがある。
—
2. Java実装における「落とし穴」：ゼロ抑制と負数
Javaで`DecimalFormat`を使う際、最も注意すべきは「数値が0のとき、出力が空文字になるのか、それとも ‘0’ と表示されるのか」という仕様だ。
PL/Iの`PIC ‘ZZ9’`は、値が0のとき` 0`と出力するが、`PIC ‘ZZZ’`であれば完全に空白になる。一方、Javaの`DecimalFormat`はパターン文字列の定義次第で挙動が変わる。
実践的アプローチ：ユーティリティクラスでの標準化
マイグレーション先のJavaプロジェクトでは、以下のような変換ロジックを共通化し、チーム全体で「PL/Iと同じ挙動」を強制するべきだ。
// Javaでの実装例：PL/IのPIC編集を模倣するヘルパーメソッド
public static String formatPic(BigDecimal value, String pattern) {
if (value == null) return ” “; // PL/I的なNULLハンドリング
DecimalFormat df = new DecimalFormat(pattern);
// PL/IのPIC編集において、負数の扱いは重要
// 必要に応じて、負数の場合に符号を付けるロジックをカスタム追加する
return df.format(value);
}
ここで重要なのは、「例外処理をONユニット的に設計する」という考え方だ。PL/Iでは`ON CONVERSION`を使用して、変換エラーをキャッチし、不正データを空白に置換するような制御が一般的だった。Java移行時も、単に`NumberFormatException`を投げてバッチを異常終了させるのではなく、メインフレーム側の運用ロジックを踏襲した「安全な変換」を実装する必要がある。
—
3. VSAMと入出力：構造体の整合性をどう守るか
メインフレーム移行で最も危険なのが、VSAMのレコード定義（Copybook）をJavaのDTOに変換する際、`PIC`属性の解釈を誤ることだ。
特に`PIC ‘S9(7)V99’`のような符号付き数値は、パック10進数（COMP-3）として物理的に格納されていることが多い。これをJavaの`BigDecimal`に引き継ぐ際、変換ミスがあると、下位桁のビット化けを招く。
現場のコツ：変換テストの自動化
1. ダンプ比較: PL/Iの出力結果と、Java変換後の結果を、1バイト単位でバイナリ比較するツールを通すこと。
2. 符号の反転: PL/Iの`PIC`で`CR`や`DB`が付加されている場合、Java側で計算不能にならないよう、前処理で符号を正規化するメソッドを通すのが定石だ。
—
結論：システムアーキテクトからのアドバイス
「PL/IからJavaへ」という移行プロジェクトは、単なるプログラミング言語の置き換えではない。それは、「メインフレームが数十年かけて培ってきたデータの整合性管理を、現代の言語仕様でいかに再構築するか」という思想の移行だ。
現場の後輩エンジニアたちに伝えたいのは、「仕様書にあるロジックをそのまま写すのではなく、そのPICTURE句が『なぜ』その形式で定義されているのかという意図を汲み取れ」ということだ。
エラー処理、ゼロ抑制、符号の取り扱い。これら一つ一つを丁寧にJavaのクラス設計に落とし込むことで初めて、移行後のシステムは「メインフレーム時代のように堅牢な」バッチ処理を実現できる。
もし、移行先で数値編集の結果が微妙にズレるという怪奇現象に遭遇したら、まずは`DecimalFormat`のパターン文字列ではなく、入力データ側の「型」と「ゼロ抑制の意図」を疑ってほしい。現場の勘と、PL/Iの厳格な仕様への敬意があれば、必ず解決の糸口は見つかるはずだ。
次は、ONユニットの制御フローをJavaの例外ハンドリングにどう落とし込むかについて、もう少し掘り下げてみようと思う。現場からは以上だ。
