メインフレームの闇を照らす：BASED変数とポインタによる動的メモリ管理の「正攻法」
やあ。今日も今日とてJCLの海を泳いでいるか？
メインフレームの世界で長く生きていると、静的なデータ定義（DCL）だけではどうにもならない局面にぶつかるはずだ。レコード長が可変のVSAMファイルを読み込む時、あるいは、バッチ処理の中で動的にリスト構造を構築してメモリ上にキャッシュしたい時。
そんな時、多くのエンジニアが「怖い」と避けるのがBASEDストレージとポインタだ。だが、これこそがPL/Iが「汎用言語」として最強たる所以でもある。今回は、この動的メモリ管理を安全かつ確実に実装するための「現場の知恵」を授けよう。
—
1. BASED変数の本質：メモリの「型」を定義するだけ
まず誤解を解いておこう。`DCL P PTR;` と `DCL X CHAR(100) BASED(P);` を書いたとしても、この瞬間、メモリは確保されていない。
`BASED`変数は、「このアドレスから先をこういう構造として解釈する」というテンプレートに過ぎない。実際にメモリを確保し、そのアドレスをポインタ変数 `P` にセットするのは `ALLOCATE` 文の役割だ。
2. 実践：動的メモリ確保の定石コード
以下の例を見てほしい。VSAMから読み込んだ可変長レコードを、メモリ上にリストとして繋いでいくイメージだ。
1
/ ================================================================== /
/ 動的メモリ確保のサンプル: リスト構造の構築 /
/ ================================================================== /
TEST_PROG: PROC OPTIONS(MAIN);
/ 構造体の定義: BASED属性を付与 /
DCL 1 NODE BASED(P_NODE),
2 NEXT_PTR PTR, / 次の要素へのポインタ /
2 DATA_LEN BIN(15), / データ長 /
2 DATA_VAL CHAR(80); / データ本体 /
DCL (P_HEAD, P_NODE, P_WORK) PTR INIT(NULL());
/ 1. メモリを確保する /
ALLOCATE NODE;
/ この時点で P_NODE にはOSから割り当てられたアドレスが入る /
P_HEAD = P_NODE; / リストの先頭を保持 /
/ 値をセット /
NODE.DATA_LEN = 10;
NODE.DATA_VAL = ‘SAMPLE_DATA’;
/ 2. 不要になったら必ず解放する /
/ ここで FREE を忘れると、バッチが長時間稼働した際にABEND(S80A)必至 /
P_WORK = P_HEAD;
FREE NODE; / P_WORKが指すメモリを解放 /
P_HEAD = NULL(); / ダングリングポインタを防ぐ /
END TEST_PROG;
—
3. 現場で「死なない」ための3つの掟
大規模なバッチ改修で、動的メモリ管理を扱う際に守るべき「掟」がある。これを無視すると、本番環境でS0C4やS80Aという悪夢を見ることになるぞ。
① 必ず `NULL()` で初期化せよ
ポインタ変数を宣言したら、例外なく `INIT(NULL())` しておくこと。初期化を忘れると、ゴミデータが入ったポインタに対して `FREE` を発行し、システム全体を巻き込む異常終了を引き起こす。
② `FREE` 後は即座にポインタをクリアせよ
`FREE` を実行しても、ポインタ変数 `P_NODE` の中身は解放前の「古いアドレス」を指したままだ。これを「ダングリングポインタ（ぶら下がりポインタ）」と呼ぶ。`FREE` の直後に `P_NODE = NULL();` を書く癖をつけろ。これができているかいないかで、コードの品質が段違いになる。
③ ONユニットで例外を捉えよ
メモリ確保（`ALLOCATE`）は、ストレージ不足で失敗することがある。`ON STORAGE` ユニットを適切に配置し、万が一の時にログを出力して、安全に後処理（クローズ処理など）へ遷移させる設計を忘れるな。
1
ON STORAGE BEGIN;
PUT SKIP LIST(‘!!! メモリ不足が発生しました !!!’);
/ ここでVSAMファイルをクローズする等の安全策を講じる /
CALL ABEND_ROUTINE;
END;
—
4. 最後に：なぜ「ポインタ」を恐れるのか
ポインタは、メモリという「生の領域」を直接制御する強力な武器だ。PL/Iはアセンブラのようにハードウェアに近い制御が可能でありながら、高級言語としての堅牢性も備えている。
最近の若手は、メモリ管理が自動化された言語に慣れているかもしれない。だが、メインフレームのバッチ処理において、メモリを「自分で制御できる」という能力は、極限のパフォーマンスを絞り出す際に決定的な差となる。
もし、デバッグ中に `S0C4`（保護例外）に遭遇したら、それは「ポインタが意図しないメモリを指している」という合図だ。`ADDR()` 組み込み関数や `OFFSET` 属性を活用し、メモリマップを頭の中で描けるようになるまで練習してほしい。
PL/Iは古い言語かもしれないが、その仕様は完璧に洗練されている。恐れず、しかし慎重に。今日の実装が、明日の安定稼働を支える。
では、健闘を祈る。何かあればいつでも聞いてくれ。
