【PL/I深層探求】STATIC変数の「静かなる罠」：初期化タイミングと再入可能性の鉄則
諸君、お疲れ様。今日もメインフレームの暗い画面と向き合っていることだろう。
PL/Iという言語は、一見すると古臭いCOBOLの隣にいる堅苦しい言語に見えるかもしれない。だが、その実態は、メモリ管理の機微からコンパイラの最適化戦略までを掌握できる、非常に理知的で奥深いツールだ。今日は、バッチ処理の「心臓部」とも言える`STATIC`属性について、現場で泣きを見ないための深掘り解説をしよう。
1. STATIC変数の本質：メモリの「永続性」とは何か
PL/Iにおいて`STATIC`を宣言した変数は、プログラムの実行開始から終了まで、その生存期間（Extent）を全うする。これは、自動（`AUTOMATIC`）変数がブロックに入るたびにスタック上で生成され、抜けると消えるのとは対照的だ。
ここで初心者が陥りやすいのが、「初期化タイミング」の誤解だ。`STATIC`変数の初期化は、プログラムが`PROCEDURE`の先頭行を実行する「前」に行われる。いわゆる「ロード時（プログラムがメモリに読み込まれた時点）」の静的初期化だ。
実践的なコード例：カウンターによる確認
/i
TEST_STATIC: PROCEDURE OPTIONS(MAIN);
/ 実行中に値を保持し続けるSTATIC変数 /
DCL MSG_COUNT FIXED BIN(15) STATIC INIT(0);
/ 処理用の自動変数 /
DCL I FIXED BIN(15);
DO I = 1 TO 3;
CALL INCREMENT_AND_PRINT;
END;
INCREMENT_AND_PRINT: PROCEDURE;
/ この変数は呼び出されるたびにクリアされることはない /
MSG_COUNT = MSG_COUNT + 1;
PUT SKIP LIST(‘現在のカウント値:’ || TRIM(MSG_COUNT));
END INCREMENT_AND_PRINT;
END TEST_STATIC;
このコードを実行すれば、カウントは1, 2, 3と増え続ける。もしこれを`AUTOMATIC`で宣言していたら、常に値は不定（あるいは初期値）に戻り、期待したバッチの集計処理は破綻するだろう。
2. マルチスレッド環境とReentrant（再入可能）の呪縛
さて、ここからがベテランの領域だ。現代のメインフレーム環境では、CICSやバッチのマルチスレッド実行が当たり前になっている。ここで`STATIC`を使うと、「共有メモリの競合」という悪魔が顔を出す。
なぜSTATICは再入可能コードの敵なのか？
`STATIC`変数はプログラムのロードモジュール（CSECT）内に固定配置される。もし、複数のトランザクションやタスクが同じロードモジュールを共有している場合、`STATIC`変数は「すべてのスレッドから書き換え可能な共有変数」として機能してしまう。
- 問題のシナリオ:
- スレッドAが`MSG_COUNT`を更新している最中に、スレッドBが同じプログラムを呼び出し、`MSG_COUNT`をクリア、あるいはインクリメントする。
- 結果、計算結果が壊れ、デバッグ不可能なデータの不整合が発生する。
現場の鉄則: 「再入可能（`REENTRANT`）であるべき処理（CICSプログラムや、共用サブプログラム）では、`STATIC`の使用を極力避けるか、少なくとも共有されるべきでないデータには`AUTOMATIC`または`BASED`変数を使用せよ」。
3. ONユニットとSTATICの危うい関係
PL/Iの強力な武器である`ON`ユニット（例外処理）内で`STATIC`変数を操作する際は注意が必要だ。
/i
DCL ERROR_FLAG BIT(1) STATIC INIT(‘0’B);
ON CONVERSION BEGIN;
/ エラー発生時にフラグを立てる /
ERROR_FLAG = ‘1’B;
PUT SKIP LIST(‘変換エラーが発生しました。静的フラグをONにします。’);
END;
もし、この`ON`ユニットがプログラムの途中で動的に記述（`ON CONDITION`など）されている場合、`STATIC`変数は「どの例外がいつ発生したか」を記録する履歴として非常に有用だ。しかし、`SIGNAL`で意図的に例外を飛ばしている場合、`STATIC`変数の状態が残存したまま次のループへ突入し、誤った例外判定を引き起こす可能性がある。`ON`ユニットを抜ける前に、必ずフラグの管理を徹底してほしい。
4. エンジニアへのアドバイス：デバッグのコツ
もし、バッチ実行中に「なぜか変数の値が予期せず書き換わっている」という事態に遭遇したら、以下の手順で切り分けろ。
1. ストレージ・マップの確認: コンパイラオプションに`MAP`を指定し、当該変数が`STATIC`領域に配置されているか確認する。
2. OFFSETの特定: コンパイルリストから変数のオフセットを確認し、ダンプリストと照合する。隣接する変数がオーバーフローして`STATIC`領域を侵食していないか（`DECLARE`の境界ミス）を確認するのが定石だ。
3. モジュール分離: 再入性が疑われる場合は、`STATIC`を使用している変数を「制御ブロック（DSECT/BASED変数）」に追い出し、呼び出し元からアドレスを渡す構造へリファクタリングすることを検討せよ。
最後に
`STATIC`は強力だ。だが、その強力さは「ライフサイクルの管理を自ら放棄する」ことと引き換えに得られるものだ。メモリと実行環境を支配下に置くのがシステムアーキテクトの仕事だが、時にはその支配欲がコードを複雑にする。
明日の改修作業では、その変数が本当に`STATIC`である必要があるのか、一度立ち止まって考えてみてほしい。君の書くその一行が、数年後の保守担当者の命を救うことになるのだから。
それでは、また現場で会おう。健闘を祈る。
