PL/IとCICSの「メモリ管理」：二つの巨人が喧嘩しないための処方箋
こんにちは。メインフレームの世界へようこそ。Javaで`new`を呼び、ガベージコレクションにすべてをお任せしてきた皆さんにとって、PL/Iのストレージ管理は少し古風で、時に気難しい職人のように見えるかもしれませんね。
今日は、CICS環境でPL/Iを扱う際、誰もが一度は冷や汗をかく「メモリ管理の二重支配」について、現場の知見を交えて紐解いていきましょう。大丈夫、仕組みさえ分かれば怖くありませんよ。
—
1. PL/Iの「ALLOCATE」とCICSの「GETMAIN」は似て非なるもの
PL/Iプログラムの中で動的にメモリを確保したいとき、私たちは大きく分けて二つの手段を持っています。
- PL/I標準の `ALLOCATE` 文: 言語仕様そのもの。`BASED`変数を使ってメモリを確保します。
- CICSの `EXEC CICS GETMAIN` コマンド: CICS（オンライン制御プログラム）のサービス。
JavaやCOBOLの経験がある方は、「メモリを確保するならどっちでも同じじゃないの？」と思うかもしれません。しかし、ここが落とし穴です。
PL/Iの `ALLOCATE` は、PL/Iランタイムライブラリが管理する「ヒープ」からメモリを切り出します。一方、CICSの `GETMAIN` は、CICSのタスク管理領域から直接メモリをぶんどってきます。
この二つを無秩序に混在させると、後で「どっちが解放（FREEMAIN/FREE）するんだっけ？」という混乱が生じ、最悪の場合、メモリリークや「ストレージ破壊（お化けメモリ）」という悪夢を招くことになります。
—
2. 実践コード：安全な「BASED変数」の歩き方
PL/Iで動的メモリを扱う際の基本形を見てみましょう。ここでは、`BASED`変数を使って、「必要なときに必要な分だけメモリを確保する」というPL/Iの流儀をご紹介します。
/i
/ — サンプルプログラム：動的ストレージ確保の基本 — /
EXAMPLE: PROC OPTIONS(MAIN);
/ BASED変数は「メモリの型」を定義するだけで、まだ実体はありません /
DCL 1 MY_DATA BASED(P_MY_DATA),
2 ID FIXED BIN(15),
2 NAME CHAR(20);
DCL P_MY_DATA POINTER; / アドレスを保持するためのポインタ /
/ 1. PL/I標準のALLOCATEでメモリを確保 /
ALLOCATE MY_DATA;
/ この時点で、P_MY_DATAには確保されたメモリの先頭アドレスが入ります /
ID = 101;
NAME = ‘PL/I TEST’;
/ ここで何らかの処理を行う… /
/ 2. 使い終わったら必ずFREEする！ /
FREE MY_DATA;
RETURN;
END EXAMPLE;
見ての通り、PL/Iの `ALLOCATE` は非常に直感的ですよね。しかし、CICS環境では、これに加えて「CICS側が管理するメモリ」という要素が絡んできます。
—
3. なぜ「混在」がトラブルの元なのか
CICS環境で最も恐ろしいのは、「PL/Iで確保したメモリを、CICSのコマンドで解放しようとする」あるいはその逆です。
- PL/Iの `FREE`: PL/Iが「自分が確保した管理テーブル」を探しに行きます。CICSが確保したメモリにはそのテーブルがないため、異常終了（ABEND）します。
- CICSの `FREEMAIN`: CICSがメモリを強制的に回収します。PL/Iは「まだそのメモリは自分の管理下にある」と思い込んでいるため、次にそのメモリにアクセスした瞬間にシステムがクラッシュします。
現場からの鉄則：ルールを統一しよう
現場のトラブルシューティングで私がいつも助言するのは、「メモリ管理の主導権をどちらかに一本化せよ」ということです。
1. ビジネスロジック内: 原則としてPL/Iの `ALLOCATE` / `FREE` を使用する。これが最も安全で、コンパイラの最適化も効きやすいです。
2. CICS特有のインターフェース: CICSのAPIで受け取るデータ構造（例えば、他のプログラムと共有するメモリなど）は、`EXEC CICS GETMAIN` を使用する。
—
4. 最後に：怖がる必要はありません
PL/Iのストレージ管理は、まるで「自分で自分の部屋を掃除する」ようなものです。`ALLOCATE` で家具を運び込み、`FREE` で片付ける。当たり前のことですが、CICSという「巨大なマンションの管理人」が横にいるため、少しだけ作法が必要になるだけなのです。
「Javaのガベージコレクションが恋しい」と思うかもしれませんが、PL/Iでメモリを直接コントロールする感覚は、システムのパフォーマンスを極限まで引き出すための「職人の手仕事」です。この感覚が分かってくると、メインフレームの基幹システムを動かすのが、もっと楽しくなってきますよ。
もし、メモリ周りで「原因不明のABEND」に遭遇したら、まずは「誰が確保して、誰が解放しようとしているのか」という所有権のバトンタッチを追いかけてみてください。必ず答えは見つかります。
それでは、また次回のレクチャーでお会いしましょう。健闘を祈ります！
