【PL/I深掘り】BASED変数とREFERオプション：可変長データをスマートに捌く極意
メインフレームの現場で、長年使い込まれた基幹システムのコードを紐解いていると、たまに「おっ、やるな」と思わせるトリッキーな構造に出くわすことがある。その筆頭が、`BASED`変数と`REFER`オプションを組み合わせた可変長構造体だ。
「なぜわざわざポインタを使うのか？」「メモリレイアウトはどうなっているんだ？」――若手エンジニアからそんな質問を投げかけられることも多い。今日は、この一見取っ付きにくいが、実は非常に強力なこの機能について、現場で泣きを見ないための勘所を伝授しよう。
—
なぜREFERオプションが必要なのか
通常、PL/Iで配列を定義する場合、サイズはコンパイル時に固定される。しかし、バッチ処理で扱うレコードの多くは、ヘッダ情報の後に「明細データの数」という制御変数が置かれ、その数に応じて明細部分の長さが変動する構造を持っている。
これを素直に実装しようとして、最大サイズで固定領域を確保するのはメモリの無駄だ。かといって毎回`ALLOCATE`で動的に切り出すのも非効率な場合がある。そこで登場するのが`REFER`オプションだ。
実践：REFERオプションを用いた可変長構造体の定義
以下のコード例を見てほしい。VSAMファイルから読み込んだバッファを、この構造体にマップさせるのが最も一般的な実務パターンだ。
/i
//
/ 可変長データ構造体の定義例 /
//
DCL 1 HEADER_REC BASED(P_REC),
2 RECLEN FIXED BIN(31), / 全体長 /
2 ITEM_COUNT FIXED BIN(15), / 明細データの個数 /
2 ITEM_LIST(1 REFER(ITEM_COUNT)) / REFERによる制御 /
CHAR(10); / 1明細のサイズ /
DCL P_REC POINTER; / 構造体を指すポインタ /
DCL BUF_AREA CHAR(1024) BASED(P_BUF); / 受信バッファ /
このコードの肝は、`ITEM_LIST(1 REFER(ITEM_COUNT))`という記述だ。
`ITEM_COUNT`の値が、そのまま`ITEM_LIST`の配列要素数として動的に解釈される。これにより、コンパイラは「この構造体の実サイズは、その時の`ITEM_COUNT`の値に依存する」ことを理解する。
—
メモリレイアウトの「暗黙の了解」に注意せよ
ここで一つ、ベテランとして釘を刺しておきたい。`REFER`を使用する際、メモリレイアウトは「先行する制御変数」と「後続する配列」が物理的に連続していることを前提としている。
VSAMアクセス時や`READ INTO`を使用する際、もしバッファの先頭番地を正しく設定せずに構造体を割り当てると、`ITEM_COUNT`が予期せぬゴミ値を読み込み、`ITEM_LIST`の境界を誤認識してストレージ保護違反（S0C4）を食らうことになる。
デバッグの現場でのコツ
もし、デバッグ中に「なぜか配列の途中でデータが化ける」という事象に遭遇したら、以下の点を確認してほしい。
1. ポインタの再設定: `ALLOCATE`を行う前、あるいはバッファを指し直すたびに、ポインタ（`P_REC`）が正しいアドレスを向いているか。
2. 制御変数の整合性: `ITEM_COUNT`にセットした値が、実際に読み込んだレコードの物理的な明細数と一致しているか。
3. ONユニットの活用: `ALLOCATE`やアクセス時のエラーをキャッチするために、以下のようなONユニットを仕込んでおくのが定石だ。
/i
ON STORAGE CONDITION
BEGIN;
PUT SKIP LIST(‘ ストレージエラー発生: 変数REFERの整合性を確認せよ ‘);
/ ここで必要に応じてダンプを出力する /
SIGNAL FINISH;
END;
—
現場で戦うエンジニアへのメッセージ
`REFER`オプションは、現代の言語仕様から見れば少し古風なテクニックに見えるかもしれない。しかし、メモリリソースを極限まで絞り出し、かつ高速なバッチ処理を実現し続けてきたメインフレームの歴史そのものだ。
`BASED`変数を使うということは、メモリ管理の責任をプログラマが引き受けるということだ。コンパイラ任せにせず、メモリレイアウトを頭の中で描きながらコードを書く。その姿勢こそが、大規模マイグレーションや保守の現場で、バグを未然に防ぐ唯一の道になる。
さあ、次回のバッチ改修では、この構造を怖がらず、適切に制御してみてほしい。理解さえすれば、これほど頼りになる相棒はないのだから。
