【PL/I深層解説】BASED変数とポインタ操作：諸刃の剣を使いこなすための現場の流儀
メインフレームの現場で長く生き残っていると、時折「触りたくない」コードに出くわすことがある。その筆頭が、BASED属性とポインタを駆使して、メモリを強引にマッピングしているソースだ。
若手エンジニアから「なぜポインタなど使うのか？静的な構造体宣言でいいのではないか？」という質問をよく受ける。確かに、通常の業務ロジックでは不要だ。だが、VSAMの可変長レコードを高速に解析したり、巨大なメモリ・バッファを効率的に使い回す必要がある時、この「メモリの直接操作」は最強の武器になる。
今日は、PL/IにおけるBASED変数とポインタを安全に、かつプロフェッショナルに扱うための指針を授けよう。
—
1. BASED属性とADDR関数の本質
PL/Iの`BASED`変数は、メモリ上の特定の場所（アドレス）を、特定の「型（構造体定義）」として解釈させるためのテンプレートに過ぎない。実体はそこに存在せず、ポインタ変数が指し示すアドレスを参照して初めて意味を持つ。
実践コード：構造体の動的マッピング
まずは、VSAMから読み込んだバッファを、構造体としてマップする基本的なパターンを見てほしい。
1
/ VSAMからの読み込みバッファをポインタでマッピングする例 /
DCL BUFFER_PTR PTR; / アドレスを保持するポインタ /
DCL 1 IN_REC BASED(BUFFER_PTR), / バッファをこの構造体として解釈 /
2 REC_TYPE CHAR(1), / レコード種別 /
2 REC_BODY CHAR(100); / 本体 /
DCL WORK_AREA CHAR(101) BASED(ADDR(IN_REC)); / 実際には動的確保された領域を指す /
/ 処理開始 /
/ 何らかの手段でバッファのアドレスをBUFFER_PTRにセット /
BUFFER_PTR = ADDR(SOME_STORAGE_AREA);
IF IN_REC.REC_TYPE = ‘A’ THEN DO;
/ ここでポインタによる直接アクセスが実行される /
CALL PROCESS_TYPE_A(IN_REC.REC_BODY);
END;
ここで重要なのは、`ADDR`ビルトイン関数が返すのは「その変数が格納されているメモリ位置」であるという点だ。このアドレスをポインタ変数に代入することで、コンパイラは「そのメモリを`IN_REC`として扱え」と命令されることになる。
—
2. ポインタ演算の「危険な罠」
多くの障害は、ポインタに対する「算術演算」から生まれる。`P = P + 10;` といったコードを書く際、PL/Iはそれが「バイト単位」なのか「型単位」なのかを判断する。
- バイト単位の加算: ポインタそのものに加算する場合、明示的に`SYSINCL`等のOSレベルの関数や、`PL/I`固有の`OFFSET`データ型を使わない限り、意図しないオフセットずれを引き起こしやすい。
- 構造体配列の走査: これが最も多いバグの温床だ。ポインタをインクリメントする際、構造体定義のサイズを意識していないと、メモリ破壊（オーバーレイ）が発生し、原因不明の異常終了（S0C4やS0C7）を招く。
現場の教訓： ポインタ演算を多用するコードを書くなら、必ず`ON CONDITION(STORAGE)`や`ON ERROR`を用いて例外をトラップし、ダンプリストを解析できるようにしておくこと。
—
3. ONユニットによる制御フローと安全性
ポインタ操作を行う際は、必ずと言っていいほど異常終了のリスクが伴う。特に、無効なアドレスを指した状態で構造体にアクセスした瞬間に発生する「アドレッシング例外」は、バッチ処理を即座に停止させる。
1
/ 安全なメモリアクセスのためのONユニット /
ON CONDITION(ANY_ERROR) BEGIN;
PUT SKIP LIST(‘メモリ操作中に予期せぬエラーが発生しました’);
PUT SKIP LIST(‘現在のポインタアドレス:’, HEX(BUFFER_PTR));
SIGNAL ERROR; / 呼び出し元へ戻す /
END;
複雑なメモリ操作を行う箇所では、上記のように`ON`ユニットでエラーを捕捉し、せめて「どのポインタが、どのアドレスを指していたか」をログに残すコードを仕込んでおくのが、ベテランの流儀だ。
—
4. 最後に：なぜ「使うべきではない」のかを理解せよ
ここまで解説しておいて何だが、「本当に必要か？」を自問自答してほしい。
最近のコンパイラは優秀だ。最適化オプションを適切に設定すれば、無理にポインタでメモリを操作しなくても、十分なパフォーマンスが出る。BASED変数によるポインタ操作は、保守性を著しく低下させる。後からコードを読む担当者が、メモリレイアウトを頭の中で再構築しなければならないからだ。
もし君が大規模なマイグレーションや、極限のパフォーマンスが求められるバッチ改修を担当しているなら、この技術は君を救う。だが、そうでないなら、静的な構造体定義と`BY NAME`代入などの安全な構文を優先すべきだ。
メインフレームのコードは、書くときよりも「読まれるとき」に価値が決まる。そのことを忘れないでほしい。
—
何か不明な点や、実際のソースコードで「なぜここでS0C4が出るのか」といった悩みがあれば、いつでも相談してくれ。PL/Iのコンパイラ挙動を紐解けば、必ず原因はあるはずだ。
