奈落の淵からシステムを救い出す：CEE3DMPによるPL/Iランタイムダンプ深層解析術
基幹システムの現場において、深夜のバッチ処理で突如発生する「S0C7」や「S0C4」。画面の向こうで震える運用担当者の顔が浮かぶとき、我々アーキテクトの真価が問われます。
現代のJavaエンジニアがスタックトレースを眺めるように、我々はLanguage Environment (LE) が吐き出す`CEE3DMP`の海を泳ぎ切らねばなりません。今回は、PL/Iの動的メモリ操作からDB2・CICSの罠までを網羅した、ダンプ解析の極意を伝授します。
1. スタックフレームの深淵：レジスタとバックチェインを追う
ダンプを読み解く第一歩は、現在の「実行地点」を特定することです。LEのダンプにおいて重要なのは、単なる命令アドレスではありません。
- R13（保存エリアポインタ）: ここから遡る「バックチェイン」こそが、サブルーチンの呼び出し履歴（トレースバック）の命綱です。
- PSW（プログラムステータスワード）: アベンド発生時の正確なアドレスを示します。ここから`CSECT`のロードモジュールマップを照合し、ソースコードのどの行（あるいはコンパイラが生成したどの機械語）に該当するかを特定します。
もし、最適化オプション（`OPTIMIZE(2|3)`）を付与している場合、変数の一部はレジスタに保持され、メモリ上の値と一致しないことがあります。このとき、コンパイラが生成した`LIST`（アセンブラコード）と照らし合わせ、変数がレジスタへ退避されたタイミングを追うのが、ベテランの流儀です。
2. ポインタとベース変数：動的メモリの「地雷」
PL/Iの真骨頂であるポインタ演算と`BASED`変数は、メモリ破壊の温床でもあります。特に、以下のコード例のような領域オーバーラップは、ダンプ解析で最も頻繁に遭遇する光景です。
1
/ ポインタを用いた動的データ操作の例 /
DCL P_REC POINTER; / メモリ上のアドレスを保持するポインタ /
DCL 1 MY_REC BASED(P_REC), / P_RECが指す領域を構造体として定義 /
5 ID CHAR(4),
5 DATA CHAR(20);
/ 不適切なオフセット計算によるメモリ破壊の典型例 /
P_REC = ADDR(BUFFER) + 4; / 意図せぬ位置から構造体を重ねる /
MY_REC.ID = ‘ABCD’; / ここで本来の領域を超えて書き込む危険性 /
このような動的メモリ操作においてアベンドが発生した場合、`CEE3DMP`内の「Storage」セクションを確認してください。問題のポインタが指しているアドレスの前後を確認し、隣接する領域のデータが破壊されていないか、あるいはポインタ自体が不正な値（`00000000`や`FFFFFFFF`）になっていないかをチェックします。
3. パックデシマル内部表現の罠
マイグレーション時に特に頭を抱えるのが、`PIC S9(7) COMP-3`といったパックデシマル変数の「符号反転バグ」です。
本来、パックデシマルの末尾ニブルは`C`（正）または`D`（負）であるべきですが、演算過程でゴミデータが混入し、`F`などが紛れ込むと、演算命令実行時に即座にアベンドします。`CEE3DMP`で該当変数の16進ダンプを確認し、末尾の数値が仕様に合致しているかを見極める力が必要です。これは、レガシーデータをJavaの`BigDecimal`へ移行する際の「データの汚染」調査でも必須のスキルとなります。
4. エッジケースの防波堤：CICSと埋め込みSQL
CICSオンライン処理で`ABEND ASRA`が発生した場合、PL/IプログラムはLEの管理下にあるため、通常のバッチとは異なるスタックトレースを生成します。
- CICS特有の対処: `EXEC CICS`コマンドの前後の変数をダンプで確認してください。特に、通信領域（COMMAREA）の定義不一致は、オンライン環境特有の難問です。
- SQLCAの確認: DB2の埋め込みSQLでアベンドした場合、まず`SQLCODE`を見てください。PL/Iの`SQLCA`構造体はダンプ内でも容易に特定できます。`-811`（複数行戻り）や`-911`（デッドロック）といったエラーが、プログラムの論理破綻を隠蔽しているケースは枚挙に暇がありません。
結論：ダンプは「動かぬ証拠」である
マイグレーションを進める上で、レガシーコードの「挙動」を理解せずにJavaやC#へ変換することは、沈没船をそのまま再利用しようとするようなものです。
PL/Iのダンプは、冷徹な機械語の世界と、人間が記述したロジックの狭間にある「真実」を映し出す鏡です。`CEE3DMP`を読み解く力は、単なるデバッグ能力を超え、システムの本質的な信頼性を担保する技術者としての誇りそのものなのです。
もし貴方のプロジェクトで解決不能なバグが渦巻いているなら、まずはダンプを印刷し、コンパイラの最適化オプションを疑い、ポインタの先にある16進数の羅列と対話してみてください。そこにこそ、真の解決策が眠っています。
