メインフレームの「動的メモリ」と付き合う：ALLOCATEとSTORAGE条件の深淵
現場の諸君、今日もメインフレームの暗い海で格闘していることだろう。
PL/Iの保守をしていると、静的領域（STATIC）だけでは収まりきらない巨大なデータ構造や、件数が予測不可能なバッチ処理に遭遇する。そこで登場するのが`ALLOCATE`文による動的メモリ確保だ。しかし、この「ヒープ領域」への安易な依存は、しばしばシステムを停止させる爆弾を抱えることになる。
今日は、特に「STORAGE条件」という名の悲鳴を、どう適切にハンドリングするかについて、現場の知見を共有しよう。
—
1. なぜ「動的」なのか：ALLOCATE文の現在地
PL/Iにおいて、`ALLOCATE`は単なるメモリ確保ではない。それは、OS側のストレージ管理と直接対話する行為だ。特に`BASED`変数を用いた動的割り当ては、VSAMファイルから読み込んだ大量のレコードを一時的に保持したり、複雑な連結リストを構築したりする際に必須の技術だ。
1
/ 構造体定義： BASED属性を付与することで、ポインタ変数による制御が可能になる /
DCL 1 WORK_REC BASED(P_WORK_REC),
2 KEY_ID CHAR(10),
2 DATA_VAL CHAR(100);
DCL P_WORK_REC PTR; / ポインタ変数 /
/ ヒープ領域からメモリを確保 /
ALLOCATE WORK_REC;
/ ここでP_WORK_RECが指すアドレスに対して値を設定 /
P_WORK_REC->KEY_ID = ‘TEST001’;
ここで重要なのは、`ALLOCATE`したメモリは、明示的に`FREE`しない限り、`PROCEDURE`が終了しても消えないという点だ。これを忘れると、バッチ処理の中でメモリリークを引き起こし、じわじわと領域を食いつぶす「静かなる犯人」となる。
—
2. 「STORAGE条件」という警鐘
バッチが突如として異常終了（ABEND）し、ダンプリストに`STORAGE`の文字が踊ったとき、それは「もうこれ以上、OSからメモリをもらえない」というシステムからの最後通告だ。
標準的なコーディングでは、これを無視しがちだが、大規模なシステムであれば`ON CONDITION`を使って救済措置を講じることがプロの仕事だ。
1
/ STORAGE条件のハンドリング /
ON STORAGE
BEGIN;
/ ここでログ出力や、一時ファイルの切り替え、あるいは安全な終了処理を行う /
PUT SKIP LIST(‘警告: 動的ストレージが枯渇しました。緊急終了を開始します。’);
CALL DUMP_PROGRAM_STATE; / 独自のダンプ生成ルーチン /
STOP;
END;
—
3. 実践：VSAM読み込みにおける動的確保とエラー制御
実際のバッチ処理でよくあるパターンを例示しよう。VSAMから読み込んだデータを動的配列に格納する際、メモリ不足に備える実装だ。
1
MY_PROC: PROC OPTIONS(MAIN);
DCL P_REC PTR;
DCL 1 REC_STRUC BASED(P_REC),
2 REC_KEY CHAR(8),
2 REC_BODY CHAR(100);
/ ストレージ不足時の例外処理定義 /
ON STORAGE BEGIN;
PUT SKIP LIST(‘メモリ確保失敗: バッチ処理を中断します’);
SIGNAL CONDITION(ABORT_PROC);
END;
/ VSAMオープン処理などは省略 /
DO WHILE (NOT_EOF);
/ 動的確保 /
ALLOCATE REC_STRUC;
/ VSAM読み込み処理 (例: READ FILE(VSAM_IN) INTO(REC_STRUC) ) /
/ ここで読み込み失敗したらメモリを解放する等のケアも必要 /
/ 処理が終わったら忘れずに解放 /
FREE REC_STRUC;
END;
END MY_PROC;
—
4. 現場で生き残るためのデバッグの極意
STORAGE条件で落ちた際、ダンプ解析で見るべきポイントは以下の3点だ。
1. 確保の連鎖（Chain）を確認せよ:
ダンプ上のポインタ変数を追い、`ALLOCATE`された領域がどこで繋がっているかを確認する。大抵の場合、`FREE`のし忘れや、ループ内での過剰な確保が見つかるはずだ。
2. REGIO設定とREGION値の乖離:
プログラムのバグではなく、単純にJCLの`REGION`パラメータが足りていないケースも多い。コンパイラのリスト出力にある「ストレージ所要量」と、実行時の`REGION`サイズを照らし合わせるのが基本中の基本だ。
3. BUILTIN関数の活用:
`STORAGE`（組み込み関数）を使って、現在確保しているメモリ量を監視するロジックをデバッグモードで仕込んでおくのも手だ。
最後に
「動的メモリ」は強力な武器だが、制御を誤れば自らの首を絞める諸刃の剣だ。`ALLOCATE`と`FREE`は対になる。この原則を徹底し、万が一の`ON STORAGE`を仕込んでおく。これだけで、夜中の呼び出し対応の確率はぐっと下がるはずだ。
技術は裏切らない。だが、過信は禁物だ。今日も堅牢なコードを書いていこう。何かあればまた聞きに来てくれ。
