「値渡し」でバグを封じ込める：PL/IにおけるBYVALUEの正しい矜持
現場の若手からよく「PL/Iの引数渡しって、結局デフォルト（BYADDR）でいいんじゃないですか？」と聞かれる。確かに、メインフレームの歴史的な経緯を考えれば、メモリ効率の面からポインタベースの参照渡し（BYADDR）が主流だった。だが、現代の複雑化したバッチシステムにおいて、意図せぬ副作用（サイドエフェクト）を引き起こすコーディングは、夜間バッチのデバッグを地獄に変える諸悪の根源だ。
今回は、あえて「値渡し（BYVALUE）」に焦点を当て、堅牢なプログラムを書くための知見を共有しよう。
—
なぜ今、BYVALUEなのか？
PL/Iのデフォルトは `BYADDR`（アドレス渡し）だ。呼び出し先のサブプロシージャで引数を変更すれば、呼び出し元の変数も当然書き換わる。これが意図的なら良いが、大規模なサブプログラム群で不用意に書き換えが起きると、原因特定は困難を極める。
`BYVALUE` を指定すると、引数はその名の通り「値のコピー」として渡される。呼び出し先でどんなに数値をこねくり回そうが、呼び出し元のデータは鉄壁の守りを維持できる。
BYVALUEのメリット
1. 局所性の確保: 副作用を排除し、テスト容易性を劇的に向上させる。
2. 最適化の余地: 多くのコンパイラ最適化において、レジスタ渡しが可能になり、メモリ参照のオーバーヘッドが軽減される。
3. インターフェースの明確化: 「この値は読み取り専用である」という設計者の意図をコンパイラレベルで強制できる。
—
実践：BYVALUEを用いた堅牢なコード設計
以下の例は、VSAMファイルから読み込んだデータを計算用プロシージャに渡すシーンを想定したものだ。計算の過程で元の値を壊さないための、現場の標準的な書き方を見てほしい。
/i
/ メイン処理ブロック /
MAIN_BATCH: PROCEDURE OPTIONS(MAIN);
DCL REC_VAL FIXED BIN(15) INIT(100);
DCL RESULT FIXED BIN(31);
/ 呼び出し処理 /
/ REC_VALを値渡しで渡すことで、計算後の保護を確実にする /
RESULT = CALC_ROUTINE(REC_VAL);
PUT SKIP LIST(‘元データは無傷:’, REC_VAL);
PUT SKIP LIST(‘計算結果:’, RESULT);
/ 値渡しを行うサブプロシージャ定義 /
/ BYVALUE属性を明示することで安全性を担保 /
CALC_ROUTINE: PROCEDURE(P_VAL) RETURNS(FIXED BIN(31));
DCL P_VAL FIXED BIN(15) BYVALUE;
P_VAL = P_VAL 2; / ここで値を変更しても、呼び出し元には影響しない /
RETURN(P_VAL + 50);
END CALC_ROUTINE;
END MAIN_BATCH;
—
現場で直面する「落とし穴」と制御フロー
もちろん、`BYVALUE`にも制限はある。構造体（STRUCTURE）や大きな配列を `BYVALUE` で渡そうとすれば、コンパイラから厳しい警告を受けるはずだ。スタック領域の爆発を防ぐため、`BYVALUE` は基本的にスカラー型（整数やポインタ）に限定すべきだ。
また、`ON` ユニットと組み合わせる際は注意が必要だ。
- ONユニットとの距離感: `BYVALUE` で渡された値は、呼び出し元とは切り離されたスナップショットだ。したがって、計算中に `CONVERSION` エラーが発生し `ON` ユニットで値をリカバリしようとしても、呼び出し元の変数を直接救済することはできない。
- 例外処理の原則: `BYVALUE` を使う場合は、例外発生時のリカバリを「呼び出し先」で完結させるか、エラー情報を構造体として別途 `BYADDR` で渡すのが定石だ。
—
シニアからのアドバイス：保守性を高めるために
大規模なバッチ改修を行っていると、ポインタを多用した「スパゲッティ・コード」に遭遇することがある。もし君が既存コードをモダナイズする立場にあるなら、まずは「計算ロジック」を切り出し、それらを `BYVALUE` で呼び出す設計に書き換えることから始めてほしい。
- デバッグのコツ: 値渡しにしておけば、呼び出し先の入り口で `DISPLAY` 文を置くだけで、「呼び出し元から何が渡されたか」を完全にトレースできる。参照渡しだと、途中で誰かが値を書き換えていないか、ダンプを追う羽目になる。
PL/Iの古い仕様に縛られる必要はない。言語の持つ堅牢な機能を使いこなし、後世のエンジニアが「読みやすい」と思えるコードを残すことこそが、我々アーキテクトの仕事だ。
次回のブログでは、`STORAGE` クラスを活用した動的メモリ管理と、VSAMファイルI/Oにおける `ONCODE` の高度な制御について深掘りしよう。現場からは以上だ。
