【入門編】INTERNAL属性のスコープ制限 – PL/Iの基本構文とデータ制御実践ガイド

こんにちは！長年、巨大な汎用機の心臓部を見守り続けてきたシステムアーキテクトです。

Javaでオブジェクト指向に親しんだ方や、COBOLでガチガチのデータ定義を書いてきた方にとって、PL/Iという言語は少し「古風で気難しい隣人」のように見えるかもしれません。でも安心してください。PL/Iは実は、現代の言語の先駆けとなった、非常に合理的で懐の深い言語なんです。

今日は、そんなPL/Iの入門編として、「特定の場所でしか通用しない秘密の変数」を作るためのINTERNAL属性について、現場の知見を交えてお話ししますね。

—

まず、PL/Iのプログラムは「大きな箱の中に小さな箱が入っている」構造をしています。

Javaならクラスやメソッド、COBOLならDIVISIONやSECTIONに近いですが、PL/Iはこれを「どこまででも入れ子（ネスト）にできる」という特徴があります。この「入れ子」の関係性の中で、変数がどこまで見えるか（スコープ）を制御するのが、今回のお題である`INTERNAL`属性です。

—

PL/Iでは、変数はデフォルトで`INTERNAL`（内部的）です。これはどういう意味かというと、「その変数を定義したブロック（PROCEDURE）の外からは見えない」ということです。

例えば、家の中に「自分専用の書斎」があるとします。リビング（外部）にいる人には、書斎の中で何をしているのか（どんな変数があるのか）は見えませんよね。

大規模な基幹システムでは、数千行にも及ぶプログラムをチームで改修します。もし、すべての変数がどこからでも見える「グローバル変数」だったらどうでしょう？誰かがうっかり同じ名前の変数を使ってしまい、原因不明のバグが多発する……なんて悲劇が待っています。

`INTERNAL`属性は、「この変数はこの処理の中だけで使います！」と宣言することで、名前の衝突（ネーミングコンフリクト）を物理的に防ぐための防波堤なのです。

—

では、実際にどう書くのか見てみましょう。

/i
/ メインのプログラムの開始 /
TEST_PROG: PROCEDURE OPTIONS(MAIN);

/ ここで宣言した変数は、このメインブロック内でのみ有効 /
DCL WORK_DATE CHAR(8) INTERNAL;

/ サブルーチンを呼び出す /
CALL SUB_PROCESS;

SUB_PROCESS: PROCEDURE;
/ もしここで WORK_DATE を宣言し直すと、別の変数として扱われる /
/ これがINTERNALの力。外の変数を汚さない /
DCL WORK_DATE CHAR(8) INTERNAL;

WORK_DATE = ‘20231027’; / これは内側のWORK_DATEを指す /
END SUB_PROCESS;

END TEST_PROG;

見ての通り、`SUB_PROCESS`の中で`WORK_DATE`を宣言しても、外側の`WORK_DATE`は書き換わりません。Javaで言えばメソッド内のローカル変数と同じ感覚ですが、PL/Iではこのルールが「入れ子になったブロックごと」に適用されるのが非常に強力なんです。

—

初心者の頃、よくあるトラブルが「変数の宣言漏れ」です。PL/Iは非常に親切（あるいは余計なお世話？）で、宣言していない変数に出会うと、コンパイラが勝手にその場で宣言してしまいます（これを「暗黙宣言」と言います）。

しかし、大規模改修の現場では、これはバグの温床になります。

アドバイス: 必ずプログラムの冒頭に `DEFAULT(RANGE() INTERNAL)` と記述する癖をつけましょう。これにより、予期せぬ変数の誤用をコンパイラが厳しくチェックしてくれるようになります。

—

PL/Iの`INTERNAL`属性は、プログラムという大きな地図の中に「立ち入り禁止区域」や「専用エリア」を設けるための魔法の境界線です。

「名前が被らないようにしなきゃ……」と悩む必要はありません。ブロックごとに`INTERNAL`を使ってスコープを閉じ込めてしまえば、あなたの書くコードは驚くほど堅牢で、保守しやすいものに変わります。

最初は独特のキーワードに戸惑うかもしれませんが、一つ一つ紐解けば、PL/Iほど論理的で美しい言語はなかなかありません。もし現場で奇妙な宣言に出会ったら、「これは誰の、どの範囲のための変数かな？」と、その変数の「居場所」を想像してみてください。

皆さんのメインフレーム・ライフが、少しでも楽しいものになりますように！また次のステップでお会いしましょう。