導入：なぜEXTERNALの正規化を知る必要があるのか
メインフレーム開発において、プログラム間でデータを共有する際に欠かせないのが「EXTERNAL属性」です。しかし、z/OS環境における外部変数名は、コンパイルやリンクの過程で独自の「正規化」が行われます。この仕様を理解していないと、異なる言語間での連携や、移行プロジェクトにおいて「別の変数だと思っていたものが、実は同じ実体を指していた」という深刻なバグを引き起こす可能性があります。本稿では、EXTERNAL名前空間のルールと、Java/TypeScript連携時代に必須の注意点を解説します。
基礎知識：EXTERNALの仕組みと正規化ルール
PL/I等の言語で「DCL X EXTERNAL;」と宣言した場合、リンカ（IEWBLINKなど）は、この変数をロードモジュール全体でユニークな名前として解決します。
ここで重要なのは、z/OSのレガシーなリンカ環境では、多くの場合、名前が「大文字」に変換され、かつ特殊文字が制限されるという点です。例えば、小文字の「myVar」と「MYVAR」を別個の変数として扱おうとしても、リンカの段階でどちらも「MYVAR」として同一視されてしまうのです。
実装・解決策：名前空間の衝突を避ける
この問題を回避する最も確実な方法は、「EXTERNAL名の命名規則をあらかじめ大文字かつ8文字以内（またはリンカの仕様に準拠）に統一すること」です。また、外部連携を行う際は、リンカのオプション（CASE=MIXEDなど）を確認し、環境がどの程度大文字・小文字を区別できるかを把握しておく必要があります。
サンプルプログラム：PL/Iにおける安全なEXTERNAL宣言
以下は、名前空間の衝突を防ぐために、あえて大文字で統一し、意図を明確にした宣言例です。
/
EXTERNAL変数の宣言例
外部との連携を考慮し、すべて大文字かつ命名規則に従う
/
/ 共有データ領域の定義 /
DCL 1 SHARED_DATA EXTERNAL,
2 COUNTER FIXED BIN(31), / 共有カウンター /
2 STATUS CHAR(8); / ステータスフラグ /
/
注意：
もしここで DCL my_counter EXTERNAL; と宣言してしまうと
他のモジュールの MY_COUNTER と衝突する可能性があります。
必ずプロジェクト内で一意な大文字名称を使用してください。
/
応用・注意点：モダン言語との連携時の罠
現在、メインフレームのデータをJavaやTypeScriptから参照するケースが増えています。Javaは「Case-sensitive（大文字・小文字を区別する）」な言語であるため、PL/I側で「大文字・小文字を使い分ければ別物になる」と勘違いしていると、Java側からアクセスした際に想定外の変数に書き込んでしまう事故が発生します。
現場で役立つチェックリスト：
1. EXTERNAL変数は、必ず大文字で統一されているか？
2. 連携するモダン言語（Java/TS）側での定義名と、リンカが解釈する名前は一致しているか？
3. 特殊記号（_ や $）が含まれていないか？（古い環境では変換・削除される可能性があります）
これらのルールをチーム内で共有し、設計段階で「正規化後の名前」を定義書に明記しておくことが、トラブルを未然に防ぐ唯一の道です。
コメント