こんにちは。日夜、膨大なバッチジョブの嵐とVSAMの制御に格闘しているメインフレームエンジニアの皆さん、お疲れ様です。
オープン系のエンジニアから「なんで今どきPL/Iなんですか？」なんて無粋な質問をされることがありますが、金融や流通の基幹を支えるこの言語の奥深さを知ると、そう簡単には離れられない魅力がありますよね。COBOLよりも自由度が高く、C言語よりも泥臭くハードウェアを叩ける――それがPL/Iです。
さて、今回はPL/Iの基本構文、その中でも「プログラムの玄関口」である `OPTIONS(MAIN)` の初期化処理と、背後で動いている Language Environment (LE：CEE) のランタイム環境の構築について、実務の現場で即座に役立つ知見をお話ししましょう。
—
1. 予約語を持たないPL/Iと `OPTIONS(MAIN)` の正体
PL/Iの最もユニークな特徴の一つに「言語に厳密な予約語が存在しない」という仕様があります。
つまり、`IF` や `THEN` といったキーワードであっても、変数の名前として宣言して使うことが技術的には可能です（もちろん、そんなことをするとソースコードを読む人間が全員発狂するので、絶対にやめましょう）。
この「コンテキスト（文脈）によって意味を解釈する」という柔軟な思想は、プログラムの起点であるエントリポイントの定義にも表れています。それが、プロシージャ文に付与する `OPTIONS(MAIN)` です。
1
MYPROG: PROC OPTIONS(MAIN);
この一行が書かれた瞬間、コンパイラとランタイム（LE）はこのプロシージャを「ジョブステップから最初に呼び出される主プログラム」として認識します。しかし、単にエントリポイントを指定するだけでは、メインフレームの荒波を乗り切る堅牢なバッチプログラムは作れません。背後で何が起きているのか、その仕組みを紐解いていきましょう。
—
2. ランタイム環境（CEE）と初期化ルーチンの裏側
プログラムがJCLの `EXEC PGM=` で実行されたとき、コントロールを最初に握るのはアプリケーションコードではありません。IBM Language Environment（LE）の初期化ルーチン、すなわちお馴染みの CEEBINIT（またはそれに類するブートストラップ）です。
LE環境がロードされると、以下のステップが水面下で実行されます。
1. ワーキングストレージ（スタック／ヒープ）の動的割振り
- `AUTOMATIC` 変数の領域確保、および `HEAP` ストレージプールの初期化。
2. ファイル制御ブロック（DCB / ACB）のオープン準備
- JCLの `DD名` と、PL/Iコード内の `FILE` 属性を結びつけるためのランタイム表の構築。
3. ONユニット（例外・割込み処理）のグローバルハンドラの登録
- `ON ERROR` や `ON ENDFILE` などのトラップ機構の有効化。
特に重要なのが、ファイルやVSAMデータセットにアクセスする前の「暗黙の初期化」です。ここを理解していないと、突如として `IBM0001S` のような残酷なABENDコードに直面することになります。
—
3. 実践：VSAMアクセスとONユニットを網羅したメインプログラム
百聞は一見にしかず。実際の現場のバッチ改修で使える、標準的なコーディングパターンを見てみましょう。
ここでは、`OPTIONS(MAIN)` を起点とし、VSAM（KSDS）のレコード入出力、および堅牢な例外処理（`ON ENDFILE`, `ON ERROR`）を組み込んだ実用的なコードを提示します。
1
/———————————————————————/
/ モジュール名: VSMUPD01 /
/ 処理概要 : VSAM(KSDS)マスタファイルを読み込み、更新処理を行う /
/———————————————————————/
VSMUPD01: PROC OPTIONS(MAIN);
/ — 宣言部 — /
DCL MSTR_FILE FILE RECORD
ENV(VSAM)
KEYED
UPDATE;
/ VSAMレコード様式（マッピング） /
DCL 1 MSTR_REC,
5 MSTR_KEY CHAR(8),
5 MSTR_DATA CHAR(72),
5 MSTR_FLAG CHAR(1);
DCL WK_KEY CHAR(8) INIT(‘ ‘);
DCL EOF_FLG BIT(1) INIT(‘0’B);
DCL IO_ERR_FLG BIT(1) INIT(‘0’B);
/ — 初期化フェーズ（LE環境構築後の最初の処理） — /
DISPLAY(‘ VSMUPD01 START ‘);
/ 異常終了（ERROR）時の共通トラップ設定 /
ON ERROR BEGIN;
DISPLAY(‘ SEVERE ERROR OCCURRED IN VSMUPD01 ‘);
IO_ERR_FLG = ‘1’B;
GOTO EXIT_ROUTINE;
END;
/ ファイル終了（ENDFILE）時のトラップ設定 /
ON ENDFILE(MSTR_FILE) EOF_FLG = ‘1’B;
/ — ファイルオープン — /
OPEN FILE(MSTR_FILE);
/ — メイン処理ループ — /
DO WHILE(^EOF_FLG & ^IO_ERR_FLG);
/ レコード読み込み（キー順アクセス） /
READ FILE(MSTR_FILE) INTO(MSTR_REC);
/ 読み込み成功時のビジネスロジック（例：フラグ更新） /
IF ^EOF_FLG THEN DO;
MSTR_FLAG = ‘1’;
/ レコードの書き換え（REWRITE） /
REWRITE FILE(MSTR_FILE) FROM(MSTR_REC);
END;
END;
/ — 終了処理フェーズ — /
EXIT_ROUTINE:
/ 開いたファイルは確実にクローズする（リソースリーク防止） /
CLOSE FILE(MSTR_FILE);
IF IO_ERR_FLG THEN
DISPLAY(‘ VSMUPD01 END WITH ERROR ‘);
ELSE
DISPLAY(‘ VSMUPD01 NORMAL END ‘);
RETURN;
END VSMUPD01;
—
4. ベテランから伝授するデバッグと保守のコツ
上記のコードを見て、「おっ」と思った人は鋭い。現場でバッチプログラムを安全に動かし続けるために、以下のポイントを体に叩き込んでおいてください。
① ONユニットは「局所化」を意識せよ
サンプルでは `ERROR` 条件をプロシージャ全体で捕捉していますが、ファイル入出力エラーなど、特定のブロックでしか起きない例外は、該当の `OPEN` や `READ` の直前でスコープを絞って `ON` を定義するのがモダンかつ安全です。グローバルに `ON ERROR` をベタ書きしすぎると、かえって原因究明の邪魔（デバッグの難航）になります。
② VSAMのステータスチェックを怠るな
PL/Iではファイル操作のエラーをONユニットや `STATUS` ビルトイン関数（`PLIRETV()` やファイル条件）で拾いますが、特にVSAMを扱う際は `ENV(VSAM)` のオプションやフィードバックコード（FDBK）の確認が不可欠です。「ファイルが開けない」「レコードが見つからない（KEY)` といった例外は、バッチ運用中の夜間コールを誘発する最大の原因です。
③ ストレージのライフサイクルを理解する
`OPTIONS(MAIN)` が終了して `RETURN`（あるいはメインプロシージャの終端）に達すると、LEは確保したヒープや自動変数のメモリをきれいにお掃除（解放）してOSに制御を返します。しかし、サブタスクや非同期処理、あるいは外部サブルーチン（`FETCH` による動的ロード）を使用している場合は、この初期化・終了のライフサイクルが複雑化します。動的ロードを行う場合は、必ず対応する `RELEASE` を忘れないようにしましょう。
—
おわりに
PL/Iの `OPTIONS(MAIN)` とランタイム環境の裏側を知ることは、単に「プログラムを動かす」だけでなく、「メインフレームという巨大なOSの上で、メモリやリソースがどう調停されているか」を理解することに他なりません。
レガシーシステムの保守は地味に見えるかもしれませんが、私たちが書く一行、設定する一つのオプションが、止まること許されない社会インフラを支えています。
次にジョブが異常終了したときは、慌てずにCEEのダンプメッセージと、今日の話を思い出してください。きっと原因への最短ルートが見えてくるはずです。
それでは、次回のインフラ・アーキテクチャ解説もお楽しみに！
