メインフレームの深淵へ：PL/Iポインタ操作とアドレス解決の「勘所」
現場の諸君、今日もメインフレームの海を泳いでいるか。
PL/Iという言語は、一見するとCOBOLのような「お堅い事務処理用」の顔をしているが、その実、ポインタを直接操作できる強力な低級言語としての側面を持っている。この二面性が、大規模バッチの保守における「悪夢」にもなれば、極めて効率的なデータ処理を可能にする「武器」にもなるんだ。
今回は、特にトラブルの温床となりやすいポインタ変数とADDRビルトイン関数、そしてメモリ上のアドレス解決について深掘りしていく。ここを理解していないと、マイグレーション先での予期せぬS0C4（アドレッシング例外）に泣くことになるぞ。
—
ポインタの実体はただの「数値」ではない
PL/Iにおいて `POINTER` 型変数は、単なる4バイト（31ビット環境）または8バイト（64ビット環境）の数値格納場所だ。だが、コンパイラはこれを単なる整数として扱わない。「どの領域を指しているか」という基底（Based）情報のメタデータを常に意識している。
特に注意すべきは、31ビット・アドレッシングと64ビット・アドレッシングの混在だ。AMODE 31で動く既存のレガシー資産をAMODE 64へ移行しようとする際、`ADDR` 関数が返す値の解釈を誤ると、メモリ保護違反の泥沼にハマる。
実践：基底付き変数（BASED）へのアクセス制御
まずは、現場でよくある「動的なレコード構造の読み込み」を想定したコード例を見てくれ。VSAMやバッファ管理で必須のテクニックだ。
1
/ —————————————————————— /
/ PROGRAM: ADDR_DEMO /
/ 目的: ポインタを用いた動的領域アクセスとADDR関数の使用 /
/ —————————————————————— /
DEMO_PROC: PROCEDURE OPTIONS(MAIN);
/ 構造体テンプレート：実際の物理データではなく「型」を定義 /
DCL 1 MY_RECORD BASED(P_REC),
2 ID CHAR(5),
2 VALUE FIXED BIN(31);
/ ポインタ変数の宣言 /
DCL P_REC POINTER;
DCL P_BUFFER POINTER;
/ ダミーのバッファ領域確保（実際はGETMAIN等で取得したアドレス） /
P_BUFFER = … ; / ここにOSから返された有効なメモリ番地が入る /
/ ADDR関数で特定の変数番地を確認するデバッグ手法 /
DCL P_TARGET POINTER;
P_TARGET = ADDR(MY_RECORD);
/
- ポイント:
- P_RECにP_BUFFERを代入することで、MY_RECORDの「基底」が
- 指定したメモリ領域を指すようになる。
/
P_REC = P_BUFFER;
/ VSAMや入出力バッファを直接マッピングしてアクセス /
PUT SKIP LIST(‘ID IS: ‘ || MY_RECORD.ID);
/ ONユニット：アドレス違反をトラップする鉄則 /
ON CONDITION(CHECK_ERROR) BEGIN;
PUT SKIP LIST(‘メモリ参照エラーが発生しました’);
END;
END DEMO_PROC;
—
ADDR関数とアドレス解決の落とし穴
`ADDR` 関数を使う際、諸君が必ず理解しておくべきは「どのセグメントを指しているか」だ。
1. 31ビット vs 64ビットの境界:
現在、多くのシステムがAMODE 31だが、一部のJava連携や大規模メモリ活用でAMODE 64が混在している。`ADDR` は現在の実行モードに依存した形式のアドレスを返す。64ビットモードで取得したアドレスを31ビットのポインタに無理やり詰め込めば、上位ビットが切り捨てられ、全く関係のない番地を指すことになる。
2. 基底付き変数の「型」の重要性:
`P_REC -> MY_RECORD.ID` のように修飾子を使う際、PL/Iコンパイラはコンパイル時にオフセットを計算する。もし `P_REC` が指す実際のメモリレイアウトと、構造体 `MY_RECORD` の定義が少しでもズレていれば、データは化ける。特に `UNION` や `DEFINED` 属性を併用している時は要注意だ。
デバッグのコツ：現場の知恵
もしS0C4に遭遇したら、すぐにダンプを見る前に、以下の手順を試してくれ。
- ポインタの値を表示せよ: デバッガ（XPEDITERやDebug Tool）で `P_REC` の値を確認し、それが `0` (NULL) でないか、あるいは不正な領域（`x’00000000’` 付近や、解放済みの領域）を指していないかを確認する。
- ストレージの生存期間: `BASED` 変数を使っている場合、そのポインタが指しているメモリが `FREE`（または `FREEMAIN`）されていないか。PL/Iの `ALLOCATE` を使っている場合は特に、ストレージのライフサイクル管理が破綻すると、このエラーが頻発する。
- コンパイラオプション: `CHECK(STORAGE)` を一時的に有効にしてコンパイルしてくれ。実行速度は落ちるが、境界外アクセスを自動で検知してくれる。
最後に
PL/Iのポインタ操作は「諸刃の剣」だ。しかし、この制御をマスターすれば、OSのカーネルに近い動きをメインフレーム上で操ることができる。
「なぜ動いているのか」を突き詰め、メモリの１バイト単位まで意識を向ける。それこそが、我々メインフレームエンジニアの矜持というものだ。
また次回は、`ON` ユニットを使った例外ハンドリングの「エレガントな書き方」について語ろうと思う。それまで、コードの隅々まで目を光らせておけよ。
