メインフレームの深淵：ADDR関数とPOINTER関数が暴くアドレス解決の真実とマイグレーションの罠
こんにちは。基幹システムの深層で日々、COBOLやPL/Iの古いコードベースと格闘しているシステムアーキテクトの皆さん。
現代のJavaやC#といったマネージド言語の世界では、メモリのアドレスやポインタ操作という概念は、原則として「安全なカプセル化の向こう側」に隠蔽されています。しかし、私たちが生きるIBMメインフレーム（z/OS）のPL/Iの世界では、ポインタは単なるデータ型ではなく、ハードウェアのアーキテクチャと直接対話するための「剥き出しの刃」です。
今回は、PL/Iにおける `ADDR`関数 と `POINTER`関数 を取り上げ、変数のアドレス解決、S/370およびz/Architectureにおける基底レジスタ（Base Register）と変位（Displacement）の計算メカニズム、そしてアベンド（ABEND）解析やJava/C#等へのマイグレーション時における極限のエッジケースについて、私の実務経験を交えて徹底的に解説します。
—
1. 予約語を持たないPL/Iの美学と、アドレス解決のハードウェア的背景
PL/Iの言語仕様における最大の特徴であり、C言語や現代の言語に慣れたプログラマを最も混乱させるのが 「予約語（Reserved Words）を持たない」 という設計思想です。
PL/Iには、`IF`や`DO`といったキーワードですさえ、コンテキストによっては単なる変数名として宣言して使うことが可能です（推奨はしませんが）。この柔軟な構文規則の裏で、コンパイラはコードを解析し、シンボルが変数なのか、組み込み関数（Built-in Function）なのか、あるいはラベルなのかを文脈から厳密に判断しています。
そのPL/Iにおいて、メモリの生アドレスを扱うのが `POINTER` データ型であり、それを取得・生成するのが `ADDR` と `POINTER` 関数です。
基底レジスタと変位の32ビット/64ビットアドレス解決
IBMメインフレームの機械語命令（System/370 アーキテクチャ以降）は、メモリアクセスにおいて以下のアドレス計算を行います。
$$\text{実効アドレス} = \text{基底レジスタ（Base Register）} + \text{変位（Displacement：12ビット/20ビット）}$$
- 12ビット変位（旧アーキテクチャ）: 最大4KB（4095バイト）までのオフセットしか表現できませんでした。
- 20ビット変位（Immmediate/Extended Displacement）: z/Architecture以降では、より大きな構造体やDSECTのオフセットに対応するため拡張されています。
PL/Iプログラム内で `ADDR(my_variable)` を呼び出すとき、コンパイラは単にメモリ上のオフセットを返しているわけではありません。リンケージ・セクション（Linkage Section）や自動ストレージ（Automatic Storage）上の変数が、どのベース・レジスタを起点として相対位置にあるのかをコンパイル時に計算し、ロード命令（LやLG）やアドレスロード命令（LAやLAY）の機械語列へと翻訳しています。
—
2. 実践：`ADDR` と `POINTER` を駆使した動的メモリ操作
言葉だけでは抽象的なので、実際のPL/Iコードを見てみましょう。以下のコードは、CICSオンラインやバッチの大規模ソートワークエリアなどでよく見られる、基底なしストレージ（Based Storage）へのポインタ割り当てのイディオムです。
/ —————————————————- /
/ ポインタとベース変数を用いた動的ストレージ操作の例 /
/ —————————————————- /
DEMO_PROG: PROC OPTIONS(MAIN);
DCL 1 WORK_AREA BASED(P_WORK),
2 REC_ID CHAR(4),
2 DATA_LEN FIXED BIN(31),
2 PAYLOAD CHAR(100);
DCL P_WORK POINTER;
DCL P_TARGET POINTER;
DCL MY_CHAR_ADDR CHAR(4) BASED;
DCL OFFSET_VAL FIXED BIN(31);
/ 1. 任意のストレージ領域（例: ゲットストレージ等で取得した領域）を想定 /
/ ここでは説明のため、別の変数からの相対アドレスを計算するシミュレーション /
P_WORK = ADDR(WORK_AREA); / 実際にはSTORAGE BUILTIN等で確保したポインタを設定 /
/ 2. POINTER関数による絶対アドレス/オフセットの演算 /
/ 注: POINTER(ptr, offset)は、ptrにoffsetバイトを加算した新しいポインタを返す /
P_TARGET = POINTER(P_WORK, 8); / REC_ID(4) + DATA_LEN(4) の位置を指す /
/ 3. 別構造の型を無理やり被せてデータを読み取る（C言語のキャストに近い挙動） /
P_WORK->PAYLOAD = ‘HELLO MAIN FRAME WORLD’;
DISPLAY(‘PAYLOAD DATA: ‘ || WORK_AREA.PAYLOAD);
RETURN;
END DEMO_PROG;
ここで注目すべきは `POINTER(ptr, offset)` 組み込み関数です。第一引数にベースとなるポインタ、第二引数にバイト単位のオフセットを指定することで、ハードウェアのポインタ演算を安全かつポータブル（31ビット/64ビットモード両対応）に記述できます。
—
3. コンパイラオプションと最適化の罠
Enterprise PL/I コンパイラを使用する際、アドレス解決やポインタ操作において注意すべきコンパイラオプションがあります。これが不適切だと、本番稼働後に突然のアベンドを引き起こします。
`RENT` (Reentrant) と `NORENT`
基幹システムのオンライン（CICS）や高スループットなバッチでは、プログラムはリエエントラント（再入可能）でなければなりません。
`NORENT` でコンパイルされたプログラム内で静的変数のアドレスを直接書き換えるようなコードを書くと、マルチタスク環境下でメモリ破壊（Storage Violation）を引き起こし、S0C4アベンド や ASCB破壊 という致命的な障害に直結します。
`OPTIMIZE(2)` または `OPTIMIZE(FULL)`
高度な最適化が有効な場合、コンパイラは「このポインタ変数はループ内で変化しない」と勝手に判断し、レジスタにキャッシュしてしまいます。
もし、別のタスクやAMODE 31/64の境界を跨ぐルーチンでストレージが書き換えられている場合、最適化されたコードは古いレジスタ値を参照し続け、データ不整合を起こします。ポインタ経由で外部から書き換わる領域を指す変数には、必ず `VOLATILE` 属性を付与することが、シニアアーキテクトとしての必須作法です。
—
4. アベンド解析の現場：なぜポインタは狂うのか？
現場でよく遭遇するのが、SYSUDUMPやCEEDUMPに記録された `S0C4（Protection Exception）` や `S0C1（Operation Exception）` です。
ある日、夜間バッチが突然 `S0C4` で異常終了しました。トランスレーション・例外です。ダンプリストのPSW（Program Status Word）が指すアドレスと、レジスタ（R14〜R12）の値を確認すると、以下のような原因が特定されます。
1. 無効なポインタの参照（DEREFの失敗）:
`P_WORK` が `NULL`（あるいは不正なアドレス `X’00000000’` や `X’80000000’`）の状態で、`P_WORK->PAYLOAD` にアクセスした瞬間、ハードウェアは物理メモリの保護違反を検出し、容赦なくジョブをアベンドさせます。
2. パックデシマルの内部符号反転バグとアドレスズレ:
これが最も厄介なケースです。PL/Iの構造体において、`FIXED DECIMAL`（パック10進数: `DECIMAL(p,q)`）の領域を、誤って `POINTER` や `CHAR` として無理やりアドレス解決・キャストした場合、符号ニブル（最下位バイトの右側4ビット、通常 `C`, `D`, `F` など）が破損することがあります。
この状態でポインタ演算のオフセット値としてその領域を読み込むと、計算される変位が意図した数値から数千バイトずれてしまい、全く関係ないプログラム領域や別のトランザクションのメモリを破壊する、という悪夢のようなバグに発展します。
—
5. レガシーマイグレーション（Java / C# への移行）における設計の急所
私たちアーキテクトが最も頭を悩ませるのが、このPL/Iのポインタ操作を、Java（Spring Bootなど）やC#（.NET Core）へとモダナイゼーション（マイグレーション）するフェーズです。
JavaやC#には、`ADDR` 関数に相当する「変数の物理メモリ上の仮想アドレスを直接取得する手段」はありません（JNIや `unsafe` コンテキストを使えば不可能ではありませんが、基幹システムの保守性・安全性において御法度です）。
移行アーキテクチャの設計指針
1. ポインタ演算の抽象化とカプセル化:
PL/Iの `BASED` 構造体と `POINTER` による動的レイアウト変更は、移行先言語では 「バイナリバッファ（Javaの `ByteBuffer` や C#の `Memory
メインフレームから渡される固定長バイナリ電文（コピーブック/構造体）を `ByteBuffer` に流し込み、オフセットを指定してデータを切り出すラッパーレイヤーを構築します。
2. ポインタ代入の置き換え:
`P_TARGET = POINTER(P_WORK, 8);` のような処理は、移行先では「バイト配列のオフセットインデックス（Offset Pointer）」、あるいはオブジェクト指向の「ビュー（View）クラス／プロパティ」に置き換えます。
3. アライメントとパディングの厳密な一致:
PL/Iの構造体におけるアライメント規則（`ALIGNED` / `UNALIGNED`）は、移行先のバイナリパーサーでも完全に再現しなければなりません。特に `FIXED BIN(31)` や `FLOAT` の境界調整（Boundary Alignment）の差異を見落とすと、Java側で数値が化ける致命的なバグを生みます。移行プロジェクトでは、ビット単位のテストケース作成が成否を分けます。
—
おわりに
PL/Iの `ADDR` と `POINTER` は、ハードウェアのアーキテクチャとプログラマを直結する強力な機能であると同時に、一歩間違えばシステム全体を崩壊させる諸刃の剣です。
基幹システムの保守であれ、モダンなクラウド環境へのマイグレーションであれ、その背後にある「メモリ管理の物理モデル」を正しく理解しているかどうかが、プロのシステムアーキテクトと単なるコードワーカーを分ける境界線となります。
レガシーの闇を恐れず、ハードウェアからアプリケーション層までを一貫して見通す視座を持って、日々のシステム構築に挑んでいきましょう。
