「動けばいい」では済まされない：PL/Iの引数渡し（BYADDR vs BYVALUE）でS0C4を回避する技術
メインフレームのバッチ改修現場で、最も胃が痛くなる瞬間といえば、深夜のテスト実行で突然突きつけられる「SYSTEM COMPLETION CODE 0C4（S0C4）」ではないだろうか。
「昨日まで動いていたのに、なぜ急にメモリ保護違反が起きるのか」。その原因の多くは、実はPL/Iのプロシージャ呼び出しにおける「引数の渡し方」の不整合に潜んでいる。今日は、設計書には一行しか書かれていないことが多いが、基幹システムの安定稼働を左右する`BYADDR`と`BYVALUE`の深淵について解説しよう。
—
1. 原理原則：アドレスを渡すか、実体を渡すか
PL/Iのプロシージャ呼び出しにおいて、引数をどう扱うかはシステムの効率と安全性に直結する。
- BYADDR（デフォルト）: 呼び出し先へ「変数の格納先アドレス」を渡す。ポインタ経由のアクセスだ。
- BYVALUE: 呼び出し先へ「変数の値そのもの」をコピーして渡す。
一見、`BYVALUE`の方が値の保護ができて安全に見えるが、メインフレームの歴史的な経緯もあり、PL/Iのデフォルトは`BYADDR`だ。ここを意識せずに、呼び出し側と呼び出し先で属性（特に長さや精度）を不一致のまま記述すると、コンパイラは文句を言わずにコードを生成し、実行時にS0C4という「地雷」が爆発する。
—
2. 現場で遭遇するS0C4の典型パターン
以下の例を見てほしい。呼び出し側が`FIXED BIN(31)`で渡そうとしているのに、受け取り側が`FIXED BIN(15)`と定義されていたらどうなるか。
呼び出し側（CALLER）
1
DCL PARM_VAL FIXED BIN(31) INIT(100);
/ デフォルトのBYADDRで呼び出す /
CALL SUB_PROC(PARM_VAL);
呼び出し先（CALLEE）
1
/ 意図的に型を誤ったサブプロシージャ /
SUB_PROC: PROC(ARG) OPTIONS(REENTRANT);
DCL ARG FIXED BIN(15) BYADDR; / ここで受け取り側のサイズが小さい /
/ 呼び出し先はARGを2バイトの領域として扱うため、
本来の4バイト領域を破壊したり、範囲外メモリへアクセスしてS0C4が発生する /
IF ARG > 50 THEN …
END SUB_PROC;
なぜS0C4になるのか？ それは、呼び出し側が4バイト確保している領域に対し、受け取り側がその先頭2バイトを「自分のもの」として境界チェックや演算を行うからだ。複雑なデータ構造やVSAMのレコード定義を渡す場合、この不一致はメモリ破壊の温床となる。
—
3. 実践：VSAMレコードを安全に受け渡すコーディング標準
バッチ処理で頻出する、VSAMのレコードをサブプログラムへ渡すケースを考えてみよう。ここで重要なのは`BYADDR`を明示し、かつ`DESCRIPTOR`（あるいは`BYADDR`の挙動）を理解することだ。
1
/ VSAMレコードの受け渡し例 /
PROCEDURE_MAIN: PROC OPTIONS(MAIN);
DCL 1 VSAM_REC,
5 KEY_FLD CHAR(10),
5 DATA_FLD CHAR(50);
/ VSAMからのREAD成功後にサブへ渡す /
CALL PROCESS_RECORD(VSAM_REC);
END PROCEDURE_MAIN;
/ 安全なサブプロシージャの定義 /
PROCESS_RECORD: PROC(P_REC) BYADDR;
DCL 1 P_REC,
5 KEY_FLD CHAR(10),
5 DATA_FLD CHAR(50);
/ 内部処理でONユニットを利用して例外をトラップ /
ON ERROR BEGIN;
PUT SKIP LIST(‘データ処理中に例外発生’);
SIGNAL FINISH;
END;
/ BUILTIN関数による境界チェックの例 /
IF LENGTH(TRIM(P_REC.KEY_FLD)) > 0 THEN
DO;
/ 処理ロジック /
END;
END PROCESS_RECORD;
ここがポイント
1. 明示的な属性定義: 受け渡し側の構造体定義は、必ずCOPYメンバーで共通化すること。手打ちで定義を合わせようとすると、必ずどこかでズレが生じる。
2. BYADDRの明示: `PROC(ARG) BYADDR`と明記することで、保守担当者が「これはアドレス渡しである」と一目で認識できる。これは可読性という名の防御策だ。
3. ONユニットの活用: 予期せぬデータ不整合でアベンドする前に、`ON ERROR`や`ON STORAGE`を適切に配置し、異常をハンドリングする設計が、大規模バッチの「夜間呼び出し」を減らす鍵となる。
—
最後に：ベテランからのアドバイス
「コンパイルエラーが出ないから大丈夫」という考えは、メインフレーム開発においては最も危険な甘えだ。特にPL/Iのコンパイラは非常に優秀だが、裏を返せば「プログラマが意図した通りに（たとえそれがメモリ破壊であっても）動いてしまう」言語である。
S0C4に悩まされた時は、まず「呼び出し側と受け取り側の変数の属性（長さ、精度、アライメント）が、メモリ上で本当に一致しているか」をダンプリストと突き合わせて確認してほしい。
技術は移ろいゆくが、メモリレイアウトを意識するこの作法は、どの言語を扱うことになっても必ず君の血肉となるはずだ。堅実な実装を積み重ね、今日も安定したバッチ運用を支えていこう。
