メインフレームの深淵：PL/Iポインタ演算とアライメントの「見えない罠」を攻略する
やあ、今日もバッチジョブの解析でメインフレームのログと睨めっこしている諸君。お疲れ様。
今日は、PL/Iにおける「ポインタ演算」という、一歩間違えれば基幹システムのメモリを破壊しかねない、しかし強力な武器について話そうと思う。
最近のマイグレーション案件で、「なぜか本番環境で特定レコードを読み込むと異常終了（S0C4など）する」という相談を受けた。コードを追うと、`POINTER`型を駆使した怪しげなアドレス計算が散見された。現代の高級言語に慣れた若いエンジニアにとって、PL/Iのメモリ管理は時に「魔法」に見えるかもしれないが、これは物理メモリを直接叩く泥臭い作業なんだ。
今日は、その「魔法」を正しく制御するための鉄則を伝授する。
1. ポインタ演算の基本：加算と「型」の誤解
まず、PL/Iでポインタに数値を足す際は、単なる「バイト単位の加算」であることを忘れてはいけない。C言語のように「ポインタの指す型（構造体）のサイズ分だけ自動で加算される」なんて親切な機能はないんだ。
/i
/ — ポインタ加算の正しい扱い方 — /
DCL PTR POINTER;
DCL ADDR_VAL FIXED BIN(31);
/ 構造体のサイズを取得して計算に使う /
/ STG_SIZEはストレージのバイト数 /
PTR = PTR + STG_SIZE;
ここで多くの初学者が犯すミスは、`FIXED BIN`の精度不足だ。64ビットモード（z/Architecture）が主流の今、アドレス空間は巨大だ。`FIXED BIN(15)`でアドレス計算をしようものなら、即座に桁あふれで計算結果が狂う。必ず `FIXED BIN(31)` か `FIXED BIN(63)` を使う癖をつけろ。
2. アライメント違反：なぜ「性能劣化」どころか「異常終了」するのか
ここからが本題だ。メインフレームにおいて、CPUはメモリ上のデータを「キリの良いアドレス」から読み込むことを好む。これを境界アライメント（Alignment）と呼ぶ。
例えば、`FIXED BIN(31)`（4バイト）のデータは、必ず4の倍数のアドレスに配置される必要がある。もしポインタを適当に加算して、奇数番地から整数値を読み込もうとするとどうなるか？
- 性能劣化: CPUが「非整列アクセス」を補正するために余分なサイクルを回す。バッチ全体の実行時間が地味に延びる原因だ。
- 異常終了 (S0C7/S0C4): 厳格なモデルや、特定の命令セット（浮動小数点演算など）では、アライメント違反は即座に例外を発生させる。
実践：アライメントを考慮した安全なポインタ操作
レコードを読み込み、可変長部分をポインタでなぞる際は、以下のように「次に進むべき正しいアドレス」を計算しなければならない。
/i
DCL BUFFER_PTR POINTER;
DCL OFFSET FIXED BIN(31);
DCL 1 MY_RECORD BASED(BUFFER_PTR),
2 KEY_FLD CHAR(4),
2 VAL_FLD FIXED BIN(31);
/ 安全な境界アライメント計算の例 /
/ 4バイト境界に合わせるために、端数を切り上げて加算する /
/ (現在のオフセット + 3) / 4 4 というテクニックを使う /
OFFSET = ADDR(BUFFER_PTR->VAL_FLD) – ADDR(BUFFER_PTR);
OFFSET = ((OFFSET + 3) / 4) 4;
/ 正しい位置にポインタを再配置 /
BUFFER_PTR = ADDR(BUFFER_PTR) + OFFSET;
3. ONユニットとポインタの関係：エラーを「飲み込む」な
現場でよく見るアンチパターンが、`ON CONDITION(ANYCONDITION)` でエラーを握りつぶす実装だ。ポインタ不正によるアドレス違反は、致命的なセグメンテーションフォールトだ。
/i
/ ダメな例：問題の所在が見えなくなる /
ON ERROR BEGIN;
PUT SKIP LIST(‘エラーが発生しました’);
END;
/ 良い例：スタックトレースを残し、PL/Iの標準的なダンプを活用する /
/ ONユニットは最小限のクリーンアップに使い、異常終了を隠蔽しないこと /
最後に：ベテランからのアドバイス
ポインタは、基幹システムのVSAMファイルから直接データを引き抜く際や、バッファリングされた大規模データを高速に処理する際には不可欠だ。しかし、それは「型安全」というガードレールを自ら外す行為でもある。
1. `ADDR`関数と`NULL`関数を使い倒せ。
2. `BASED`変数の定義には、必ず`ALIGNED`属性を明示しろ。（デフォルトの`UNALIGNED`は省メモリだが、今回のような罠にハマりやすい）
3. デバッグ時は必ずコンパイラオプション `CHECK(SUBSCRIPTS, POINTERS)` を有効にしておけ。（本番では外すのが鉄則だが、開発・テスト段階でこのチェックを外すのは愚の骨頂だ）
君たちが書くコードは、数十年後の誰かがメンテナンスする可能性が高い。ポインタを使ったトリッキーなコードを書くときは、「なぜこの計算が必要なのか」を詳細にコメントに残してくれ。それが、この過酷なメインフレームの現場で生き残るプロフェッショナルの矜持というものだ。
さて、またコンパイルリストの山が呼んでいる。諸君の健闘を祈る。
