メインフレームの深淵へようこそ：PL/IのBASED変数とポインタで「メモリを直接操る」極意
こんにちは。メインフレームの荒波を乗りこなすシステムアーキテクトです。
これまでJavaのガベージコレクションに守られ、あるいはCOBOLの堅牢なデータ定義に親しんできた皆さんにとって、PL/Iの世界に足を踏み入れるのは、まるで「舗装された道路から、地図なき未開の原野へ飛び出す」ような感覚かもしれません。
特に、今回解説する「BASED変数」と「ポインタ」は、PL/Iの最も強力であり、かつ最もスリリングな機能です。OSのメモリ領域に直接触れるこの技術をマスターすれば、基幹システムのバッチ処理で見かける「謎のバッファ操作」も手に取るように理解できるようになりますよ。
—
1. 「BASED変数」とは何か？：型のない箱にラベルを貼る
JavaでいうクラスやCOBOLのコピー句を想像してください。通常、変数を宣言すると、その分だけメモリが確保されますよね。しかし、`BASED`属性を使うと話が変わります。
BASED変数は、「そこにデータがあるという定義（型）」だけを先に作っておき、具体的なメモリ場所（番地）は後からポインタで指定するという仕組みです。
例えるなら、「中身が何であれ、ここにこのサイズの箱を置く！」という設計図だけを用意し、ポインタを使ってその設計図を「特定のメモリ番地」にパコッとはめ込むイメージです。
2. コードで見る「メモリ・マッピング」の実践
では、実際にコードを見てみましょう。メインフレームの現場でよく使われる、構造体の動的なマッピング例です。
1
/ 構造体の定義（BASEDなので、この時点ではメモリを消費しません） /
DCL 1 MY_RECORD BASED(P_PTR),
2 ID CHAR(4),
2 AMOUNT FIXED BIN(31);
/ ポインタ変数の宣言 /
DCL P_PTR POINTER;
/ 外部からのバッファデータを受け取るためのポインタ操作 /
/ 例えば、OSから渡されたバッファアドレスをADDR関数で指定する /
P_PTR = ADDR(BUFFER_AREA);
/ これで、BUFFER_AREAの先頭がMY_RECORDの構造で扱えるようになります /
PUT SKIP LIST(‘IDは: ‘ || MY_RECORD.ID);
このコードの肝は、`P_PTR`という「住所」を書き換えるだけで、同じ`MY_RECORD`という定義を使って、メモリ上のあちこちにあるデータを自由自在に読み書きできる点にあります。
3. なぜこんな危険なことをするのか？
COBOL経験者の方は「なぜわざわざ面倒なことを？」と思われるかもしれません。しかし、基幹システムのバッチ処理では、以下のようなケースが頻繁に発生します。
- 異なるフォーマットのデータが1つの大きなバッファに混在している場合：
ポインタを少しずつずらして（ポインタ演算）、頭から順に異なる構造体をマッピングしていくことで、高速に解析できます。
- ストレージ・ダンプの解析：
システムが異常終了した際、メモリ上に残された生のバイナリデータに対し、このテクニックを使って「強引に構造体を被せる」ことで、何が起きていたのかを解明するのです。
4. 忘れないで！ポインタ演算の注意点
PL/Iには、他の高級言語にはない「自由度」があります。しかし、自由には責任が伴います。
- 「迷子」にならないこと：
ポインタが指し示す先が、OSの保護領域や無効な番地だった場合、プログラムは容赦なく「SYSTEM ABEND（強制終了）」します。
- アライメントの罠：
`FIXED BIN`などの数値データは、メモリの「4バイト境界」などに配置されるのが一般的です。ポインタを適当にずらしてマッピングすると、実行時にエラーが出るか、ゴミデータが読み込まれます。
最後に：怖がる必要はありません
「ポインタ操作」と聞くと、C言語のポインタ恐怖症を思い出す方もいるでしょう。ですが、PL/IのBASED変数は、「データの入れ物（型）」を整理整頓するために使うと割り切れば、非常に強力な武器になります。
まずは、既存のプログラムで`BASED`というキーワードを見つけたら、「あ、ここはメモリを動的に見ているんだな」とマークしてみてください。それだけで、コードを読む解像度がグッと上がります。
メインフレームの世界へようこそ。また一つ、黒い画面の向こう側の景色が見えてきましたね。何か分からないことがあれば、いつでも相談してください。共にレガシーの知見を深めていきましょう。
