【PL/I深層解説】INTERNAL属性で「名前の衝突」を根絶せよ：大規模保守の現場から
メインフレームの現場で何十年と稼働しているレガシーコードの改修、胃が痛くなる作業だよな。特に厄介なのが「変数名がどこで定義されているか分からない」という迷宮だ。
PL/Iには、他の言語に見られるような「厳格な予約語」がほとんど存在しない。これが自由度を生む一方で、意図しない名前の衝突を引き起こし、バグの温床になる。今日は、大規模バッチ改修の現場で「事故」を起こさないための、`INTERNAL`属性によるスコープ管理の鉄則を叩き込む。
—
なぜPL/Iには「予約語」がないのか
PL/Iを触り始めたばかりの若手エンジニアが一番驚くのが、「IFやTHEN、あるいはGETすら変数名として使えてしまう」という仕様だ。これはPL/Iが「コンテキスト依存」の言語だからだ。
例えば、`IF = 10;` と書けばコンパイラは「IFという名前の変数に10を代入する」と解釈する。強力だが、一歩間違えれば可読性は地獄と化す。だからこそ、「どの範囲までその変数が有効か」をプログラマ自身が制御するという意識が、メインフレームエンジニアには不可欠なんだ。
—
INTERNAL属性による「スコープの壁」構築
`INTERNAL`属性は、変数の有効範囲をそのプロシージャ（またはBEGINブロック）内に限定する。デフォルトでも内部スコープになることが多いが、明示的に記述することで「ここは外部から隠蔽されている」という意思表示をコードに残せる。これが保守フェーズでの安全性に直結する。
次のコード例を見てくれ。VSAMファイルを読み込み、計算処理を行うバッチの骨子だ。
1
/ ———————————————————– /
/ 計算プロシージャ：名前の衝突を避けるためのスコープ設計 /
/ ———————————————————– /
CALC_PROC: PROCEDURE(IN_DATA) INTERNAL;
DCL IN_DATA CHAR(10);
/ 内部変数：外部の同名変数と衝突しても、ここではこれを使う /
DCL WORK_AMT FIXED BIN(31) INTERNAL;
DCL ERR_CODE FIXED BIN(15) INTERNAL INIT(0);
/ 内部でのみ有効なデータ変換処理 /
WORK_AMT = BINARY(SUBSTR(IN_DATA, 1, 5), 31);
/ ONユニット：例外発生時のスコープ制御 /
ON CONVERSION BEGIN;
ERR_CODE = 99;
PUT SKIP LIST(‘データ変換エラーが発生しました’);
END;
IF WORK_AMT > 10000 THEN DO;
/ 処理ロジック /
END;
RETURN;
END CALC_PROC;
実務で「INTERNAL」を使いこなすコツ
1. 共通変数の肥大化を防ぐ:
メインのプログラム（MAIN PROC）に何でもかんでもDCLするのは悪手だ。グローバル変数が多すぎると、どのONユニットが値を書き換えたのか追跡不能になる。計算ロジックやファイルアクセスなど、機能単位で`PROCEDURE … INTERNAL`を切り出し、変数をその中に閉じ込めろ。
2. BUILTIN関数との衝突回避:
`DATE`や`TIME`といった組み込み関数名を不用意に変数名に使うのは避けろ。もし使わざるを得ない場合でも、`INTERNAL`でスコープを限定しておけば、そのブロックの外側で組み込み関数が正しく機能することを保証できる。
3. VSAMアクセスとスコープ:
VSAMファイルを読み込む際、レコードバッファを広域で定義しがちだが、これも危険だ。レコードレイアウトの構造体こそ、`INTERNAL`属性を持たせたBEGINブロック内に局所化すべきだ。そうすることで、複数のファイルアクセスが混在する巨大なバッチプログラムでも、変数の「生存期間」を明確に制御できる。
—
デバッグ時の「鉄の掟」
現場でバグに遭遇したとき、「変数の値がいつの間にか変わっている」という現象に突き当たったら、まずその変数がどのスコープで定義されているかを確認しろ。
- 同一名称の変数が入れ子構造になっていないか？
- EXTERNAL属性が付与された共有変数を使っていないか？
PL/Iのコンパイラは優秀だが、人間が書いた「曖昧なスコープ」までは修正してくれない。だからこそ、我々エンジニアが`INTERNAL`を適切に配置し、プログラムに「境界線」を引く必要があるんだ。
最後に
「動けばいい」というコードは、1年後の自分を苦しめることになる。PL/Iの自由度を逆手に取り、`INTERNAL`による厳密なスコープ制御を行うこと。それが、数百万ステップの大規模資産を安全に継承するための、我々システムアーキテクトの矜持だ。
また何か壁にぶつかったら相談してくれ。バッチのログを読み解くのも、コンパイラリストを睨むのも、結局は現場の経験がモノを言うからな。引き続き、堅牢なコードを書いていこう。
