メインフレームPL/Iの落とし穴？「STATIC変数」とマルチスレッドの知られざる関係
皆さん、こんにちは！ メインフレームの世界へようこそ！
JavaやCOBOLなどの経験はあるけれど、PL/Iは初めて…という方が、このブログにたどり着いてくださったのかなと思います。メインフレームというと、なんだか難しそうで、敷居が高いイメージがあるかもしれませんよね。でも、大丈夫！PL/Iも、一つずつ紐解いていけば、意外と面白くて、そして強力な言語なんですよ。
今日は、特にz/OS環境でマルチスレッドでPL/Iプログラムを動かす際に、ちょっと注意が必要な「STATIC変数」について、その不思議な挙動と、どうやってうまく付き合っていくのかを、現場のリアルな経験を交えながら、優しく解説していきたいと思います。
プログラムの「記憶力」：STATIC変数とは？
まず、PL/Iのプログラムがどうやって動くのか、その基本からおさらいしましょう。
PL/Iのプログラムは、大まかに言うと「PACKAGE」や「PROCEDURE」といったブロックで構成されます。そして、プログラムの中で使うデータ（変数）には、それぞれ「属性」というものが設定されます。この属性が、その変数がどこに、どのように格納され、どういう役割を持つのかを決める、いわば「身分証明書」みたいなものなんです。
今回注目するのは「STATIC」という属性を持つ変数です。これは、プログラムが実行される前に、メモリの決まった場所に確保されて、プログラムの実行中はずっとその場所を占有し続ける、という特徴があります。例えるなら、プログラムが起動するたびに、決まった席に座る「常連さん」みたいなものですね。
Javaでいうところのstatic変数や、COBOLでいうところのWORKING-STORAGE SECTIONで宣言された変数が、プログラムの開始から終了までずっとメモリ上に存在し続けるイメージに近いかもしれません。
宣言してみよう！
PL/Iでは、STATIC変数はこのように宣言します。
MY_PACKAGE: PACKAGE;
DECLARE MY_STATIC_VAR FIXED BINARY(31) STATIC INITIAL(0);
MY_PROCEDURE: PROCEDURE;
/ … 処理 … /
END MY_PROCEDURE;
END MY_PACKAGE;
ここで、`DECLARE MY_STATIC_VAR FIXED BINARY(31) STATIC INITIAL(0);` という部分がポイントです。
- `DECLARE`: 変数を宣言しますよ、という合図です。
- `MY_STATIC_VAR`: 変数名です。わかりやすい名前をつけましょう。
- `FIXED BINARY(31)`: データの型とサイズを指定しています。ここでは31ビットの固定小数点二進数、というイメージです。数値データを扱うことが多いですね。
- `STATIC`: ここで「静的な」変数ですよ、と宣言しています。プログラム開始前にメモリが確保される、あの常連さんですね！
- `INITIAL(0)`: プログラムが始まる前に、この変数に初期値として0を入れておきます、という指定です。
マルチスレッドとSTATIC変数：知られざる「競合」の影
さて、ここからが本題です。最近のシステムでは、処理を高速化するために、一つのプログラムを複数の「スレッド」に分けて同時に実行することがよくあります。z/OSでも、CICSトランザクションや、UNIX System Services (USS) 上で動くプログラムなどで、マルチスレッドの恩恵を受けることができます。
ここで、先ほどのSTATIC変数に、ちょっとした「落とし穴」が潜んでいるんです。
もし、複数のスレッドが、同じSTATIC変数を同時に更新しようとしたら、どうなると思いますか？
そうです、まるで複数の人が同じ一つのペンを同時に使おうとして、取っ組み合いになるような状況が発生しかねません。どちらのスレッドが先に書き込んだか、あるいは書き込みの途中で別のスレッドが読み取ってしまったら…予期しない値になってしまったり、プログラムがおかしな動作をしてしまったりする可能性があります。これが「競合（コンフリクト）」と呼ばれる現象です。
Javaなどでは、synchronizedキーワードを使って、一度に一つのスレッドしかアクセスできないように制御することが一般的ですよね。COBOLでも、排他制御を意識したコーディングが必要になります。
PL/Iの「THREAD」属性：スレッドごとに「個室」を用意する魔法
では、PL/Iでは、このSTATIC変数の競合にどう対処するのでしょうか？
ここで登場するのが、ちょっと聞き慣れないかもしれない「THREAD」属性なんです！
`STATIC THREAD` と指定することで、なんと！ 各スレッドが、そのSTATIC変数専用の「個室」を持つことができるようになるんです！
例えるなら、先ほどの「常連さん」が、プログラム全体で一つの席に座るのではなく、スレッドごとに自分専用の席を用意してもらえる、というイメージです。これなら、他のスレッドの邪魔をすることなく、安心して自分の席で作業できますよね。
THREAD属性をつけてみよう！
先ほどのSTATIC変数の宣言に、`THREAD`属性を加えてみましょう。
MY_PACKAGE: PACKAGE;
/ THREAD属性を追加！これで各スレッドは専用のMY_STATIC_VARを持つ /
DECLARE MY_STATIC_VAR FIXED BINARY(31) STATIC THREAD INITIAL(0);
MY_PROCEDURE: PROCEDURE;
/ … 処理 … /
END MY_PROCEDURE;
END MY_PACKAGE;
たったこれだけです！ `STATIC` の後に `THREAD` を追加するだけで、z/OSのPL/Iコンパイラは、この変数をスレッドごとに独立した領域に確保してくれるようになります。
これにより、複数のスレッドが同時にこの `MY_STATIC_VAR` を更新しても、お互いの値に影響を与えることはありません。それぞれのスレッドは、自分専用の変数に自由に書き込んだり読み取ったりできるので、競合の心配がなくなるんです。
なぜ「THREAD」属性が重要なのか？（現場からの声）
「でも、そんなに頻繁にマルチスレッドでPL/Iプログラムを動かすことなんてあるの？」と思われるかもしれません。
確かに、歴史的に見れば、PL/Iはバッチ処理でじっくりと長時間動くイメージが強かったかもしれません。しかし、近年のメインフレームシステムでは、CICSのようなオンライン処理や、USS上で動作するサーバーアプリケーションなど、マルチスレッド環境でPL/Iが活用されるケースは増えています。
特に、過去に開発されたPL/Iプログラムを、そのままの形でマルチスレッド環境に移行しようとした際に、この`STATIC THREAD`属性を考慮しないと、思わぬバグに遭遇することがあるんです。
例えば、あるバッチ処理で何の問題もなく動いていたプログラムが、CICSのトランザクションとして動かしたら、特定の値がおかしくなってしまう…なんていう、原因究明に頭を悩ませるようなケース。その原因が、まさにこの「STATIC変数の競合」だった、という話は、現場ではよく耳にします。
まとめ：PL/IのSTATIC変数は怖くない！
今日のまとめです。
- PL/Iの `STATIC` 変数は、プログラム開始前にメモリが確保され、プログラム終了まで存在し続ける変数です。
- マルチスレッド環境で複数のスレッドが同じ `STATIC` 変数を更新すると、競合が発生する可能性があります。
- `STATIC THREAD` 属性を指定することで、各スレッドが `STATIC` 変数専用の領域を持つようになり、競合を回避できます。
PL/Iの `STATIC` 変数とマルチスレッドの関係は、一見すると少し複雑に感じるかもしれませんが、`THREAD` 属性という強力な味方のおかげで、実はとてもシンプルに解決できる問題なんです。
メインフレームのレガシーシステムに触れる機会がある方、特にPL/Iのプログラムを扱われる方は、ぜひこの `STATIC THREAD` 属性を覚えておいてください。この知識があれば、マルチスレッド環境での予期せぬバグに悩まされることも少なくなり、より安心してプログラム開発や改修を進めることができるはずです。
「レガシーだから…」と敬遠せず、一つずつ、丁寧に紐解いていくことで、PL/Iの持つ奥深さや、メインフレームシステムの安定性・信頼性を、ぜひ皆さんも体験してみてくださいね。
それでは、また次回のブログでお会いしましょう！
