メインフレームの深淵へ：PL/Iにおける「引数省略（OMITTED）」とNULLポインタの防衛術
やあ、今日もバッチの夜間ジョブ監視と格闘しているエンジニア諸君。
IBMメインフレームのプロジェクトで、レガシーコードの解析をしていると必ず出くわすのが「引数の省略」というテクニックだ。特に大規模バッチでは、汎用的なサブルーチンに複数の引数を定義し、呼び出し側が必要に応じて一部を省略する設計がよく見られる。
しかし、この「省略」を甘く見ると、本番環境で突然のS0C4（メモリ保護例外）や、意図しないデータの書き換えという地獄を見ることになる。今日は、PL/Iにおける`OMITTED`の判定と、実務で絶対に守るべき安全なコーディング作法について、ベテランの視点から紐解いていこう。
—
1. なぜ「OMITTED」を意識しなければならないのか
PL/Iのプロシージャ呼び出しにおいて、引数を省略すると、コンパイラは呼び出し側のスタックに「ダミーのアドレス（通常は NULL または特定的パターン）」を積む。受け取り側のプロシージャで、定義されたはずの引数を無防備に参照すると、システムは「存在しないアドレス」へアクセスしようとして異常終了する。
我々のようなシステムアーキテクトが最も恐れるのは、「テスト環境ではたまたまメモリがクリアされていて動いたが、本番の複雑なメモリ配置では落ちる」という最悪のバグだ。これを防ぐには、受け取り側のプロシージャで、引数が本当に渡されているかを`ADDR`関数と`NULL`（あるいは`SYSNULL`）を用いて厳格にチェックする必要がある。
—
2. 実践的コーディング：OMITTED判定の黄金律
以下に、VSAMファイルのレコード処理を想定した、堅牢なプロシージャのひな形を示す。
/i
/ — サブルーチン: レコード更新プロシージャ — /
UPDATE_RECORD: PROCEDURE(REC_DATA, OPT_FLAG) OPTIONS(REENTRANT);
DCL REC_DATA CHAR() BASED(P_REC); / 可変長レコード /
DCL OPT_FLAG CHAR(1) BASED(P_FLAG); / 省略可能なフラグ /
DCL (P_REC, P_FLAG) PTR; / ポインタ変数 /
DCL SYSNULL BUILTIN; / NULL判定用 /
DCL ADDR BUILTIN; / アドレス取得用 /
/ 引数のアドレスを確定させる /
P_REC = ADDR(REC_DATA);
P_FLAG = ADDR(OPT_FLAG);
/ 1. 必須引数のチェック (もしREC_DATAが省略されたら即エラー) /
IF P_REC = SYSNULL() THEN DO;
PUT SKIP LIST(‘CRITICAL ERROR: REC_DATA IS OMITTED’);
SIGNAL ERROR;
END;
/ 2. 省略可能な引数の安全な判定 /
IF P_FLAG = SYSNULL() THEN DO;
/ フラグが省略された場合のデフォルト処理 /
PUT SKIP LIST(‘OPT_FLAG IS OMITTED, USE DEFAULT MODE’);
END;
ELSE DO;
/ 値が存在する場合のみ参照する /
IF P_FLAG->OPT_FLAG = ‘Y’ THEN CALL DO_SPECIAL_LOGIC;
END;
/ 以下、VSAMへのアクセス処理などが続く /
/ … /
END UPDATE_RECORD;
ポイント解説
- `ADDR`関数の活用: 引数に渡されたものが実体か、あるいは省略されたダミーポインタかを確認するには、`ADDR`関数で受け取ったアドレスを`SYSNULL()`と比較するのが最も確実だ。
- `BASED`変数の活用: `BASED`で定義することで、ポインタ経由でのアクセスが明確になり、メモリ安全性が向上する。
- ONユニットとの併用: 大規模システムであれば、ここで`SIGNAL ERROR`を投げるのではなく、事前に定義した`ON CONDITION`や`ON ERROR`ユニットで例外を捕捉し、ダンプを出力した後に適切に後処理（VSAMのクローズ等）を行うのが定石だ。
—
3. 現場のトラブルシューティング：ここがハマりどころだ
後輩がよくやる失敗として、「引数を渡しているつもりが、呼び出し側で属性が不一致（例えば`FIXED BIN(15)`と`FIXED BIN(31)`の不整合など）」があり、結果として`ADDR`が正しいアドレスを指さないというケースがある。
もし、デバッグ中に「値が化ける」「アドレスが変だ」と感じたら、以下の順序で確認してほしい。
1. CALL側の宣言とPROCEDURE側の仮引数宣言を並べて比較する: 属性（`CHAR`, `FIXED`, `PIC`など）が完全に一致しているか。
2. コンパイルリストの`STORAGE MAP`を確認する: アライメントがずれていないか。特に`ALIGNED`と`UNALIGNED`の混在は、メインフレーム移行時のトラブルの温床だ。
3. ONユニットで捕捉: 異常終了する前に、`ON ERROR`で`PUT DATA`を行い、その時の引数ポインタの値をダンプ出力するコードを一時的に埋め込む。
—
最後に：堅牢なコードを遺すために
我々が書くコードは、数十年後のエンジニアが保守することになる可能性がある。
「動けばいい」というコードは、数年後に必ず自分たちに跳ね返ってくる。特に今回紹介したような引数の制御は、システムの「境界」を定義する重要な部分だ。
`OMITTED`を単なる「省略できる便利な機能」と捉えず、「呼び出し元と呼び出し先の契約（コントラクト）」であると意識してほしい。引数が渡されない可能性があるなら、その不在を明示的に、そして安全に処理する。その一手間が、深夜の呼び出しから君を救うことになるはずだ。
次は「ONユニットを使った動的なエラーハンドリングと、VSAMファイル処理中のリカバリ戦略」について深掘りしよう。質問があれば、いつでも現場の廊下で捕まえてくれ。健闘を祈る。
