メインフレームの「PL/I」をJavaエンジニアが読み解く：メモリ管理と設計のパラダイムシフト
こんにちは。長年メインフレームの深淵でシステム設計に携わってきたアーキテクトです。
最近、「既存のPL/I基幹システムをJavaへ移行したい」という相談をよく受けます。Javaエンジニアの方々にとって、PL/Iのコードは一見すると「魔法の呪文」のように見えるかもしれません。しかし、一つずつ紐解けば、PL/Iは非常に論理的で、コンピュータのハードウェアに近い挙動を制御できる、まさに「職人のための言語」であることがわかります。
今回は、PL/Iの基本構造と、Javaへの移行時に最も頭を悩ませる「メモリ管理」の考え方について、現場の知見を交えてお話しします。
—
1. PL/Iの基本構造：まずは「箱」の正体を知る
PL/Iのプログラムは、`PACKAGE`や`PROCEDURE`という単位で構成されます。Javaで言えばクラスやメソッドに近いですが、決定的な違いは「ストレージ（メモリ）の寿命を明示的に制御する」という点です。
まずは簡単な構造例を見てみましょう。
1
/ メインプログラムの入り口となるPROCEDURE /
HELLO_WORLD: PROCEDURE OPTIONS(MAIN);
/ 文字列変数の宣言：JavaのStringとは異なり、固定長でメモリを占有します /
DCL MSG CHAR(20) INIT(‘HELLO, MAINFRAME!’);
/ 標準出力：PUT SKIPはJavaのSystem.out.printlnに近い感覚ですね /
PUT SKIP LIST(MSG);
END HELLO_WORLD;
ここで重要なのは、`DCL`（DECLARE）で宣言された変数は、宣言された瞬間にメモリ上の特定の場所を陣取るということです。Javaのように「後からインスタンスを生成する」というよりは、「あらかじめ決められたサイズの箱を用意する」というイメージに近いですね。
—
2. メモリ管理の大きな壁：ポインタとガベージコレクション
Javaエンジニアが最も苦戦するのが、PL/Iの「ポインタ操作」です。Javaではガベージコレクション（GC）が自動で不要なメモリを掃除してくれますが、PL/Iの世界では「自分で確保し、自分で解放する」のが鉄則です。
PL/Iのポインタと制御属性
PL/Iでは、`BASED`という属性を使って、メモリの特定の番地を直接指し示すことができます。
1
/ ポインタ変数の宣言 /
DCL P_DATA PTR;
/ 構造体の定義：メモリのレイアウトを直接指定します /
DCL 1 MY_REC BASED(P_DATA),
2 ID FIXED BIN(31),
2 NAME CHAR(10);
/ メモリの動的確保（Javaのnewに相当） /
ALLOCATE MY_REC;
/ この時点で、P_DATAは確保されたメモリの先頭を指しています /
/ ポインタを使ってデータを操作 /
ID IN MY_REC = 100;
/ 使い終わったら必ず解放。これを忘れるとメモリリークが起きます /
FREE MY_REC;
なぜJava移行で苦労するのか？
Javaには`FREE`命令がありません。Javaへ移行する際、こうしたポインタベースのロジックをそのまま「オブジェクトの生成と参照」に置き換えると、GCの負荷やメモリモデルの違いから予期せぬパフォーマンス低下を招くことがあります。
現場の知見：
PL/Iのポインタ操作は、特定のデータ構造を「複数の場所から効率よく参照する」ために使われていることが多いです。これをJava化する際は、無理にポインタを再現しようとせず、「データを保持するPOJO（Plain Old Java Object）」と「それを管理するサービス層」を分離する設計へのリファクタリングが不可欠です。
—
3. Javaへの移行：設計変更のヒント
PL/Iの「メモリを直接いじる」という手法は、ハードウェアリソースが限られていた時代の知恵です。現代のJavaで同じことをしようとすると、かえってコードが複雑になり、保守性が下がります。
移行の際、意識すべき3つのポイント
1. 固定長から可変長へ
PL/Iの`CHAR(n)`はメモリを固定で消費しますが、Javaの`String`はヒープ上で柔軟に扱われます。この「サイズ固定」という前提で作られたバリデーションロジックを見直しましょう。
2. ポインタの抽象化
PL/IのポインタをJavaの「参照型」に置き換えるのは簡単ですが、「なぜポインタを使っていたのか」という意図を汲み取ってください。単なるデータ構造の共有なら、Javaの不変オブジェクト（Immutable Object）の活用を検討すべきです。
3. 明示的な解放の排除
`FREE`文の代わりに、Javaの`try-with-resources`構文を活用する設計に切り替えましょう。自動化できる部分は言語の特性に任せるのが、モダンな開発の定石です。
—
最後に：怖がらなくて大丈夫です
PL/Iのコードを初めて見るJavaエンジニアは、その「古めかしい記述」に圧倒されてしまうかもしれません。しかし、PL/Iは現代のプログラミング言語の多くの概念を先取りしていた、非常に完成度の高い言語です。
「メモリというハードウェアの資源を、人間が意図した通りに動かす」。このPL/Iの哲学を理解できれば、Javaの世界に戻ったとき、メモリ効率を意識したワンランク上の設計ができるようになっているはずです。
もし現場で「この変数の挙動がわからない…」というコードに遭遇したら、いつでも相談してください。その「箱」がメモリのどこを指しているのか、なぜそのサイズでなければならないのか、一緒に紐解いていきましょう。
それでは、次回の記事でお会いしましょう！
