メインフレームの深淵：BYADDRとBYVALUEが織りなすメモリの罠
諸君、今日もレガシーの海で格闘していることだろう。PL/Iという言語は、一見すると古臭い記法に見えるかもしれないが、そのメモリ制御の柔軟性は現代の高級言語など足元にも及ばない。だが、その柔軟性ゆえに、一度足を踏み外せば「S0C4（Storage Protection Exception）」という名の深淵が待っている。
今回は、PL/Iにおける引数受け渡し、特に `BYADDR` と `BYVALUE` がメモリレイアウトに与える影響と、それが引き起こす悪夢のようなデバッグ現場について語ろうと思う。
—
1. BYADDRとBYVALUE：メモリ上の挙動を解剖する
PL/Iのデフォルトは `BYADDR` だ。呼び出し側の変数の「アドレス」をサブルーチンに渡す。一方、`BYVALUE` は変数の「値」そのものを直接レジスタ（あるいはスタック）にコピーする。
この違いは、アセンブラレベルで見れば一目瞭然だ。
1
/ 呼び出し側 /
DCL A FIXED BIN(31) INIT(100);
CALL SUB(A); / デフォルトはBYADDR /
/ 受け取り側（BYADDR） /
SUB: PROC(P_VAL) OPTIONS(BYADDR);
DCL P_VAL FIXED BIN(31) BYADDR;
/ P_VALは呼び出し側のAそのものを指すポインタ経由でアクセスされる /
END SUB;
`BYADDR` の場合、コンパイラは `P_VAL` を「間接参照（Indirection）」するためのコードを生成する。もし受け取り側で `BYVALUE` を指定し、呼び出し側が `BYADDR`（デフォルト）のままであれば、サブルーチンは「アドレス値そのもの」を数値として受け取り、その番地をメモリデータとして読みに行こうとする。
結果、不正なメモリアドレスへのアクセスにより S0C4 アベンドが即座に発生する。これはマイグレーション時に最も多く見られる人為的ミスの典型だ。
—
2. S0C4の真相：ダンプ解析と最適化の罠
現場で最も厄介なのは、コンパイラの「最適化レベル」が絡むケースだ。`OPTIMIZE(2)` や `(3)` を指定すると、コンパイラは頻繁に使用される変数をレジスタにキャッシュする。
もしあなたがパッチを当てたモジュールで、引数の属性不一致を残したまま再コンパイルすると、開発環境では動いていたものが、本番環境の最適化をかけた途端にコケることがある。
ダンプ解析のヒント：
1. PSW（プログラムステータスワード）の確認: 異常終了時の命令アドレスを特定せよ。
2. レジスタの追跡: 異常発生時のレジスタに、本来保持すべき「データの値」が入っているか、それとも「アドレスのような値」が入っているかを確認する。もし後者であれば、それは呼び出し規約の不一致だ。
3. Linkage Sectionの確認: CICS環境であれば、通信域（COMMAREA）の定義と呼び出し側のレコード構造が厳密に一致しているか。特に `PACKED DECIMAL` の桁数が合わないまま `BYADDR` で渡すと、符号ビットがずれてしまい、数値計算時に `S0C7（Data Exception）` を引き起こすこともある。
—
3. 実践：安全なインターフェース設計のために
マイグレーションを担当するアーキテクトとしては、以下のコーディング規約を強く推奨する。
1
/ 推奨するコーディング規約の例 /
PROC_SAMPLE: PROC(ARG_VAL) OPTIONS(MAIN);
/ 引数には明示的に属性を付与し、意図を明確にする /
DCL ARG_VAL FIXED BIN(31) BYVALUE;
/ 埋め込みSQL（DB2）使用時の注意：NULLインジケータも同様 /
/ ポインタを用いて動的にメモリを確保する場合は、必ず初期化を行う /
DCL PTR_DATA PTR;
ALLOCATE DATA_STRG SET(PTR_DATA);
/ 確実にポインタをゼロクリアし、未定義参照を排除する /
PTR_DATA = NULL();
END PROC_SAMPLE;
特にDB2のホスト変数やCICSのタスク間通信において、`BYADDR` の属性不一致は「データが化ける」という最も検知しにくいバグを生む。`BYVALUE` を明示的に指定することで、スタック経由のコピーが行われ、呼び出し側のメモリ領域を不用意に破壊するリスクを大幅に低減できる。
—
4. 最後に：レガシーを「継承」するということ
JavaやC#への移行を検討する諸君へ。オブジェクト指向言語の「参照渡し」と「値渡し」をPL/Iの視点で再解釈してほしい。Javaのオブジェクト参照は実質的にポインタだが、PL/Iの `BYADDR` はそれよりも遥かに原始的で、かつ強力だ。
PL/Iのコードを解析することは、コンピュータのアーキテクチャそのものを学ぶことに等しい。アベンドを恐れるな。ダンプは、そのプログラムが「何をしようとしていたか」を雄弁に語る唯一の証人だ。
もし次回のバッチで S0C4 に遭遇したら、まずは `LIST(引数)` でそのアドレスが本当に正しいメモリを指しているか、冷静に確認することから始めてみてくれ。健闘を祈る。
