メインフレームの「構造体」をJavaへ解き放つ：PL/Iから移行する際の「メモリレイアウト」という名の呪縛
やあ、後輩諸君。今日も元気にバッチジョブのABENDログと格闘しているかな？
いま、我々の業界で最も熱く、そして最も火傷しやすいトピックといえば「PL/IからJavaへのマイグレーション」だ。長年使い倒してきたVSAMデータセットや、あの複雑怪奇なレベル構造体（Level Structure）を、どうやってオブジェクト指向のJavaに落とし込むか。これが単なる「書き換え」で終わると思ったら大間違いだ。
今日は、PL/Iの構造体をJavaへマッピングする際に、なぜ多くのエンジニアが沼にハマるのか、その技術的核心を突いていく。
—
1. なぜ「メモリレイアウト」を気にする必要があるのか
PL/Iの構造体は、単なるデータの入れ物ではない。ストレージ上の物理的なオフセットを厳密に定義する「地図」そのものだ。`DCL 1 MY_REC, 2 A CHAR(10), 2 B BIN FIXED(31);` と書けば、コンパイラは即座に14バイトの固定領域をメモリ上に確保する。
Javaに移行する際、これを単なるPOJO（Plain Old Java Object）としてフィールドを定義するだけでは痛い目を見る。特に以下のケースだ。
- VSAMのバイナリ読み込み: `READ FILE(VSAMFILE) INTO(MY_REC)` が行うメモリアクセスを、Javaで再現しなければならない。
- バイナリ・インターフェース: 外部の他システムが、かつてのPL/Iのバイナリレイアウトを前提にデータを投げ込んでくる場合。
Javaでこれを再現するには、単なるクラス定義ではなく、`java.nio.ByteBuffer` を駆使した「シリアライザ」の設計が不可欠だ。
—
2. 実践：PL/Iの構造体定義とJavaマッピングの要諦
まず、現場でよく見る標準的なPL/Iの構造体を見てみよう。
/i
/ 顧客マスタレコードの例 /
DCL 1 CUST_REC,
2 CUST_ID CHAR(8), / 顧客ID /
2 CUST_INFO, / グループ項目 /
3 NAME CHAR(20), / 顧客名 /
3 AGE BIN FIXED(31), / 年齢(4バイトバイナリ) /
2 FILLER CHAR(4); / 調整用パディング /
/ ONユニットによる入出力エラー制御の実践 /
ON ENDFILE(CUST_FILE) BEGIN;
PUT SKIP LIST(‘データ終了につき処理を終了します’);
GO TO EOF_LABEL;
END;
この構造体をJavaに移行する際、最も重要なのは「アライメント」だ。PL/Iコンパイラが自動的に挿入するパディング（境界調整）をJava側で忠実に再現しなければ、データの読み取り位置がズレて「化け」が発生する。
Javaへの変換戦略（ByteBufferの活用）
Java側では、以下のように`ByteBuffer`のオフセットを明示的に制御するラッパーを作るのがプロのやり方だ。
public class CustRec {
private String custId; // 8 bytes
private String name; // 20 bytes
private int age; // 4 bytes
public void unmarshall(byte[] buffer) {
ByteBuffer bb = ByteBuffer.wrap(buffer);
this.custId = new String(bb.get(new byte[8]));
this.name = new String(bb.get(new byte[20]));
this.age = bb.getInt(); // BIN FIXED(31)はJavaのintと合致する
}
}
—
3. マイグレーションの現場で陥る「落とし穴」
現場のエンジニアからよく相談されるトラブルには、共通点がある。
1. `BIN FIXED(15)` と `(31)` の混同:
PL/Iの `FIXED BIN(15)` は2バイト、`(31)` は4バイトだ。Javaの `int` は常に4バイトなので、ここを安易に `int` にすると、構造体の長さが合わず後続データがすべてずれる。これこそが「マイグレーションの墓場」だ。
2. `UNION` 構文の扱い:
PL/Iの `DEFINED` や `UNION` を使った領域のオーバーレイは、Javaには存在しない。これらを移行する際は、継承やポリモーフィズムで解決しようとせず、一度「バイト配列」に分解してから解釈するロジックを分離すべきだ。
3. `ON`ユニットと例外処理の温度差:
PL/Iの `ON` ユニットは、プログラムの処理フローをジャンプさせる強力な非局所的制御だ。Javaの `try-catch` は局所的であるため、単純な置換はバグを生む。`ON` ユニットが持っていた「復帰先」の概念を、Javaの例外処理でどう表現するか、設計段階で腹を括っておく必要がある。
—
最後に：諸君へ送るアドバイス
メインフレームからJavaへ移行するということは、単に言語を変えることではない。「ハードウェアの制約をコードで管理していた時代」から「メモリ管理をランタイムに委ねる時代」への価値観の転換だ。
しかし、どんなに時代が変わっても、バイナリデータの構造が持つ「厳密さ」は変わらない。PL/Iで培ったその「メモリへの直感」を、Javaのライブラリの裏側に活かすことができれば、君たちはどこへ行っても重宝されるエンジニアになれる。
何か行き詰まったら、いつでも聞くといい。メインフレームの歴史は、そのまま君たちの技術の背骨になるはずだ。
さて、そろそろバッチウィンドウが閉まる時間だ。各自、デバッグに戻るように。
