現場の暗闇を照らす灯火：OFFSETオプションとダンプ解析の深淵
基幹システムの保守に携わるエンジニアにとって、深夜のバッチ処理で発生する「SYSTEM ABEND S0C7」ほど心拍数を上げるものはないだろう。データ例外、あるいはポインタの暴走。ソースコードを睨みつけても、最適化されたバイナリの迷宮の中で、一体どこで「運命の分岐」が起きたのかを突き止めるのは容易ではない。
今日は、そんな泥沼のデバッグから脱出するための最強の武器、PL/Iコンパイラオプション `OFFSET` について語ろうと思う。
—
1. なぜ「OFFSET」なのか：コンパイラの最適化という壁
PL/Iプログラムをコンパイルする際、`OPTIMIZE(2)` や `OPTIMIZE(3)` を指定すると、コンパイラはコードの効率化のために命令順序を組み替えたり、冗長な命令を削除したりする。これが実行速度には寄与するが、ダンプ解析の際には大きな障壁となる。
`LIST` オプションだけでは不十分だ。そこで `OFFSET` を指定する。これにより、コンパイルリストには「ステートメント番号」と「命令のオフセット値」が明示的に出力されるようになる。これは、CEE3DMP（Language Environmentのダンプ）に吐き出された、あの忌々しい「Offset: +000001A4」という数字を、ソースコードの具体的な行番号へ逆引きするための羅列だ。
OFFSET利用の基本設定
/ コンパイルオプション例 /
PROCESS OPTIONS(MAIN) LIST OFFSET MAP SOURCE
この設定を加えるだけで、ダンプ解析の所要時間は劇的に短縮される。もしあなたが現在、勘と経験だけでアベンド箇所を追いかけているのなら、今すぐコンパイルJCLを見直すべきだ。
—
2. 実践：ダンプとソースの照合手順
CEE3DMPから「Instruction address」を特定したら、以下の手順で掘り下げる。
1. エントリーポイントの確認: ダンプ内の「Entry Point Address」を特定する。
2. 相対アドレスの算出: `アベンド発生アドレス – エントリーポイントアドレス = 相対オフセット`
3. リストとの突き合わせ: コンパイルリストの `OFFSET` カラムを眺め、算出したオフセット値が収まる範囲のステートメントを探す。
このとき、`MAP` オプションも併用しておくのが鉄則だ。変数（特にベース変数を用いた動的構造体）がどこに配置されているかを把握していないと、ポインタが指し示す先のメモリが正しいのか、それとも別の領域を破壊しているのか判断できないからだ。
—
3. 現場のエッジケース：パックデシマルとポインタの罠
移行案件でよく遭遇するのが、ポインタ操作によるメモリ破壊だ。C言語などからマイグレーションする際、PL/Iの `BASED` 変数をポインタとして扱う感覚を誤解しているケースが散見される。
DCL P_PTR POINTER;
DCL 1 MY_DATA BASED(P_PTR),
2 FIELD_A FIXED DEC(5,0),
2 FIELD_B CHAR(10);
/ ポインタの割り当て忘れや範囲外アクセスは、 /
/ 往々にしてパックデシマルの内部符号（最後のニブル）を /
/ 破壊し、S0C7を誘発する /
P_PTR = ADDR(WORK_AREA);
MY_DATA.FIELD_A = 12345;
特に、DB2からFETCHした結果を構造体にマップする際、インジケータ変数を無視してヌル値を数値項目に放り込むと、LE（Language Environment）は容赦なく例外を投げる。また、古いCOBOL資産からの移行で、`PACKED-DECIMAL` の内部表現（符号反転）が想定外のビットパターンになっている場合、PL/Iの厳格な型チェックが火を噴く。これらは `OFFSET` で追いかけ、ダンプ上の16進数データを `DUMP` 文で解析するしかない。
—
4. マイグレーション時代に求められる「視点」
JavaやC#への移行を検討するテックリードたちへ。
レガシーコードの解析において、単なる「ロジックの書き換え」は二の次だ。重要なのは、「なぜそのPL/Iがそのメモリレイアウトをとっていたのか」という設計の意図を汲み取ることにある。
- CICSオンライン処理: 疑似会話型（Pseudo-conversational）の処理において、COMMAREAを通じて引き回されるデータ構造のオフセットがずれた瞬間、システム全体が崩壊する。
- 最適化の罠: コンパイラが「この変数はループ内で変化しない」と判断し、レジスタにキャッシュした値を、外部からの非同期なメモリ書き換えが検知できないケース。これらはマイグレーション先の言語でも、メモリモデルの違いとして現れる。
—
結びに：技術の深淵を愛する者たちへ
PL/Iは、決して過去の遺物ではない。メインフレームという閉じた、しかし極めて堅牢な世界で培われた「メモリを直接制御する感覚」と「厳密な型管理」は、現代の分散システムにおいてもエンジニアの素養として極めて重要だ。
もしあなたが今日、ダンプファイルの海に溺れそうになっているのなら、一度深呼吸をして `OFFSET` を見直してほしい。機械が吐き出す数字の羅列は、決して無機質なものではない。そこには、過去の誰かが書いたロジックの鼓動が、確かに刻まれているのだから。
次は、`CEEHDLR` を用いた動的な例外処理のハンドリングについて深く掘り下げてみよう。あれを知れば、もう異常終了で夜中に叩き起こされる回数は減るはずだ。
