【入門編】AUTOMATICとSTATICストレージ属性の生存期間 – PL/Iの基本構文とデータ制御実践ガイド

メインフレームの世界に飛び込んだ皆さん、ようこそ！COBOLの堅実さや、Javaのオブジェクト指向に慣れていると、PL/Iという言語は少し「古風な魔法」のように見えるかもしれません。

でも、安心してください。PL/Iは非常に論理的で、かつてのエンジニアたちが「いかに効率よく、かつ安全にメモリを使うか」を突き詰めた結果生まれた、非常に理にかなった言語なんです。

今日は、その中でも特に重要で、かつバグの温床になりがちな「メモリの寿命（ストレージ属性）」について、じっくり紐解いていきましょう。

—

PL/Iにおいて、変数を宣言する際、私たちはその変数が「いつ生まれて、いつ死ぬのか」を制御できます。それが `AUTOMATIC` と `STATIC` です。

`AUTOMATIC` は、プロシージャ（関数）が呼ばれた瞬間に生まれ、処理が終わると跡形もなく消え去ります。

`STATIC` は、プログラムがロードされた瞬間に生まれ、プログラムが終了するまで決して消えません。

—

言葉だけだと少し硬いので、実際のコード例を見てみましょう。PL/Iのメインフレーム開発では、これらは `DCL` (DECLARE) 文で指定します。

/i
MY_PROG: PROC OPTIONS(MAIN);

/ AUTOMATICはデフォルトなので省略可能ですが、あえて書くこともあります /
DCL COUNTER_AUTO FIXED BIN(31) AUTOMATIC INIT(0);

/ STATICは値が消えません。プログラム実行中ずっと生き続けます /
DCL COUNTER_STATIC FIXED BIN(31) STATIC INIT(0);

/ 処理のたびに呼び出される内部手続き /
INCREMENT_TEST: PROC;
COUNTER_AUTO = COUNTER_AUTO + 1;
COUNTER_STATIC = COUNTER_STATIC + 1;

PUT SKIP LIST (‘AUTOの値: ‘ || COUNTER_AUTO);
PUT SKIP LIST (‘STATICの値: ‘ || COUNTER_STATIC);
END INCREMENT_TEST;

/ 2回呼び出してみる /
CALL INCREMENT_TEST; / 1回目 /
CALL INCREMENT_TEST; / 2回目 /

END MY_PROG;

この「STATICは値が残る」という特性は、便利な反面、「前回の処理のゴミが残っていて計算が合わない」というバグの代表格になります。特にマイグレーション時に「あれ？なぜか値がおかしい」と思ったら、まず `STATIC` の存在を疑うのがベテランの流儀です。

—

メインフレームの世界では、一つのプログラムを大勢のユーザーやバッチが同時に使います。もし、あるユーザーが計算途中の `STATIC` 変数を書き換えている最中に、別のユーザーの処理が割り込んだらどうなるでしょう？

そう、計算結果がめちゃくちゃになりますよね。これを防ぐために、現代のオンライン処理（CICSなど）では、原則として `AUTOMATIC` を使うのが鉄則です。

—

PL/Iのストレージ属性は、メモリ管理という「コンピュータの深淵」に少しだけ触れるインターフェースです。

この2つを使い分けるだけで、皆さんの書くコードはぐっと堅牢で、メインフレームの過酷なバッチ処理にも耐えうるものになります。もしコードを読んでいて `DCL` 文にこのキーワードを見つけたら、「ああ、この変数はこういう性格なんだな」と優しく声をかけてあげてくださいね。

また何か分からないことがあれば、いつでも聞いてください。一緒にメインフレームの深い森を歩いていきましょう！