ポインタ演算の深淵：PL/I `POINTERADD` と構造体操作の極意
メインフレームの現場で「PL/I」という言葉を口にすると、若手エンジニアからは化石のような扱いを受けることもある。だが、この言語のポインタ操作能力と、それに伴うメモリ管理の柔軟性は、C言語のそれよりも遥かに「基幹システム的」な厳密さを内包していることを知るべきだ。
特に、大規模バッチ処理における配列操作の最適化や、CICSの通信領域（COMMAREA）を直接マッピングするような処理において、`POINTERADD` ビルトイン関数は避けて通れない武器となる。今日は、この関数を安全かつ高効率に使いこなすための、現場の知見を共有しよう。
—
1. `POINTERADD` の真価：バイト単位のオフセット操作
PL/Iにおいてポインタ演算は、単なるアドレス計算ではない。`POINTERADD(ptr, offset)` は、指定されたポインタ `ptr` に対して `offset` バイトを加算した新しいポインタを返す。
ここで重要なのは、「型」の概念を一時的にバイパスできるという点だ。構造体配列を走査する際、単に `PTR = ADDR(ARRAY(I))` と書くよりも、ベースポインタを起点に `POINTERADD` でオフセットを操作する手法をとることで、コンパイラのオーバヘッドを抑制し、動的なメモリレイアウトに対する耐性を高めることができる。
1
/ 構造体配列へのポインタ動的アクセス例 /
DCL 1 TABLE_STRUCT BASED(P_BASE),
3 ITEM_KEY CHAR(8),
3 ITEM_VAL FIXED BIN(31);
DCL P_BASE POINTER;
DCL P_WORK POINTER;
DCL ENTRY_SIZE FIXED BIN(31) INIT(12); / 8 + 4 = 12バイト /
/ 配列の第N番目の要素へ直接アクセス /
/ POINTERADDはバイト単位で計算するため、インデックス計算が必須となる /
P_WORK = POINTERADD(P_BASE, (N – 1) ENTRY_SIZE);
/ ここでP_WORKを使用して構造体にアクセス /
/ 構造体のメンバレイアウトが固定されている場合、この手法は極めて高速 /
PUT SKIP LIST(TABLE_STRUCT.ITEM_KEY -> P_WORK);
2. マイグレーションにおける罠：パックデシマルとポインタの相性
JavaやC#への移行を検討するアーキテクト諸氏に警告しておきたい。PL/Iのポインタ操作で最も恐ろしいのは、`FIXED DECIMAL`（パックデシマル）が絡んだ時の内部表現だ。
構造体の中にパックデシマルが含まれている場合、`POINTERADD` で誤ったオフセットを指定すると、符号（Sign）ビットがデータ領域の先頭に食い込み、S0C7（データ例外）を引き起こす。Java側で `BigDecimal` に変換する際、メインフレームの「F（正）」や「C（正）」といった符号ビットを正しくハンドリングできていないと、移行後のDB2で数値整合性が崩れるという、最も泥沼化しやすいバグに直面する。
現場のTips:
移行コードを書く際は、必ず `DCL … ALIGNED` オプションを指定し、境界調整（アラインメント）を明示すること。`UNALIGNED` はメモリを節約するが、ポインタ操作の難易度を劇的に引き上げる。
3. ダンプ解析：S0C4を恐れるな
`POINTERADD` を多用するコードでアベンドが発生した場合、大抵の原因は「アドレスの指し示す先が、現行プログラムのストレージ保護違反（S0C4）」である。
ダンプを解析する際、まずは `P_WORK` が指すアドレスが、`GETMAIN` で確保した領域の境界内にあるかを確認せよ。もし構造体のサイズを計算ミスし、配列の終端を超えて `POINTERADD` を実行した場合、後続の制御ブロックを破壊し、不可解なタイミングで別の箇所がアベンドする「時限爆弾」が埋め込まれることになる。
- チェックポイント: `STORAGE` コンパイラオプションを有効にし、デバッグ時には `CHECKSTG` を併用すること。
- 最適化: 本番環境では `OPTIMIZE(2)` を使用するが、ポインタ操作が頻出するモジュールでは `NOSTG`（ストレージの最適化を抑制）を検討せよ。コンパイラがポインタの再利用を誤って最適化し、意図しないアドレスへジャンプする事故を防ぐためだ。
4. 最後に：SQLとCICSの境界線上で
DB2の埋め込みSQLやCICSのAPIを使用する際、SQLCA（SQL Communications Area）や通信領域に対して `POINTERADD` を適用する場面があるだろう。この時、「コンパイラが暗黙的に生成する制御ブロック」のサイズを考慮していないコードは、将来的にメンテナンス不能となる。
PL/Iは、システムと最も近い距離で対話できる言語だ。`POINTERADD` を駆使するということは、システムのメモリマップを完全に掌握しているという自負の裏返しでもある。
マイグレーション先がどんなに現代的な言語であっても、この「メモリのどこに何があり、どうアクセスすべきか」というアーキテクトの視点は、決して失われてはならない。それが、汎用機で培った我々の、最大の強みなのだから。
