PL/Iの「INTERNAL」を制する者は、レガシーの迷宮を制す
汎用機の世界で長年戦ってきた諸君なら、一度は目にしたことがあるはずだ。「なぜ、この変数が予期せず書き換わっているのか？」という、夜中のバッチ処理を血の気引く思いで見つめるあの瞬間を。
PL/Iは、その柔軟すぎる構文ゆえに、現代の言語にはない特有の「落とし穴」を内包している。今回は、PL/Iプログラムの構造を決定づける`INTERNAL`属性のスコープ、そしてそれがマイグレーションやデバッグ時にどれほど厄介な牙を剥くかについて、現場の視点から深掘りしていこう。
—
1. INTERNAL属性とスコープの境界線
PL/Iにおいて、明示的に`EXTERNAL`を宣言しない限り、変数はデフォルトで`INTERNAL`として扱われる。これは、そのブロック（PROCEDUREやBEGINブロック）内でのみ有効であることを意味する。
しかし、ここが落とし穴だ。`INTERNAL`であっても、入れ子構造（ネスト）になったPROCEDUREでは、外側の変数が内側に「透過」して見える。
/i
MAIN_PROC: PROCEDURE OPTIONS(MAIN);
DCL WORK_AREA CHAR(10) INIT(‘INITIAL’);
CALL SUB_PROC;
SUB_PROC: PROCEDURE;
/ ここでは外側のWORK_AREAが見えているため、誤って書き換える可能性がある /
WORK_AREA = ‘MODIFIED’;
PUT SKIP LIST(WORK_AREA);
END SUB_PROC;
END MAIN_PROC;
現代のJavaやC#のスコープ管理に慣れた若手エンジニアから見れば、この「自動的に親のスコープが汚染される」挙動は恐怖だろう。大規模な基幹システム改修時、変数名の衝突を避けるために適当な名前を付けていると、この透過性が災いして思わぬ副作用を引き起こす。
2. ポインタと動的メモリ操作の闇
マイグレーション案件で最も頭を抱えるのが、`BASED`変数とポインタ（`PTR`）の組み合わせだ。`INTERNAL`なスコープで定義されたポインタが、不適切に外部スコープのメモリ領域を指し示すよう設計されたコードは、まさに時限爆弾だ。
特に、`CICS`環境下での動的領域確保（`GETMAIN`相当）を行う際、ポインタの生存期間（Extent）と変数のスコープが噛み合っていないと、解放済みの領域を指し続ける「ダングリングポインタ」が生成される。
現場の教訓：
ダンプ解析で`S0C4`（保護例外）に遭遇した時、単なるポインタの不正アクセスと断定してはならない。コンパイラオプションの`STG`（ストレージ検証）を付与して再コンパイルし、メモリの破壊パターンを追うのだ。特に、`PACKED-DECIMAL`の符号領域が演算過程で破壊されている場合、それはポインタが意図しない領域（隣接する変数など）を指している明白な証拠だ。
3. マイグレーション時に死なないための設計指針
JavaやC#への移行を検討する際、PL/Iのこの「曖昧なスコープ」をそのままオブジェクト指向に置き換えるのは自殺行為だ。以下の観点を設計に盛り込むべきである。
- 名前空間の完全分離:
`INTERNAL`による隠蔽ではなく、クラスや名前空間による物理的な分離を行うこと。移行ツール任せにすると、PL/Iのスコープ規則を無理やりクラスメンバとして変換し、巨大な「God Class」が誕生する。これが一番の失敗パターンだ。
- パックデシマル（FIXED DECIMAL）の罠:
PL/Iの`PIC ‘S9(7)V99’ COMP-3`を`BigDecimal`等へ置換する際、符号の内部表現の違い（x’F’とx’C’の扱いなど）で計算結果が食い違う。特にDB2の埋め込みSQLでNULL値が混入している場合、PL/I側で`INDICATOR`変数を使って拾っていたロジックを、Java側で正しくハンドリングできているか、徹底的に検証せよ。
- コンパイラ最適化の副作用:
`OPTIMIZE(3)`を適用した途端に動かなくなるコードは、決まって変数の初期化忘れか、レジスタの値を過信した最適化によるものだ。移行先の言語で`volatile`的な挙動をどうエミュレートするか、あるいは構造自体のリファクタリングを行うか、判断は早い段階で下すべきだ。
最後に：アーキテクトとしての矜持
PL/Iは、機械語に近い制御と、高級言語の抽象化を両立させようとした野心的な言語だ。その「古さ」を単なる負債と切り捨てるのは簡単だ。しかし、この言語が積み上げてきた数十年の安定稼働という実績は、単なるコードの集積ではない。
我々アーキテクトの仕事は、その「暗黙の仕様」を現代の言語の「明示的な設計」へと昇華させることにある。`INTERNAL`という小さな属性一つをとっても、そこにはメインフレームが守り抜いてきた「厳格な境界」の思想が流れている。
コードを読み解く時、コンパイラが何を考え、メモリ上でどのようなドラマが起きているのか。その想像力を欠かさない限り、我々はどんなに複雑なレガシーシステムをも、安全かつ確実に次世代へと導くことができるはずだ。
次は、`CICS`における`EXEC CICS LINK`と共有ストレージの危うい関係について語るとしよう。現場からは以上だ。
