メインフレームの遺産を紐解く：PL/Iの「クセ」を理解し、Java移行の壁を乗り越える
こんにちは。長年、IBMメインフレームの深い森でコードと格闘してきたシステムアーキテクトです。
今、多くの現場で「PL/IからJavaへのマイグレーション」という大プロジェクトが進行しています。PL/Iは、1960年代に生まれた非常に多機能で「なんでも屋」な言語です。COBOLの事務処理能力と、FORTRANの科学計算能力、さらにはアセンブラのような低レイヤー操作までを兼ね備えた、いわば「重戦車」のような存在。
初めてPL/Iのコードを見たとき、その独特の記法に圧倒された方も多いのではないでしょうか？今日は、皆さんがJavaへの移行で最も頭を悩ませる「データ型の壁」について、現場の知見を交えて優しく解説します。
—
1. PL/Iの基本構造：まずは「ここ」から
PL/Iのプログラムは、大きく分けて `PACKAGE` と `PROCEDURE` で構成されます。
/i
/ プログラムの入り口を定義します /
MY_PROGRAM: PROCEDURE OPTIONS(MAIN);
/ ここに処理を書きます /
PUT SKIP LIST(‘Hello, Mainframe World!’);
END MY_PROGRAM;
Javaの `public static void main` に相当するのが `OPTIONS(MAIN)` です。PL/Iの特徴は、この中で変数を自由に宣言できる柔軟性にあります。しかし、この「自由さ」がJavaへの移行時には逆に足かせとなるのです。
—
2. Java移行の最大の難所：FIXED DECIMALの正体
PL/Iでよく見かけるのが、`FIXED DECIMAL` や `PICTURE` 属性です。
/i
/ 10桁の数字、小数点以下2桁を確保 /
DCL AMOUNT FIXED DECIMAL(10, 2);
/ PICTURE句を使った宣言（COBOLのPICに近いですね） /
DCL ACCT_NO PIC ‘99999999’;
なぜこれがJavaで苦労するのか？
Javaの `BigDecimal` を使えば解決すると思われがちですが、実は「メモリレイアウト」と「演算の振る舞い」に大きな落とし穴があります。
- PL/Iの場合: `FIXED DECIMAL` は「パック10進数（Packed Decimal）」としてメモリ上に詰め込まれます。これはハードウェアが直接計算できる形式であり、小数点以下の精度管理が極めて厳密です。
- Javaの場合: `BigDecimal` はオブジェクトです。メモリ消費量はPL/Iの比ではなく、さらに計算のたびに新しいインスタンスが生成されるため、高頻度なバッチ処理ではGC（ガベージコレクション）が頻発するリスクがあります。
現場からのアドバイス：
単に `BigDecimal` に置き換えるだけでなく、その変数が「計算用」なのか「単なるID表示用」なのかを厳密に切り分けてください。ID（口座番号など）であれば、数値型ではなく `String` として扱うのが、Java移行における最も安全な定石です。
—
3. 「奇妙な宣言」に惑わされないために
PL/Iには、他の言語ではあまり見ない「属性の省略」という文化があります。
/i
/ 型を指定しないと、なんと「FLOAT DECIMAL」という浮動小数点として扱われます /
DCL BALANCE;
初心者が一番ハマるのがこれです。金融システムで `BALANCE`（残高）を宣言したつもりが、実は浮動小数点型になっていて、計算のたびに0.000000001のような誤差が出る……。これは現場では「即死案件」です。
移行作業を行う際は、必ず `DEFAULT(FIXEDBIN | FIXEDDEC)` のようなコンパイラオプションを確認し、プログラム内で全変数の型を明示的に宣言する（`DCL`を徹底する）ところから始めてください。
—
4. 移行を成功させるための「心構え」
Javaへのリプレイスは、単なるコードの翻訳ではありません。「PL/Iという重戦車がハードウェアを直接叩いていた世界」を、「Javaという仮想マシン上で動くオブジェクトの世界」へ翻訳する作業です。
1. 精度を疑え: PL/Iの `FIXED DECIMAL` とJavaの `BigDecimal` では、割り算の際の丸めモード（Rounding Mode）の既定値が異なります。必ずテストケースで結果を突き合わせてください。
2. レイアウトを意識せよ: 外部ファイル（VSAMなど）とのやり取りがある場合、Java側で `ByteBuffer` を使ってバイナリデータを操作する必要が出てきます。ここが一番の難所です。
最後に
PL/Iは難解で古臭いと感じるかもしれません。しかし、その厳密さは「金銭を扱うシステム」においては非常に理にかなった設計です。Javaへ移行する際も、PL/Iが持っていたその「堅牢さ」という魂を、しっかりとJavaのコードに受け継いでいきましょう。
もし移行作業で行き詰まったら、一度マニュアルを開いて、その変数が「何のためにそこに存在しているのか」をPL/Iの文脈で読み解いてみてください。答えは必ずそこにあります。
これからもメインフレームとJavaの架け橋として、皆さんのシステム開発を応援しています。何かあれば、またいつでも相談してくださいね。
