【入門編】OPTIONS(REENTRANT)とマルチタスク環境 – PL/Iの基本構文とデータ制御実践ガイド

PL/Iの「再入可能性(REENTRANT)」を攻略する:マルチタスク環境で生き残るための静的ストレージ術

こんにちは。メインフレームの現場で長年PL/Iと格闘してきたアーキテクトです。

JavaやCOBOLの世界からメインフレームの世界に足を踏み入れると、最初は「何だこの不可解なキーワードの羅列は…」と戸惑うこともあるでしょう。特に、CICS(オンライン取引処理システム)やマルチタスク環境で避けては通れない`OPTIONS(REENTRANT)`という記述。

「再入可能(リエントラント)」なんて聞くと、なんだか難しそうな要塞のように聞こえますよね。でも大丈夫。PL/Iがなぜこの設計を求めるのか、その「本質」を紐解けば、怖がる必要は全くありません。

1. なぜ「REENTRANT(再入可能)」が必要なのか?

まずイメージしてみてください。あなたが非常に人気の高いカフェの店員だとします。
「REENTRANT」ではないコードは、「自分専用のメモ帳をカウンターに置きっぱなしにして仕事をする店員」です。

もし、同時にお客さんが二人やってきて、一人が注文中に、もう一人が別の注文を割り込ませたらどうなるでしょう? メモ帳の中身が混ざってしまい、大混乱ですよね。これが「再入不可能」なプログラムが引き起こすバグの正体です。

一方、`OPTIONS(REENTRANT)`を指定したプログラムは、「必要な情報はすべて手元のトレイに乗せて動く、プロフェッショナルな店員」です。誰から注文が重なっても、自分専用の作業スペース(ストレージ)を汚さないため、同時に何人もの注文を捌くことができる。これがマルチタスク環境における「再入可能」の姿です。

2. PL/Iでの「再入可能」な書き方

PL/Iでは、プログラムの入り口である`PROCEDURE`文でこの意思表示をします。

/i
/ メインプログラムの宣言例 /
MY_PROGRAM: PROCEDURE OPTIONS(MAIN, REENTRANT);

/ 静的ストレージは書き換え不可にしないと危険です /
DCL STATIC_VAL FIXED BIN(31) STATIC INITIAL(0);

/ 自動変数(スタック上の変数)は自分専用のトレイに乗るため安全 /
DCL AUTO_VAL FIXED BIN(31) AUTOMATIC;

/ 処理ロジック… /
END MY_PROGRAM;

ここで重要なポイントが一つ。`STATIC`(静的)属性を持った変数は、プログラム全体で一つしか存在しません。つまり、全員で共有する「壁掛けカレンダー」のようなものです。`REENTRANT`な環境でこれを不用意に書き換えると、別のタスクが参照している値まで書き変わってしまうという悲劇が起こります。

3. 注意すべき「ストレージの罠」

PL/Iが他の言語と少し違うのは、`AUTOMATIC`(自動)属性がデフォルトであるという点です。

  • AUTOMATIC: プロシージャが呼ばれるたびに新しい領域が確保されます。これがマルチタスクの主役です。
  • STATIC: プログラム実行中、ずっと同じ場所を占有します。共有したい定数には良いですが、作業用変数はここに入れてはいけません。

現場でよくあるトラブルが、古いソースコードで`STATIC`が多用されているケースです。これをそのままCICSのプログラムに組み込むと、あるタスクが更新した値が、数ミリ秒後に別のタスクの計算を狂わせるという、非常に解析困難な「幽霊のようなバグ」を生み出す原因になります。

4. 今日から使える「安全な設計」の鉄則

もしあなたがこれからPL/Iプログラムを設計、あるいは改修するなら、以下の三原則を心に留めておいてください。

1. 書き換えが発生する作業用変数は、すべて`AUTOMATIC`(またはデフォルト)にする

  • 明示的に宣言しなくても、PL/Iはプロシージャ内で宣言された変数はスタック上に確保してくれるので、基本的にはこれだけで再入可能です。

2. `STATIC`は「読み取り専用(定数)」として扱う

  • どうしても使いたい場合は、`INITIAL`で値をセットしたら、二度と書き換えない「定数置き場」と割り切りましょう。

3. `EXTERNAL`属性には要注意

  • 外部から参照できる変数は、再入可能性を破壊する最強の敵です。できる限りカプセル化(プロシージャ内に隠蔽)しましょう。

最後に:PL/Iは決して怖くない

PL/Iは、その歴史の長さゆえに「古い言語」と揶揄されることもあります。しかし、現代のJavaやC#が苦労して実現している「スレッドセーフな設計」を、PL/Iは半世紀以上も前から、この`OPTIONS(REENTRANT)`というたった一つのキーワードで厳格に管理してきました。

最初は見慣れないキーワードに圧倒されるかもしれませんが、それは「システムを事故から守るための防護壁」です。一つずつ、変数がどこに確保されるのか(スタックなのか、それとも共有領域なのか)を意識するだけで、あなたのPL/Iスキルはアーキテクト級に大きく飛躍するはずです。

もし現場で「変数が勝手に書き換わる!」という怪現象に遭遇したら、まずはその変数が`STATIC`になっていないか、疑ってみてくださいね。それでは、また現場でお会いしましょう。

コメント

タイトルとURLをコピーしました