なぜ「OPTIONS(MAIN)」はただの飾りではないのか：ランタイムの深層を覗く
若い連中からよく受ける質問がある。「なぜプログラムの最後に `OPTIONS(MAIN)` をつけるのか？ 単なる識別子じゃないのか？」と。
答えは否だ。あれはコンパイラに対する単なる属性指定ではない。OSやJCLから制御を受け取り、LE（Language Environment）という巨大なランタイム環境と握手をするための「入り口」を生成せよ、という極めて重要な指示書なんだ。
今日は、大規模バッチ改修で必ずと言っていいほど遭遇する「プログラムの初期化」と「LE連携」の裏側について、現場の視点から解説しよう。
—
1. OPTIONS(MAIN)が生成する「見えざるルーチン」
PL/Iで `OPTIONS(MAIN)` を付与すると、コンパイラはオブジェクトコードの先頭に、プログラム本体（PROCEDURE）を呼び出すための「ブートストラップ・ルーチン」を自動生成する。
このルーチンは、以下のような地味だが不可欠な仕事を裏で行っている。
- LE環境の初期化: ヒープメモリの確保、スタックの準備、そして何より「ONユニット」のスタックを構築する。
- 引数の受け渡し: JCLの `PARM` フィールドから渡される文字データを、PL/Iの `CHARACTER` 型として適切にパースし、PROCEDUREに渡す。
- 例外処理の基盤構築: 異常終了時にどこでトラップをかけるかの初期設定。
これを理解していないと、いざという時のダンプ解析で「なぜこのONユニットが動かないのか？」という泥沼にはまることになる。
—
2. 実践的なメインプログラムの構造例
現場でよく見る「安全な」メインプログラムの基本形を提示する。VSAMのアクセスやONユニットを組み合わせた、いわゆるテンプレートに近い形だ。
/i
BATCH_PGM: PROC(PARM_STR) OPTIONS(MAIN);
/ — 定義部 — /
DCL PARM_STR CHAR(100) VAR; / JCL PARMを受け取る /
DCL VSAM_FILE FILE RECORD INPUT; / VSAMファイル定義 /
DCL EOF_FLAG BIT(1) INIT(‘0’B); / 終了フラグ /
/ — 異常系トラップ（ONユニット） — /
/ 予期せぬエラー発生時にダンプを出して終了させるのが定石 /
ON ERROR BEGIN;
PUT SKIP LIST(‘!!! 重大なエラーが発生しました !!!’);
CALL PLIDUMP(‘TFCB’, ‘エラー発生時のスタックトレースを出力’);
STOP;
END;
/ — ファイル読み込みループ — /
ON ENDFILE(VSAM_FILE) EOF_FLAG = ‘1’B;
OPEN FILE(VSAM_FILE);
DO WHILE(^EOF_FLAG);
READ FILE(VSAM_FILE) INTO(REC_BUFFER);
IF EOF_FLAG THEN LEAVE;
/ 実際のビジネスロジックをここに記述 /
CALL PROCESS_DATA(REC_BUFFER);
END;
CLOSE FILE(VSAM_FILE);
PUT SKIP LIST(‘プログラム正常終了’);
END BATCH_PGM;
—
3. トラブルシューティングの勘所：LE環境との付き合い方
現場でバッチが「理由不明のOC1」や「LEランタイム・エラー」で落ちる場合、原因の多くは `OPTIONS(MAIN)` が管理する環境と、外部モジュール（例えばCOBOLで書かれたサブルーチンなど）の不整合にある。
- ONユニットのスコープに注意:
`OPTIONS(MAIN)` の下で定義したONユニットは、そのPROCEDURE内だけでなく、呼び出されたサブプログラムでも有効だ。もしサブプログラム内で独自に `ON ERROR` を定義していない場合、メインのONユニットが拾い上げてしまう。予期せぬ制御フローにならないよう、必ず呼び出し先でのエラー処理を意識せよ。
- BUILTIN関数の活用:
`ADDR()` や `LENGTH()`、あるいは `DATETIME()` といった組込関数は、コンパイラが最も効率の良い機械語に変換してくれる。自作のサブルーチンで代替しようなどとは考えるな。LEが最適化したコードに勝てるはずがない。
- PARMの取り扱い:
`OPTIONS(MAIN)` が受け取る `PARM` は、OSによって可変長形式で渡される。`VAR` 属性を付けた `CHAR` 型で受けるのが現代のコーディング標準だ。昔のように固定長で受けて `SUBSTR` で切り出すような無駄な処理は、バグの温床になるだけだ。
最後に：現場のエンジニアへ
「動けばいい」というコードと、「メンテナンス性と堅牢性を考慮した」コードの差は、こうしたランタイムの挙動に対する理解から生まれる。
`OPTIONS(MAIN)` は、君たちが書いたPL/Iコードが、メインフレームという巨大なOSの上で「一人の立派な住人」として振る舞うためのパスポートだ。このパスポートがどのように発行されているかを知ることは、君たちがよりシニアなエンジニアへ成長するための登竜門でもある。
次回の改修作業では、ただコードを書くのではなく、「この行がLE環境でどう解釈されるか？」を想像しながらキーを叩いてみてほしい。それができるようになった時、君たちはもう、ただのコーダーではなく「システムアーキテクト」の一歩を踏み出しているはずだ。
