こんにちは、現場のエンジニア諸君。
これまで数々の巨大な勘定系バッチや、複雑怪奇な生保・損保の保険料計算ロジックの改修を生き抜いてきたベテランシステムアーキテクトの私だ。
今日のテーマは、PL/Iのデータ制御における隠れた名優、「OFFSET属性による相対アドレス指定」だ。
今時のオープン系やクラウドネイティブな世界から来た若手エンジニアからすると、「ポインタがあるのに、なんでわざわざオフセットなんて使うんですか？ 古臭い最適化テクニックですか？」なんて質問が飛んできそうだが、とんでもない。これはメインフレームの限られた主記憶（あるいは仮想記憶）を極限まで効率的に使い倒し、さらに世代交代やデータ移行（マイグレーション）の際にも絶対に腐らない、先人たちの知恵が詰まった極めて強力な仕組みなのだ。
今日は、なぜOFFSET属性が必要なのか、POINTER型との違いは何なのか、そしてVSAMや入出力、動的記憶域管理の現場でどう活きるのかを、実務直結のコードを交えて徹底的に叩き込んでやろう。
—
1. なぜ今、OFFSET属性なのか？（ポインタの宿命とOFFSETの救済）
C言語やPL/IのPOINTER変数を思い出してほしい。POINTER変数が保持しているのは、そのアドレス空間における「絶対アドレス（Absolute Address）」だ。
例えば、ある構造体をメインフレーム上の特定のストレージに割り当て、その絶対アドレスをポインタに格納して処理を進めるとしよう。この時、もしそのデータ構造をそのまま外部記憶（VSAMファイルや磁気テープ）に吐き出したり、あるいはアドレス空間の異なる別の領域へ丸ごとコピー（あるいはアドレス空間の再配置＝リロケーション）したらどうなるか？
――絶対アドレスを指しているポインタは、移動先では完全に「ゴミ」になり、一瞬でS0C4等のメモリアクセス例外（ABEND）を引き起こす。
ここで登場するのが OFFSET属性 だ。
OFFSET変数が保持しているのは、絶対アドレスではない。起算点となる AREA（エリア）の先頭からの相対バイト数（オフセット） である。
つまり、データ構造全体を別の場所に移動しようが、ファイルに一旦セーブして別の日のバッチで読み込もうが、AREAの相対位置さえ変わっていなければ、OFFSETの値は完全に有効なのだ。これが、世代管理や永続化を伴う基幹システムにおいてOFFSETが重宝される最大の理由だ。
—
2. OFFSET属性とAREAの基本構文
PL/IにおけるOFFSET属性は、必ず `AREA` とセットで運用される。単独で宣言することはできない。
まずは基本の宣言構文を見てみよう。
1
/ 領域（AREA）の宣言と、その中を指すOFFSETおよびPOINTERの宣言 /
DCL MY_AREA AREA(10240) BASED(AREA_PTR); / 10KBの管理領域 /
/ OFFSET変数の宣言：MY_AREA内での相対位置を保持する /
DCL 1 LIST_NODE BASED(NODE_PTR),
2 NEXT_OFF OFFSET(MY_AREA), / 次の要素へのオフセット /
2 DATA_VAL FIXED BIN(31); / 実データ /
DCL NODE_PTR POINTER;
DCL AREA_PTR POINTER;
ここで重要なのは、`OFFSET(MY_AREA)` と指定することで、「このオフセット値は `MY_AREA` という特定のエリアの先頭からの相対距離を表す」とコンパイラに明示している点だ。
POINTER と OFFSET の相互変換（BUILTIN関数）
実務では、エリア内のメモリを確保（ALLOCATE）したり、アドレスを辿ったりする際に、絶対アドレス（POINTER）と相対アドレス（OFFSET）を行き来する必要がある。ここでPL/Iの強力な組み込み関数（BUILTIN）が活躍する。
- PTRVALUE(offset変数) : OFFSETが指す相対位置から、実際の絶対アドレス（POINTER）を計算して返す。
- OFFSET(pointer変数, area変数) : 絶対アドレスとエリアの先頭から、対応するOFFSET値を逆算する。
—
3. 実践！VSAMレコード処理とAREA/OFFSETを駆使した動的リスト構造
百聞は一見にしかず。実際のバッチプログラムを想定したサンプルコードを見てほしい。
このコードでは、VSAM（KSDS）から読み込んだ可変長あるいはマスターデータを、ワーキングストレージ上のAREA内に動的にチェイン（連結リスト）として展開し、最後にその構造をそのままファイル出力、あるいは集計する処理を模している。
1
/ ================================================================= /
/ プログラム名: OFFSET実習バッチ /
/ 概要: AREA内でのOFFSET属性を用いたリスト構造の構築と走査 /
/ ================================================================= /
OFFSET_DEMO: PROC OPTIONS(MAIN);
/ — 1. ワークエリアおよび構造体の定義 — /
/ 8KBの管理領域（AREA）を定義 /
DCL WORK_AREA AREA(8192) BASED(W_AREA_PTR);
DCL W_AREA_PTR POINTER;
/ エリア内で使用するリスト要素の定義 /
DCL 1 ELEMENT BASED(ELEM_PTR),
3 NXT_OFF OFFSET(WORK_AREA), / 次の要素へのオフセット /
3 PRV_OFF OFFSET(OFFSET), / （※説明用: 逆方向など） /
3 EMP_ID CHAR(5), / 社員ID /
3 SALARY FIXED DEC(9,2); / 給与 /
DCL ELEM_PTR POINTER;
DCL HEAD_OFF OFFSET(WORK_AREA) INIT(0); / リスト先頭のオフセット /
DCL CUR_OFF OFFSET(WORK_AREA);
DCL PREV_OFF OFFSET(WORK_AREA);
/ VSAM入力ファイル定義（例: 従業員マスタ） /
DCL EMP_FILE FILE RECORD INPUT
ENVIRONMENT(CONSECUTIVE);
DCL 1 EMP_REC,
5 R_ID CHAR(5),
5 R_SAL FIXED DEC(9,2);
DCL EOF_FLG BIT(1) INIT(‘0’B);
/ 異常系制御のためのONユニット /
ON ENDFILE(EMP_FILE) EOF_FLG = ‘1’B;
ON AREA
BEGIN;
PUT SKIP EDIT (‘ 致命的エラー: WORK_AREAが枯渇しました ‘)(A);
/ 実際の実装ではここでダンプ取得や異常終了コードを設定する /
SIGNAL ERROR;
END;
/ — 2. 初期処理 — /
DISPLAY(‘ OFFSET_DEMO START ‘);
/ ワーキングストレージ上にAREA分のメモリを明示的に取得 /
ALLOCATE WORK_AREA;
HEAD_OFF = NULL; / 初期状態は空 /
OPEN FILE(EMP_FILE);
/ — 3. 入力データ読み込みとエリア内リスト構築 — /
READ FILE(EMP_FILE) INTO(EMP_REC);
DO WHILE(^EOF_FLG);
/ AREA内に新しい要素分のメモリをALLOCATE /
/ ALLOCATE時に IN (WORK_AREA) を指定するのがポイント /
ALLOCATE ELEMENT IN(WORK_AREA);
/ 値の設定 /
ELEMENT.EMP_ID = EMP_REC.R_ID;
ELEMENT.SALARY = EMP_REC.R_SAL;
ELEMENT.NXT_OFF = NULL(); / 末尾として初期化 /
/ リストへの繋ぎ込み処理 /
IF HEAD_OFF = NULL() THEN
HEAD_OFF = OFFSET(ELEM_PTR, WORK_AREA); / 最初の要素 /
ELSE
DO;
/ 末尾を探してチェインをつなぐ（簡易的に末尾追加のロジック） /
/ 実務では末尾ポインタを保持しておくと効率が良い /
CUR_OFF = HEAD_OFF;
DO WHILE(ELEMENT.NXT_OFF ^= NULL());
/ オフセットからポインタへ変換して構造体をスライド /
CUR_OFF = ELEMENT.NXT_OFF;
ELEM_PTR = PTRVALUE(CUR_OFF);
END;
/ 最終要素のNXT_OFFに新しい要素のオフセットを設定 /
ELEMENT.NXT_OFF = OFFSET(ELEM_PTR, WORK_AREA);
END;
READ FILE(EMP_FILE) INTO(EMP_REC);
END;
/ — 4. リストの走査（トラバーサル）と集計 — /
DISPLAY(‘— 登録された社員リストの走査 —‘);
CUR_OFF = HEAD_OFF;
DO WHILE(CUR_OFF ^= NULL());
/ オフセットを実ポインタに変換して要素にアクセス /
ELEM_PTR = PTRVALUE(CUR_OFF);
PUT SKIP EDIT (‘社員ID: ‘, ELEMENT.EMP_ID, ‘ 給与: ‘, ELEMENT.SALARY)
(A, A, A, F(10,2));
/ 次のオフセットへ移動 /
CUR_OFF = ELEMENT.NXT_OFF;
END;
/ — 5. 終了処理 — /
CLOSE FILE(EMP_FILE);
/ AREA自体の解放 /
FREE WORK_AREA;
DISPLAY(‘ OFFSET_DEMO END ‘);
RETURN;
END OFFSET_DEMO;
—
4. 保守現場で使える！デバッグとトラブルシューティングの極意
さて、このコードを見て「おっ」と思ったベテランもいるだろう。OFFSETやAREAを扱うバッチプログラムの保守において、現場でよく直面するトラブルと、その処方箋をいくつか伝授しておこう。
トラブル1: `ON AREA` 割り込み（S0C4や領域枯渇）
AREAのサイズを `AREA(8192)` と静的に固定している場合、マスターの件数が増えたり、バッチの結合テストで想定以上のデータが流れ込むと、あっさりエリアが枯渇する。
- 現場の知恵: サンプルコードにも入れた通り、`ON AREA` 条件付きONユニットを必ず実装しておくこと。これをサボると、原因不明のストレージ上書きや、突発的なS0C4 ABENDに悩まされることになる。マイグレーション時には、当年と来年のデータ量を見越し、AREAサイズ（バイト数）に十分なバッファを持たせているか必ずコードレビューで確認しろ。
トラブル2: `NULL()` と `NULL` の混同
PL/Iにおいて、ポインタやオフセットが無効であることを示す値として `NULL()`（または `NULL`）がある。
OFFSET変数に対して無効値を代入・比較する場合は、きちんと `NULL()` を使うこと。特に古いソースコードでは、初期化漏れによる不定値が `NXT_OFF` に入り込み、ループが無限ループ（あるいは不正メモリアクセス）になるバグが後を絶たない。
トラブル3: ダンプ解析時の見方
もし万が一、OFFSETやAREA関連でABEND（S0C1, S0C4など）が発生し、SYSUDUMPやCEEDUMPを解析することになった時：
- ダンプ内のワーキングストレージ領域を見ても、ポインタ（4バイトの絶対アドレス）のつもりで眺めると値がチグハグに見える。
- OFFSET変数は「エリア先頭からの相対バイト数（16進数または10進数）」で格納されていることを思い出し、エリアのベースアドレスと足し合わせて実効アドレスを割り出す必要がある。この計算ができるかどうかが、三流プログラマと一流メインフレームエンジニアの分かれ道だ。
—
5. おわりに
OFFSET属性とAREAの組み合わせは、現代のオープン系言語のメモリ管理から見ればレトロフューチャーな技術に見えるかもしれない。しかし、「メモリ配置の独立性（リロケータビリティ）」を担保しながら、高効率な動的データ構造をメインフレーム上に構築できるという点で、これに勝るアーキテクチャはそうそうない。
基幹システムのマイグレーションや、古いバッチプログラムの大規模改修に直面した時、こうした基本構文の裏にある「なぜその仕様になっているのか」という設計思想を理解していれば、怖るるに足りない。
さあ、今日も現行踏襲の海原へ漕ぎ出し、確実で堅牢なコードを書き上げてくれ。健闘を祈る！
