【メインフレーム脱却の深淵】PL/IからJavaへ、数値と文字の「亡霊」を葬る技術
長年メインフレームの保守に身を捧げてきた諸君なら、一度は頭を抱えたことがあるだろう。「PL/Iのあの動き、Javaでどう再現すればいいんだ？」と。
現代のオープン化プロジェクトにおいて、我々メインフレーム技術者が直面する最大の壁は、単なる構文の翻訳ではない。EBCDICの呪縛と、PL/I特有の厳密な数値表現を、いかにしてJavaという柔軟すぎる世界へ安全に着地させるかだ。今日は、最も現場を混乱させる「データ型マッピング」の核心に切り込む。
—
1. FIXED DECIMALの「誤差」という罠
PL/Iの `FIXED DECIMAL(p, q)` は、単なる数値ではない。これはCOBOLの `COMP-3` と同様、10進演算をハードウェアレベルで担保する「正義」だ。これをJavaの `BigDecimal` に安易に放り込むと、マイグレーション後のバッチで必ず「端数誤差」という名の爆弾が炸裂する。
PL/I側の典型的な定義例
/ 勘定系システムでの金額フィールド例 /
DCL TOTAL_AMT FIXED DEC(15, 2) INIT(0);
DCL TAX_RATE FIXED DEC(5, 4) INIT(0.0800);
Javaへの移行における鉄則
Javaの `BigDecimal` を使用する際、最も重要なのは `RoundingMode`（丸めモード）の明示的な指定だ。PL/Iは演算過程でハードウェアが暗黙の丸めを行うが、Javaは何も指定しなければ `ArithmeticException` を吐くか、デフォルトの挙動で計算を続行してしまう。
// 正しいBigDecimalの扱い方
BigDecimal totalAmt = new BigDecimal(“1000.00”);
BigDecimal taxRate = new BigDecimal(“0.0800”);
// PL/Iの FIXED DEC(15, 2) 相当の精度と丸めを強制する
BigDecimal result = totalAmt.multiply(taxRate)
.setScale(2, RoundingMode.HALF_UP);
現場で最も多いトラブルは、「PL/Iの演算仕様（切り捨て・四捨五入）を調査せず、Java側でデフォルトの丸めモードを使ってしまう」ことだ。必ず旧ソースの `(p, q)` を確認し、その計算精度がどの時点で確定するのかを紐解く必要がある。
—
2. EBCDICからUnicodeへの「不可逆な変換」
VSAMやQSAMから読み込んだデータがEBCDICである以上、Java側での文字コード変換は避けて通れない。ここで注意すべきは、`DISPLAY` 属性の数値や、特殊なパック形式の領域だ。
VSAM読み込み時の落とし穴
PL/Iでは `STRUCTURE` で型を定義し、レコードを読み込む。ここで `PIC ‘999V99’` と定義された領域を、生のテキストファイルとして読み込むと悲惨なことになる。
/ VSAMレコード定義のイメージ /
DCL 1 RECORD_AREA,
3 KEY_ID CHAR(10),
3 PRICE FIXED DEC(7, 2), / 4バイトのパック10進数 /
3 FLAG BIT(8); / 1バイトのバイナリ /
この `PRICE` をJava側で `String` として読み込んでから `Integer.parseInt()` するなど言語道断だ。「バイナリデータはバイナリのまま読み込み、Javaの `ByteBuffer` 等で制御する」。これが鉄則である。文字コード変換を行うのは `KEY_ID` のような純粋なテキストデータのみに絞らねばならない。
—
3. ONユニットの制御フローと例外処理
PL/Iの `ON` ユニットは非常に強力だが、Javaの `try-catch` とは哲学が異なる。`ON SIZE` や `ON UNDERFLOW` は、メインフレームの堅牢なバッチ処理を支えてきた。
PL/Iの例外制御
/ ゼロ除算が発生した際の制御フロー /
ON ZERODIVIDE BEGIN;
PUT SKIP LIST(‘警告: ゼロ除算が発生しました。ログに記録し処理を継続します。’);
/ ここで代替値をセットして戻る /
RESULT = 0;
GOTO NEXT_PROCESS;
END;
/ 演算処理 /
RESULT = DIVIDEND / DIVISOR;
NEXT_PROCESS:;
Javaに書き換える際、これを単なる `catch` ブロックで囲むだけでは不十分だ。PL/Iの `GOTO` を使った復帰フローを、Javaの設計思想（チェック例外の適切なハンドリングとステート管理）に翻訳する必要がある。特にバッチの継続性を重んじる場合、`Result` クラスを作成し、例外発生フラグを保持するような設計を推奨する。
—
最後に：ベテランからの提言
PL/IからJavaへのリプレイスは、コードの書き換えではない。「メインフレームのハードウェアに依存していた厳密さを、ソフトウェアの設計でどう担保するか」という戦いである。
- `FIXED DEC` は常に `BigDecimal` で、かつ `RoundingMode` を固定せよ。
- VSAMのレコード構造は `Byte` 配列として捉え、EBCDICとUnicodeの境界線を死守せよ。
- PL/Iの `ON` ユニットの意図を汲み取り、Javaの例外ハンドリングとして再定義せよ。
我々メインフレームエンジニアの経験値は、単なる古い知識ではない。数万件のバッチを止めてはならないという「責任」の歴史だ。その魂を、新しいJavaのコードベースに吹き込んでやってほしい。
健闘を祈る。何かあれば、またいつでも相談に来るといい。
