PL/Iの「予約語なし」という美学と、それが現場で引き起こす罠
やあ。今日も今日とて、レガシーシステムのジャングルで格闘しているか？
PL/Iを初めて触ったエンジニアが、まず最初に面食らうのが「予約語が存在しない」という事実だ。現代の言語、例えばJavaやPythonなら、`if`や`while`といったキーワードを定数名や変数名に使うことは御法度だ。しかし、PL/Iの世界では、`IF`という名前の変数を宣言することすら、仕様上は許されている。
「そんな無法地帯で、コンパイラはどうやってコードを解釈しているんだ？」
今日は、このPL/I特有の設計思想と、実務で絶対にやってはいけない「やってはいけないコーディング」について、現場の知見を交えて語ろうと思う。
—
なぜPL/Iには予約語がないのか
PL/Iの設計思想は「汎用性（Programming Language One）」に集約される。科学技術計算から事務処理、さらにはシステム記述までを一本でこなすため、言語設計者は「プログラマーの思考を制限したくない」と考えたのだろう。
この柔軟性を実現しているのが、「文脈による解釈」だ。コンパイラは、そのトークンが文のどの位置にあるか、あるいは前後に何があるかを見て、それがキーワードなのか識別子なのかを推論する。
しかし、この「親切な設計」が、時として我々を地獄に突き落とすことになる。
現場で遭遇する「悪魔のコード」例
例えば、こんなコードを見たらどう思う？
1
/ 悪い例：キーワードを変数名にしてしまう悲劇 /
IF: PROC OPTIONS(MAIN);
DCL IF CHAR(10) INIT(‘TRUE’);
DCL THEN CHAR(10) INIT(‘FALSE’);
/ 以下の文は、コンパイラにはどう見えるか？ /
IF IF = ‘TRUE’ THEN THEN = ‘TRUE’;
PUT SKIP LIST(IF, THEN);
END IF;
一見すると壊れた文字列に見えるが、コンパイラはこれを正確にコンパイルする。`IF`がキーワードなのか変数なのか、文脈を解析して処理を進めるからだ。だが、こんなコードをメンテナンスする後輩の身にもなってほしい。可読性はゼロ、デバッグ時は迷宮入り確定だ。
—
実務におけるリスク管理：VSAM処理とONユニット
特に大規模バッチで多用されるVSAMアクセスや、異常系制御のONユニットでは、この仕様が仇となりやすい。
以下のコードを見てくれ。VSAMの読み込み処理で、よくある失敗パターンだ。
1
//
/ VSAMレコード読み込みとONユニットによる制御 /
//
READ_PROCESS: PROC;
/ VSAMアクセス用のファイル宣言 /
DCL KSDS_FILE FILE RECORD INPUT ENV(VSAM);
/ エラー処理の定義：ONユニット内で予約語っぽく見える変数は厳禁 /
ON ENDFILE(KSDS_FILE) BEGIN;
DCL EOF_FLAG BIN FIXED(15) INIT(1);
/ 現場の鉄則：ONユニット内では変数の衝突を避けること /
SIGNAL CONDITION(END_OF_DATA);
END;
/ READ文での活用：BUILTIN関数は安全だが、変数名には注意 /
READ FILE(KSDS_FILE) INTO(REC_BUFFER);
END READ_PROCESS;
もし、ここで`END`や`FILE`といった名前を変数に使っていたらどうなるか。コンパイラは「たぶんこの`FILE`は変数だろう」と気を利かせてくれるかもしれないが、保守担当者が「あ、この`FILE`は予約語だな」と誤認し、修正を躊躇する。これが、長年動いているバッチプログラムに隠された「地雷」の正体だ。
—
エンジニアへのアドバイス：どう立ち回るべきか
PL/Iの現場では、「仕様上許されていても、やってはいけない」という暗黙のコーディング規約こそが最大の武器になる。
1. キーワードを識別子に使わない:
`IF`, `THEN`, `ELSE`, `DO`, `END`, `FILE`, `KEY`などは、たとえコンパイルが通っても絶対に使用禁止にすること。
2. BUILTIN関数の活用:
`SUBSTR`や`INDEX`などの組み込み関数は強力だ。しかし、これらと同名の変数を作ることも可能だ。関数を使いたいのか、変数を使いたいのか、ソース上で明確に区別できるように名前を工夫する（例：`IDX_VAL`など）。
3. 大文字・小文字の使い分け:
最近のEnterprise PL/I環境では小文字も扱えるが、メインフレームのレガシー保守では大文字記述が正義だ。コード全体で視認性を統一せよ。
結び
PL/Iの「予約語がない」という仕様は、言語としての懐の深さを示している。しかし、その自由を使いこなせるのは、言語仕様の裏側にあるコンパイラの挙動を理解した熟練者だけだ。
「コンパイラが通るからいいや」ではなく、「後で誰が見ても一瞬で理解できるか」という視点。これこそが、何百万行というコードを支えるメインフレーム・エンジニアの矜持というものだ。
さて、そろそろジョブの投入時間だ。また現場で会おう。健闘を祈る。
