CICSとPL/Iの「メモリ管理」：その危うい同居生活を紐解く
やあ。今日もメインフレームの迷宮に潜っている諸君、お疲れ様。
最近、若手エンジニアから「CICSで動的メモリを確保しようとしたら、なぜかストレージ破壊（S0C4やS0C1）が起きて収拾がつかない」という相談をよく受ける。
結論から言うと、その原因の多くは「PL/Iのストレージ管理機能」と「CICSのGETMAIN」を無造作に混ぜ合わせていることにある。今回は、この「禁断の組み合わせ」について、現場の知見を交えて徹底的に解説しよう。
—
1. なぜ「PL/IのALLOCATE」と「CICSのGETMAIN」が衝突するのか
PL/Iには、`ALLOCATE`文を使った便利な動的メモリ確保（BASED変数）がある。一方で、CICSにはご存知`EXEC CICS GETMAIN`がある。
この二つは、舞台裏での管理方法が決定的に異なる。
- PL/IのALLOCATE: PL/Iランタイムライブラリが独自のヒープ領域（通常はLanguage Environment / LEの管理下）からメモリを切り出す。解放（`FREE`）の追跡もPL/Iが行う。
- CICSのGETMAIN: CICSのタスク管理領域から直接メモリを要求する。解放（`FREEMAIN`）は明示的に行う必要がある。
何が問題か？
PL/Iで確保したメモリをCICSで解放しようとしたり、その逆を行ったりすると、それぞれの管理テーブルに整合性が取れなくなる。特にPL/Iの`FREE`文は、自分が割り当てた領域の「管理情報（ヘッダ）」をチェックする。CICSから貰った素の領域を`FREE`しようとすれば、即座にLEのストレージ異常を招くことになる。
—
2. 実践：安全なストレージ管理のコード例
現場での鉄則は「確保した手段で解放する」こと。そして、CICS環境下では、可能であればPL/Iの`BASED`変数と`ADDR`ビルトイン関数を組み合わせるのが最も「PL/Iらしい」スマートな解法だ。
以下に、CICS環境で安全にメモリを扱うための推奨パターンを記す。
1
/ CICS環境下での動的メモリ確保と解放のベストプラクティス /
TEST_PROG: PROCEDURE OPTIONS(MAIN);
/ 構造体の定義 /
DCL 1 MY_DATA BASED(P_MY_DATA),
2 REC_ID CHAR(4),
2 REC_BODY CHAR(100);
DCL P_MY_DATA POINTER INIT(NULL());
DCL LENG FIXED BIN(31) INIT(STG(MY_DATA));
/ CICSコマンドによる領域確保 /
EXEC CICS GETMAIN SET(P_MY_DATA)
LENGTH(LENG)
INITIMG(X’00’);
IF P_MY_DATA = NULL() THEN DO;
/ メモリ確保失敗時のONユニット制御を考慮する /
SIGNAL CONDITION(STORAGE_ERROR);
END;
/ ポインタ経由でデータを操作 /
MY_DATA.REC_ID = ‘0001’;
MY_DATA.REC_BODY = ‘CICS DATA ACCESS SUCCESS’;
/ 【重要】確保した手段（EXEC CICS）で解放する /
EXEC CICS FREEMAIN DATAPTR(P_MY_DATA);
P_MY_DATA = NULL(); / ダングリングポインタを避けるための防衛策 /
RETURN;
/ エラーハンドリング用のONユニット /
ON CONDITION(STORAGE_ERROR) BEGIN;
PUT SKIP LIST(‘メモリ確保に失敗しました。資源状況を確認してください。’);
END;
END TEST_PROG;
—
3. ベテランからのアドバイス：トラブルを避けるコツ
① 「BASED変数」をフル活用せよ
PL/Iの利点は、`BASED`変数を使ってメモリ領域に「型（構造体）」を被せられることだ。`EXEC CICS GETMAIN`で取得した生のポインタを、構造体のポインタとして再定義してやれば、複雑なオフセット計算から解放される。これは保守性において非常に重要だ。
② ダングリングポインタ（吊り下げポインタ）の撲滅
解放した後にポインタを`NULL()`にするのを忘れるエンジニアが多い。もしその後に誤って参照すれば、S0C4（プロテクション例外）で即死する。デバッグを楽にするためにも、解放とポインタのクリアは必ずセットで行う癖をつけよう。
③ ONユニットの使いどころ
`STORAGE_ERROR`や`AREA`条件などのONユニットは、バッチでは便利だが、CICS環境では`EXEC CICS HANDLE CONDITION`との競合に注意が必要だ。CICSの標準的なエラー処理を優先させつつ、PL/I側で補完するという「役割分担」の設計思想を忘れないでほしい。
—
最後に：なぜ「泥臭い」管理が求められるのか
「最近はJavaやクラウドが主流だから、メモリ管理なんて意識しなくても……」という声も聞こえてくる。だが、我々が扱う基幹システムは、今この瞬間も何万件ものトランザクションをさばいている。
PL/Iのメモリ管理は、コンピュータが本来持っている「限られたリソースをいかに正しく使うか」という哲学そのものだ。ここを疎かにするエンジニアは、たとえ言語が変わっても同じ失敗を繰り返す。
諸君、まずは自分の書いたプログラムが、どの領域のメモリを、どのような規律で動かしているのか、一度メモリダンプを睨みながら追ってみてほしい。そこには、教科書には載っていない「システムとの対話」があるはずだ。
また何か壁にぶつかったら、いつでも聞いてくれ。現場からは以上だ。
