メインフレームの深淵：ADDR関数と「ポインタ」が支配するメモリ管理のリアル
長年、基幹システムの保守や移行に携わっていると、JavaやC#の「ガベージコレクション」という概念がいかに贅沢なものであるかを痛感します。メインフレームの世界では、メモリは「確保されるもの」ではなく、アーキテクトが「計算して割り当てるもの」です。
特にPL/Iにおいて、`ADDR`ビルトイン関数は、単なるアドレス取得のためのツールではありません。これはシステム制御ブロック（SCB）の深淵を覗き込み、バイナリレベルでデータを操作するための「鍵」なのです。
1. ADDR関数の本質とポインタ演算
PL/Iの`ADDR`関数は、変数の記憶域の先頭アドレスを`POINTER`型として返します。C言語のポインタとは異なり、PL/Iのポインタはベース変数（`BASED`属性）と組み合わせて初めて真価を発揮します。
/i
/ 変数のメモリ構造をマッピングするためのベース変数定義 /
DCL 1 WORK_AREA BASED(P_PTR),
2 FIELD_A CHAR(4),
2 FIELD_B FIXED BIN(31);
DCL P_PTR POINTER;
DCL MAIN_STORAGE CHAR(100) BASED(ADDR(BUFFER)); / BUFFERのアドレスをベースにする /
/ 実際のアドレスを取得し、ポインタを通じて構造体にマッピングする /
P_PTR = ADDR(TARGET_VAR);
ここで重要なのは、コンパイラの最適化オプション（`OPTIMIZE(2)`以上）との兼ね合いです。最適化が有効な場合、コンパイラは「この変数は変更されていない」と判断し、レジスタに値をキャッシュすることがあります。直接`ADDR`でメモリを書き換えるような際どいコードを書く際は、対象変数に`VOLATILE`属性を付与することを忘れてはなりません。これを怠ると、ダンプ解析で原因不明の「値の不整合」に一生悩まされることになります。
2. システム制御ブロックとアベンド（ABEND）の境界線
CICS環境やDB2の埋め込みSQLで、動的なメモリ操作を行う際、`ADDR`で取得したアドレスが「どこを指しているか」を常に意識する必要があります。
特に、オンライン処理中に`ADDR`で取得した領域が、CICSのタスク共用領域（TWA）や共通作業領域（TCTUA）を跨いでいる場合、ページ境界を意識した設計が必要です。不正なアドレス参照による`0C4`（Protection Exception）は、多くの場合、ポインタのオフセット計算ミス、あるいは`BASED`変数の割当解除（`FREE`）後の参照によって引き起こされます。
実務における防御的プログラミング
ダンプ解析時に最も絶望するのは、「どの変数がどのポインタを介して破壊されたか」が追跡できない時です。私は常に以下の手法を推奨しています。
- ポインタのバリデーション: `ADDR`で取得したポインタに対して、必ずベースとなる記憶域の範囲内であることをチェックするアサーションルーチンを通す。
- パックデシマルの符号反転: `ADDR`でメモリを直接操作する際、特に`FIXED DEC`（パックデシマル）の符号ニブル（`C`や`D`）を破壊しないよう注意してください。C言語的な感覚で`MEMSET`をかけると、基幹システムの命綱である数値データが即座に`0C7`（Data Exception）の引き金となります。
3. マイグレーションにおける「負の遺産」の扱い
Java等へのマイグレーションを担当する際、最も障壁となるのはこの「アドレスへの直接アクセス」です。`ADDR`や`OFFSET`を用いたロジックは、そのままでは現代的なマネージド言語には移植できません。
この場合、以下のステップで設計を再構築するのがアーキテクトの腕の見せ所です。
1. ポインタ依存ロジックの可視化: ADDR関数が多用されている箇所を特定し、その「意図」を分析する（多くは、動的なバッファ長変化や、異なるフォーマットのデータ構造を同じメモリ領域で再利用するためのハックです）。
2. 抽象化レイヤーの導入: 直接メモリを触るのではなく、アクセサメソッド（Getter/Setter）を介したデータアクセスに置き換える。
3. レガシー互換のデータコンテナ構築: 移行先環境で、メインフレームのメモリレイアウトを模倣する「バイトバッファクラス」を作成し、オフセット指定による読み書きをシミュレートする。
最後に：アーキテクトへの提言
PL/Iの`ADDR`関数を使いこなすということは、メインフレームの「素のメモリ」と対話するということです。現代のプログラミングでは隠蔽されているメモリ管理の泥臭い部分こそが、基幹システムが何十年もの間、止まることなく稼働し続けてきた根拠でもあります。
移行を検討されている皆さん、コードを書き換える前に、一度`ADDR`が指し示しているその領域が、ビジネスロジックの中で「何を意味しているのか」をもう一度考えてみてください。その答えが分かれば、言語が変わっても、システムの本質を見失うことはありません。
—
本稿が、貴方のデバッグ作業や、次世代システムへの架け橋の一助となれば幸いです。もし`0C4`や`0C7`の深淵に迷い込んだら、いつでもこのコードを思い出してください。
