導入
メインフレーム開発の現場において、複数のソースコード（コンパイル単位）間で共通の変数を扱う際、`EXTERNAL`属性を利用することは一般的です。しかし、複数の場所で`INITIAL`値が定義されている場合、どの値が最終的な初期値として採用されるかは「リンカ（Binder）が読み込む順序」に依存します。この挙動を理解していないと、意図しない初期値でシステムが稼働し、デバッグが困難な不具合を引き起こす原因となります。本記事では、この「順序依存」の課題を解消し、堅牢なデータ定義を行うための実務的なアプローチを解説します。
基礎知識
`EXTERNAL`変数は、プログラムの外部、つまり別のコンパイル単位から参照可能なデータ領域を指します。PL/I等の言語において、`DECLARE X EXTERNAL INITIAL(0);` と記述した場合、リンカはロードモジュールを作成する際、最初に検出した`INITIAL`値を優先する性質があります。もし複数のオブジェクトモジュールに異なる初期値が定義されていた場合、リンカがどちらを先に読み込むかによって、変数の初期状態が決定されます。これは「静的データの確定」がコンパイル時ではなく、リンク編集時に行われるためです。
実装/解決策
順序依存を回避するための最も確実な方法は、「初期化用モジュール（またはヘッダー的役割のモジュール）を単一化する」ことです。
1. 初期値を持つ変数の定義は、専用のソースファイル（例: `INIT_DATA.PLI`）に集約する。
2. 他のプログラムからは、`INITIAL`属性を除いた`EXTERNAL`定義のみを記述し、値を参照する。
3. リンカ（Binder）の制御文である`INCLUDE`順序を厳格に管理する。
これにより、特定のモジュールのみが初期値を保持するようになり、意図しない値の上書きを防ぐことができます。
サンプルプログラム
以下は、初期化を管理するモジュールと、それを参照するモジュールの構成例です。
[INIT_DATA.PLI：初期化専用モジュール]
/ このモジュールで変数の初期値を一元管理する /
/ リンク時に必ず最初に読み込ませる /
MY_CONFIG_VAR: PROCEDURE;
DCL G_SYSTEM_ID FIXED BIN(31) EXTERNAL INITIAL(999);
END MY_CONFIG_VAR;
[MAIN_PROG.PLI：参照側モジュール]
/ INITIAL属性は書かず、EXTERNAL属性のみを定義 /
MAIN_PROG: PROCEDURE OPTIONS(MAIN);
DCL G_SYSTEM_ID FIXED BIN(31) EXTERNAL;
/ 初期値999が正しく保持されているか確認 /
PUT SKIP LIST(‘SYSTEM ID IS: ‘ || G_SYSTEM_ID);
END MAIN_PROG;
応用・注意点
現代のオブジェクト指向言語（JavaのSpringコンテキスト等）へ移行する際、この「リンカ依存の初期化」は最大の懸念点となります。なぜなら、現代言語では静的イニシャライザの実行順序が厳密に管理される必要があるからです。
現場での注意点として、「古いソースコードの修正時に、安易に別のソースへEXTERNAL変数のINITIAL定義をコピーしない」ことを徹底してください。また、Binderのログを確認し、同じ外部シンボルに対して複数の初期値が割り当てられていないか、警告メッセージを見逃さないようにしましょう。大規模なシステムでは、初期化順序をプログラムのロジックに依存させず、システム起動時に設定ファイルを読み込む構成へ徐々にシフトすることが、長期的なメンテナンス性の向上につながります。
コメント