現場で差がつくPL/I：OFFSET型とAREAによる「動的メモリー管理」の深淵
若手の諸君、お疲れ様。今日も今日とてJCLの海に溺れ、コンパイルリストと睨めっこしていることだろう。
大規模な勘定系や物流系のバッチ処理を長く担当していると、たまに「なぜ今のコードはこんな面倒な書き方をしているんだ？」と疑問に思う箇所にぶつかるはずだ。その筆頭が、今回解説するOFFSET型とAREAの組み合わせだ。
現代のJavaやPythonしか知らないエンジニアには想像もつかないかもしれないが、ポインタ（POINTER）が「絶対アドレス」を指すのに対し、OFFSET型は「AREAの先頭からの相対位置」を保持する。これがなぜ基幹システムで重宝され、そしてなぜデバッグ時にエンジニアを泣かせるのか。その機微を紐解いていこう。
—
1. なぜ「OFFSET型」を使うのか？
通常、メインフレームのバッチ処理では、`ALLOCATE`文で動的にストレージを獲得する。しかし、システムが確保した領域（AREA）内でデータ構造を頻繁に入れ替える際、ポインタをそのまま保存してファイル（VSAMなど）に出力しようとすると、再ロード時にアドレスがズレてシステムダウンを招く。
ここでOFFSET型の出番だ。
AREAの先頭からの「距離」さえ保存しておけば、プログラムが再起動してメモリー上の配置が変わっても、`AREA_VAR -> OFFSET_VAR` という計算式で正しいアドレスが即座に算出できる。いわば「住所（絶対値）」ではなく「駅からの歩数（相対値）」で場所を管理する考え方だ。
2. 実践コード：AREAとOFFSETの連携
以下に、実務でよく見かける構造を簡略化したサンプルを記述する。`BASED`変数と組み合わせて使うのが定石だ。
/i
//
/ AREA内での動的リスト管理サンプル /
//
TEST_PROC: PROC OPTIONS(MAIN);
/ 1024バイトの領域を確保 /
DCL MY_AREA AREA(1024);
/ BASED変数：エリア内のデータ定義 /
DCL 1 NODE BASED(P),
2 NEXT_OFFSET OFFSET(MY_AREA), / 次の要素への相対位置 /
2 DATA_VAL FIXED BIN(31);
DCL P POINTER;
DCL HEAD_OFF OFFSET(MY_AREA) INIT(NULL());
DCL (CUR, NEW) POINTER;
/ 新しいノードをAREA内に確保 /
ALLOCATE NODE SET(NEW) IN(MY_AREA);
/ データの代入と連結 /
NEW->DATA_VAL = 100;
NEW->NEXT_OFFSET = HEAD_OFF;
/ ポインタからオフセットへ変換して保存 /
HEAD_OFF = OFFSET(NEW, MY_AREA);
/
- 注意：VSAM等に書き出す際は、このHEAD_OFFを保存する。
- 読み込み時に再計算すれば、アドレスの整合性は完璧に保たれる。
/
PUT SKIP LIST(‘DATA CREATED AT OFFSET: ‘, HEAD_OFF);
END TEST_PROC;
—
3. デバッグと「ONユニット」の罠
OFFSET型を扱う際、現場で最も恐ろしいのは「領域溢れ」だ。
`ALLOCATE`文でAREAの容量を超えて領域を確保しようとすると、即座に`AREA`条件が発生する。ここで`ON AREA`ユニットを適切に組んでいないと、プログラムは無慈悲にも異常終了（ABEND）する。
/i
ON AREA BEGIN;
PUT SKIP LIST(‘エラー：AREAの容量不足が発生しました’);
/ ここでダンプ取得やリカバリ処理を行う /
CALL DUMP_LOGIC;
STOP;
END;
現場のベテランからの助言：
OFFSET型で最もハマるのが、「初期化されていないOFFSET変数」を誤って参照するケースだ。PL/Iは賢いが、未定義のOFFSET値はゴミの値を持っている。デバッガで追いかける際は、`STORAGE`属性や`OFFSET`変換関数（`ADDR`ビルトインなど）を使って、計算されたアドレスが本当にAREAの範囲内にあるか、必ず境界チェックを入れる癖をつけろ。
4. まとめ：レガシーだからこそ光る設計思想
OFFSET型は、一見すると「ポインタでいいじゃないか」と思われるかもしれない。しかし、「メモリーの断片化を防ぎつつ、永続ストレージとの親和性を高める」という設計思想においては、この型は今なお現役の最強のツールだ。
マイグレーションや改修の際、「このOFFSETは何を指している？」と迷ったら、まずはその親となる`AREA`の定義を探せ。そこには、先人たちが苦労して構築した、効率的なメモリー管理の形跡が残されているはずだ。
技術は変わるが、計算機がメモリーをどう管理するかという本質は、メインフレームの世界では変わらない。諸君、明日からのデバッグでは、コードの裏側にある「相対位置」を意識して、自信を持ってロジックを読み解いてほしい。
何かあれば、またいつでも聞いてくれ。現場からは以上だ。
