レガシーの深淵へようこそ：PL/Iの「STATIC変数」とマルチスレッドという壁
こんにちは。メインフレームの世界へようこそ。
JavaやCOBOLの経験がある皆さんなら、「変数の寿命」については既にお馴染みかもしれませんね。しかし、PL/Iという言語の前に立つと、少し不思議な感覚を覚えるはずです。
「予約語がない？ 変数名がキーワードと被ってもいいの？」という驚きから始まり、次に直面するのが「STATIC属性」の罠です。今日は、この一見古風で、しかし非常に強力な「静的メモリ確保」の世界を、現場の知見を交えて紐解いていきましょう。
—
1. PL/Iの「自由さ」は諸刃の剣
まず、皆さんが最初に驚くのは「予約語が存在しない」という言語仕様でしょう。
例えば、Javaなら `if` や `while` はシステムが専有するキーワードですが、PL/Iの世界では、あなたが自分で `IF` や `WHILE` という名前の変数を作っても、コンパイラは（文脈を読んで）文句を言いません。
「便利じゃないか！」と思うかもしれませんが、これは非常に危険な遊びです。可読性を損なわないためにも、変数名には業務ルールを適用するのが、この世界での「大人の嗜み」です。
—
2. STATIC属性：プログラムの「記憶」を永続化する
PL/Iのデータ宣言で頻出する `STATIC` 属性。これは、「プログラムが動いている間、ずっとその場所を確保し続ける」という命令です。
皆さんが普段書いているJavaのクラス変数（staticフィールド）に近い感覚ですが、メインフレームの世界ではこれが「メモリの節約」と「初期化のタイミング」という、非常にシビアな問題に直結します。
コード例：STATIC変数の宣言
1
/ 変数の宣言例 /
DCL COUNTER FIXED BIN(31) STATIC INIT(0);
/
COUNTERという変数を静的に確保。
STATIC属性により、プログラムが終了するまで値は保持されます。
INIT(0)は一度だけ実行される初期化処理です。
/
この `STATIC` の最大のメリットは、「関数（プロシージャ）を何度呼び出しても、前の値が残っている」という点です。例えば、バッチ処理でレコードをカウントし続けるような処理には非常に適しています。
—
3. 「再入可能性（リエントラント）」という名の魔物
さて、ここからが本題です。モダンなシステム構築では「マルチスレッド」や「並行処理」が当たり前ですよね。ここで `STATIC` 変数は、悪魔に変わることがあります。
「再入可能性（Reentrancy）」とは、複数の処理フローから同時に同じコードが呼び出されても、安全に動作することを指します。もし `STATIC` 変数に「現在の処理中の状態」を書き込んでいたらどうなるでしょうか？
- スレッドAが `STATIC` 変数に「1」を書き込む。
- 処理の途中でスレッドBが割り込み、同じ変数に「2」を書き込む。
- スレッドAが計算を再開すると、変数は「2」になっており、計算が崩壊する。
これが、レガシー移行の現場で最も恐れられる「原因不明のバグ」の正体の一つです。
現場からのアドバイス：どう回避するか？
1. 基本はAUTOMATIC（デフォルト）を使う:
PL/Iでは何も指定しなければ `AUTOMATIC`（スタック領域）に確保されます。こちらは呼び出しごとにメモリが確保されるため、マルチスレッド環境でも安全です。
2. 定数にはSTATICを使う:
「一度決めたら変わらない設定値」や「読み取り専用のテーブル」には `STATIC` を使っても問題ありません。
3. どうしてもSTATICが必要なら排他制御:
どうしても値を共有したい場合は、OSのロック機能などを使って「今、この変数を使っているのは私だけ！」という状態を保証しなければなりません。
—
まとめ：怖がらず、適材適所で
PL/Iの `STATIC` 変数は、メインフレームの限られたメモリリソースを賢く使うための先人の知恵です。決して「古い技術だからダメ」なのではありません。
「この変数は、プログラムの実行中に値を引き継ぐ必要があるか？」
「それとも、呼び出されるたびに新品が必要か？」
この問いを一つずつ紐解いていけば、PL/Iは非常に論理的で美しい言語だと気づくはずです。もしマイグレーション中に「なぜか値が化ける」という謎の現象に遭遇したら、まずはその変数が `STATIC` ではないか、そしてどこかの誰かが同時に書き込んでいないかを疑ってみてください。
皆さんの開発ライフが、メインフレームの広大な宇宙でより良いものになることを願っています。また分からないことがあれば、いつでも聞きに来てくださいね！
