PL/Iの「自由」という名の劇薬：INTERNAL属性が守る基幹システムの聖域
メインフレームの現場でPL/Iのコードを眺めていると、現代のJavaやC#の厳格なスコープ管理が、いかに「後から付け加えられた規律」であるかを痛感させられます。PL/Iには予約語が存在しません。`IF`という名前の変数を作ることさえ可能です。この言語が持つ「何でも書ける」という自由は、数十年稼働し続ける基幹システムにおいて、時として悪夢のようなデバッグの引き金となります。
今日は、その混沌を制御するための防波堤、`INTERNAL`属性と、それが織りなすスコープの機微について、現場の知見を交えて深掘りします。
—
1. 予約語なき世界の「名前の衝突」という呪縛
PL/Iの設計思想において、識別子はあくまで「名前」であり、言語仕様そのものに縛られません。これは柔軟性をもたらす反面、大規模なシステム改修において、意図しないグローバル変数の参照という「地雷」を埋め込む原因になります。
特に、何世代ものプログラマが手を加えた巨大なロードモジュールでは、外部変数（`EXTERNAL`）とローカル変数の境界が曖昧になりがちです。ここで重要なのが、明示的な`INTERNAL`属性によるスコープの限定です。
/i
/ 意図せぬグローバル参照を防ぐためのINTERNAL制御 /
PROC_CALC: PROCEDURE;
/ DCL時にINTERNALを明示することで、このプロシージャ外からのアクセスを遮断 /
DCL WORK_AREA CHAR(1024) INTERNAL;
/
- 現代の移行プロジェクトにおいて、この宣言を怠ると、
- リンクエディット時に予期せぬモジュールとの名前解決が行われ、
- 不可解なABEND（S0C4やS0C7）を引き起こす原因となる。
/
END PROC_CALC;
2. 動的メモリ操作とポインタの「生存期間」
`INTERNAL`属性は、単なる可視性の制御に留まりません。基幹バッチで頻出する`BASED`変数を用いた動的メモリ操作において、`INTERNAL`と`AUTOMATIC`の挙動を混同すると、致命的なメモリリークや不正参照を招きます。
特に、CICS環境下でのポインタ操作は、`GETMAIN`した領域をどのように管理するかがシステムの信頼性を左右します。
/i
DCL PTR_DATA PTR;
DCL BASED_AREA CHAR(100) BASED(PTR_DATA);
/
- アーキテクトの視点：
- CICS環境では、ポインタの生存期間（Extent）を意識しなければならない。
- INTERNAL属性を持つポインタ変数は、スタックに配置されるが、
- 指し示す先（BASED領域）はヒープである。この断絶を理解せよ。
/
ALLOCATE BASED_AREA;
/ 処理ロジック /
FREE BASED_AREA;
3. 現場で唸る：パックデシマルの「罠」とダンプ解析
移行現場で最も頭を抱えるのが、Java等へコードを移した際に発生する「パックデシマル（`FIXED DEC`）の符号反転」問題です。PL/Iの内部表現はIBMのハードウェアに直結しています。例えば、`INTERNAL`な変数として定義したつもりが、リンクの過程で共有メモリ領域に配置されてしまい、他モジュールから不正なパック値が書き込まれるケースがあります。
もし、ダンプで`S0C7`（データ例外）に遭遇したら、まずはその変数が本当に「意図したスコープ内」で完結しているか、MAPリストを確認してください。コンパイラ最適化（`OPTIMIZE(2)`など）が効いている場合、変数の生存範囲がレジスタレベルで最適化され、ダンプ上で値が見えなくなることがありますが、それは最適化の結果であり、バグではありません。
4. マイグレーションにおける設計指針
JavaやC#への移行を進める際、PL/Iのこの「緩い」スコープ仕様をどうマッピングすべきか。
- カプセル化の徹底: PL/Iの`INTERNAL`に近い概念は、Javaであれば`private`フィールドです。移行時は、全ての変数のアクセス修飾子をデフォルト（パッケージプライベート）ではなく、明示的に`private`に設定することを強く推奨します。
- 名前空間の衝突回避: 予約語を持たないPL/Iの性質を考慮し、移行先のクラス構造では必ずネームスペースやパッケージによる分離を徹底してください。
- CICSエッジケース: オンライン処理において、`SHARED`なデータ領域を扱う場合、PL/Iのスコープ規則をそのまま高級言語に持ち込むのは危険です。スレッドセーフな設計、つまり「共有状態を持たない」設計へのリファクタリングが、長期的には最も安価なコストとなります。
結びに代えて
PL/Iは、システムを「ハードウェアの延長」として制御できる、極めて強力な言語です。`INTERNAL`属性を使いこなすことは、単にコンパイルを通すことではなく、自身のコードがメモリ上でどのように配置され、いつ消滅するのかという「計算機の呼吸」を理解することと同義です。
レガシー移行は、単なるコード変換ではありません。先人が残した「自由という名の複雑性」を解きほぐし、現代の堅牢なアーキテクチャへと昇華させる作業です。皆さんのプロジェクトが、論理的で美しい設計へと着地することを、同じメインフレームの現場から応援しています。
—
本稿に関する技術的な質問や、特定のABEND解析における相談があれば、コメント欄でお待ちしています。泥臭いダンプ解析の話こそ、アーキテクトの腕の見せ所ですから。
