【メインフレーム技術伝承】PL/IからJavaへ：その「型」の壁をどう乗り越えるか
メインフレームの現場で長年戦ってきた諸君なら、一度は耳にしたことがあるだろう。「PL/IのロジックをJavaに書き換える」というプロジェクトだ。一見、オブジェクト指向の現代的な言語に移行すれば全てが解決するように思えるが、実はそこに潜む「データ型の解釈」の差異こそが、システムを崩壊させるトリガーになる。
今日は、特に多くのエンジニアが頭を抱える「FIXED DECIMALの精度」と「ポインタ操作の再設計」について、現場の視点から深掘りしていこう。
—
1. FIXED DECIMALとBigDecimalの「目に見えない」溝
PL/Iの `FIXED DECIMAL` は、COBOLの `COMP-3` と同様、10進演算をハードウェアレベルで正確にこなすためのものだ。一方、Javaの `BigDecimal` は非常に柔軟だが、PL/Iの「桁合わせ（PICTURE指定）」のような厳格な制約を、デフォルトでは持っていない。
現場で遭遇する罠
PL/Iでは `DCL AMT FIXED DEC(15, 2);` と宣言すれば、小数点以下の扱いは自動的に固定される。だが、Javaで単純に `BigDecimal` を使うと、スケール（小数点の位置）が計算結果によって動的に変わってしまう。これにより、VSAMファイルへの書き込み時に精度が合わず、データ不整合が起きる。
PL/Iコード例：実務的な加算処理
/ 15桁、小数点以下2桁の固定小数点数 /
DCL TOTAL_AMT FIXED DEC(15, 2) INIT(0);
DCL WORK_AMT FIXED DEC(15, 2);
/ VSAMファイルから読み込んだデータを加算 /
TOTAL_AMT = TOTAL_AMT + WORK_AMT;
/ 桁あふれを考慮したONユニットによる制御 /
ON CONVERSION BEGIN;
PUT SKIP LIST (‘データ変換エラー発生: 値を確認せよ’);
SIGNAL ERROR;
END;
Javaへ移行する際は、必ず `RoundingMode.HALF_UP` などの丸めモードを明示し、スケールを定数で固定する共通クラスを作成しなければならない。PL/Iの `ON CONVERSION` で拾っていた例外を、Javaの `try-catch` でどう再設計するか。単なる書き換えではなく、エラーハンドリングの哲学を「システム全体」で統一する必要があるんだ。
—
2. ポインタ操作から「参照型」へのパラダイムシフト
PL/Iの強力な機能である `POINTER` と `BASED` 変数。これらはメモリ上の物理アドレスを直接操作できるため、レコードの動的割り当てには非常に便利だが、Javaにはポインタという概念そのものが存在しない。
移行の設計指針
多くの現場で失敗するのは、「ポインタをそのままJavaのメモリ参照としてエミュレートしようとする」ことだ。これは泥沼への入り口だ。Javaでは、ポインタの代わりに「データ転送オブジェクト（DTO）」と「リスト構造」を用いるのが定石となる。
PL/Iのポインタ操作例（構造体マップ）
DCL P_REC POINTER;
DCL 1 REC_STR BASED(P_REC),
2 KEY_ID CHAR(8),
2 DATA_VAL FIXED DEC(10, 0);
/ バッファを取得し、構造体を割り当てる /
ALLOCATE REC_STR SET(P_REC);
/ この後、P_RECをVSAM入出力のインターフェースとして使用 /
この「メモリの重なり」をJavaで再現するには、`ByteBuffer` を使ってバイナリデータをマッピングする方法がある。しかし、保守性を考えれば、素直に `POINTER` を廃止し、VSAM入出力のレイヤーで「Javaオブジェクトへの変換（マーシャリング）」を徹底する設計に切り替えるべきだ。
—
3. 移行を成功させるための「心構え」
最後に、ベテランとして一つアドバイスしておこう。PL/Iの `OPTIONS(MAIN)` プロシージャは、プログラムの入り口として非常に明確な構造を持っている。
MAIN_PROC: PROC OPTIONS(MAIN);
/ 初期化処理 /
CALL INITIALIZE_ENV;
/ メインループ：VSAM読み込みから処理まで /
DO WHILE (NOT_EOF);
CALL READ_VSAM;
/ ロジック実行 /
END;
/ 終了処理 /
CALL TERMINATE_ENV;
END MAIN_PROC;
Javaへ移行する際、この「手続き型」の構造を無理に `Spring` や `Jakarta EE` のDIコンテナに押し込めようとすると、複雑性が爆発する。まずは「PL/Iのロジックが何を成そうとしているか（入出力と計算ルール）」を完全に分離し、次にJavaのオブジェクトモデルに落とし込む。
結論：
PL/Iのコードを眺めるときは、単なる命令列としてではなく、その背景にある「ビジネスルールの厳格さ」を読み取ってほしい。型変換の課題は、単なる構文の置き換え問題ではなく、メインフレームが長年守ってきた「データの整合性」という責務を、新しい言語でどう引き継ぐかという挑戦なんだ。
技術の変遷は激しいが、基幹システムに必要なのは常に「堅牢さ」だ。諸君の移行プロジェクトが、無事に、そして確実に完遂されることを願っている。困ったことがあれば、またいつでも聞きに来てくれ。
