予約語なき世界の罠：INITIAL属性の挙動とコンパイラ最適化の深層
メインフレームの現場で長年PL/Iコードと向き合っていると、CやJavaといった他言語の常識がいかに通用しないかを思い知らされる瞬間が多々ある。その最たるものが「識別子（変数名）の命名規則と予約語を持たない」というPL/I特有の仕様だ。
1
IF IF = THEN THEN THEN = ELSE; ELSE ELSE = IF;
伝説的なこのコードが示す通り、PL/Iには厳密な意味での「予約語」が存在しない。すべては文脈（コンテキスト）によって解釈される。この柔軟性は諸刃の剣であり、変数名に `TOTAL` や `DATE` といった一般的な英語を自由に使える一方で、コンパイラの字句解析エンジンを混乱させ、予期せぬ構文エラーや難解なバグを生む温床ともなる。
今回は、この自由度の高いPL/Iにおいて、基幹システムの信頼性を根底から支える、あるいは揺るがす 「INITIAL属性による変数初期化のタイミングとコンパイラ最適化」 について、極限の深掘りを行いたい。バッチの夜間処理やCICSオンライン、さらにはJava等へのマイグレーションを控えたアーキテクト必見の知見を共有しよう。
—
1. INITIAL属性の基本動作と「2つの初期化タイミング」
PL/Iにおける `INITIAL` 属性（省略形 `INIT`）は、変数宣言時に初期値を与えるためのものだが、その実態は変数のストレージクラス（記憶クラス）によって全く異なるライフサイクルを持つ。ここを勘違いしていると、本番稼働後のデータ破損や不可解なS0C4アベンドの餌食になる。
静的ストレージ（STATIC）の場合
プログラムのロード時に一度だけ初期化が行われる。再entrancy（リエントラント）を考慮しない限り、値はプログラムの実行中ずっと保持される。
自動ストレージ（AUTOMATIC）の場合
ブロック（プロシージャやBEGINブロック）が活性化される（呼び出される）たびに、毎回初期化処理が実行される。
ここで重要なのは、`AUTOMATIC` 変数の `INITIAL` は「コンパイル時に静的に埋め込まれる定数」ではなく、実行時にコードとして展開される可能性があるという点だ。
1
DCL WK_COUNTER FIXED BIN(31) AUTOMATIC INIT(0);
このコード、一見すると安全そうに見える。しかし、この `WK_COUNTER` がループ内で毎回再生成されるようなブロック（例えばサブルーチンの内部など）にあり、かつパフォーマンスチューニングの過程でコンパイラオプションを安易にいじると、恐ろしい罠が牙をむく。
—
2. 動的メモリ操作（ALLOCATE / FREE）とINITIAL属性の挙動
基幹システムの巨大なデータ構造や可変長レコードを扱う際、ベース変数とポインタを組み合わせた動的メモリ割り当て（`ALLOCATE` 構文）は避けて通れない。ここで `INITIAL` 属性がどう絡むのか、実務的なコードで確認しよう。
1
/ ========================================================== /
/ 動的ストレージとINITIAL属性の挙動検証サンプル /
/ ========================================================== /
TEST_ALLOC: PROC OPTIONS(MAIN);
/ ベース変数の定義 /
Dcl 1 DYNAMIC_REC BASED(P_REC),
2 REC_ID CHAR(4) INIT(‘INIT’),
2 REC_DATA FIXED BIN(31) INIT(9999);
Dcl P_REC PTR;
/ 明示的なALLOCATEによる初期化 /
ALLOCATE DYNAMIC_REC;
/ この時点で REC_ID は ‘INIT’、REC_DATA は 9999 に初期化されている /
DISPLAY(‘ALLOCATE直後 REC_ID: ‘ || REC_ID);
/ 値を変更 /
REC_ID = ‘DATA’;
REC_DATA = 12345;
/ 解放 /
FREE DYNAMIC_REC;
/ 再度ALLOCATEする場合の罠 /
ALLOCATE DYNAMIC_REC;
/ 【重要】ALLOCATEのたびにINITIAL属性は再評価・適用されるか？ /
/ 答え：初期値が再設定される（デフォルトのEnterprise PL/I挙動） /
DISPLAY(‘再ALLOCATE後 REC_ID: ‘ || REC_ID);
FREE DYNAMIC_REC;
END TEST_ALLOC;
アーキテクトの視点：ALLOCATE時のオーバーヘッド
`ALLOCATE` 文が実行されると、PL/Iランタイムはヒープ領域からメモリを切り出すだけでなく、`INITIAL` 属性で定義された値をその領域に「転記（コピー）」する処理を裏で走らせる。
高頻度で呼ばれるオンライン画面制御プログラム（CICS）や、数百万件を処理するバッチの内部ループ内で不要な `ALLOCATE`/`FREE` と複雑な `INITIAL` 構造体を乱用すると、CPU使用率の急増（いわゆるCPUバースト） を引き起こす。これがパフォーマンス劣化の隠れた主犯格である。
—
3. コンパイラ最適化（OPTIMIZE）による初期化省略の魔力
IBM Enterprise PL/Iコンパイラの最適化レベル（`OPTIMIZE(2)` や `OPTIMIZE(3)`）は非常に強力だ。しかし、この最適化が、プログラマーの「甘え」を容赦なく切り捨てる。
悲劇：未初期化変数と最適化
PL/Iでは、変数に `INITIAL` を書き忘れた場合、その値は「不定（Unpredictable）」である。運悪く前回メモリにあったゴミ値がそのまま残り、偶発的に正常終了していたバッチプログラムが存在するとしよう。
ここに `OPTIMIZE(FULL)` などを適用して再コンパイルすると、コンパイラはコードフロー解析を行い、「この変数は定義直後に参照されていない、あるいは上書きされている」と判断し、初期化コードそのものをインライン展開からごっそり削除（あるいはレジスタ上で最適化）してしまうことがある。
結果として何が起きるか？
本番移行テストの環境やLPARが変わった瞬間にメモリの初期状態が変わり、夜間バッチが突然の S0C4アベンド（Protection Exception） または S0C7アベンド（Data Exception） で沈没する。
「開発環境では動いたのに本番で落ちる」というレガシー特有の悪夢の多くは、こうしたコンパイラ最適化と不完全な初期化の組み合わせによって引き起こされる。
—
4. エッジケース：パックデシマル（FIXED DECIMAL）の内部符号反転バグ
基幹システムのデータ連携において最も恐ろしいのが、DB2の埋め込みSQLやCICSの通信エリア（COMMAREA）を介したデータ授受における、パックデシマル（`FIXED DEC`）の扱いだ。
`INITIAL` 属性で数値を与えたつもりが、ストレージ上ではゾーン10進数やバイナリとして解釈され、パックデシマル領域に不正なゾーンビット（例：`X’00’` や `X’FF’` など）が混入することがある。
1
DCL DB2_AMT FIXED DEC(15,2) INIT(0);
この一見無害に見えるコードも、データベースから取得したNULL値や、不適切な再定義（`DEFINED` 属性や `UNALIGNED` の不一致）と組み合わさると、内部符号（ゾーニングニブル）が破壊され、計算時に S0C7（データ例外） を引き起こす。
特に `INITIAL` を過信して「宣言時にゼロクリアされているはずだ」と思い込み、DB2からのフェッチ直後にアンパックせず演算に持ち込むと、マイグレーション時の文字コード変換（EBCDICからASCII/UTF-8へ）の過程で符号が反転・喪失し、金額データが桁違いに化けるという致命的な事故に直結する。
—
5. マイグレーション（Java/C#等への移行）における設計指針
レガシーマイグレーションの現場では、PL/Iのこうした暗黙的な初期化挙動やストレージ構造を、オブジェクト指向言語（JavaやC#）のコンテキストに正しく翻訳しなければならない。
1. INITIALの明示化とコンストラクタの同期
PL/Iの `INITIAL` 属性を持つ構造体は、移行先のJavaクラスでは「デフォルトコンストラクタでのフィールド初期化」に完全に一致させる必要がある。特に `AUTOMATIC` 変数がブロック突入時に毎回初期化される挙動は、Javaのメソッド内ローカル変数のスコープと初期化ルール（Javaでは未初期化変数の使用はコンパイルエラーになる）を利用して、より厳格にコード側で担保する。
2. 最適化依存の排除
「コンパイラがよしなにやってくれるだろう」という甘えを捨て、変数の宣言と同時に必ず明示的な初期化（ゼロクリア、スペース埋め）を行うコーディング規約を徹底する。マイグレーションツールによる自動変換頼みではなく、アベンドリスクのある箇所は手動でセーフガードを挿入すべきだ。
3. ストレージマップの検証
`UNALIGNED` や `BDY` 属性が絡む複雑なアライメントと `INITIAL` の関係は、Java側の `@StructClass` や `ByteBuffer` のレイアウト定義に正確にマッピングする必要がある。ここを怠ると、バイナリ互換性テストで必ず痛い目をみる。
—
結びにかえて
PL/Iの予約語なき自由な世界と、強力なコンパイラ最適化、そして `INITIAL` 属性が織りなす挙動は、メインフレームの歴史そのものであり、同時に現代のエンジニアリングから見ればスリリングな地雷原でもある。
「なぜこの初期化が必要なのか」「この変数のライフサイクルはどこまでか」——その問いを突き詰めることこそが、真のシステムアーキテクトに求められる素養である。
レガシーシステムのブラックボックスを剥ぎ取り、その背後にあるコンパイラの意図とハードウェアの挙動までを完全に手中に収めたとき、あなたのシステムは、いかなるモダン化の波が来ようとも揺るぎない、鉄壁の信頼性を手に入れることになる。
