基幹システムの現場において、JCLの`PARM`パラメータで渡した制御情報をバッチプログラムのメインプロシージャでどう安全かつ正確に受け取るか。これは、何十年と動き続けているIBMメインフレームの足回りを支える上で、決して避けて通れない極めて重要なトピックだ。
JavaやC#といったモダンな言語の世界では、`main(String[] args)`の引数を配列として受け取るのは空気のように当たり前のことだが、PL/Iの世界、特にIBM Enterprise PL/Iコンパイラが吐き出すネイティブバイナリの挙動においては、この「引数の受け渡し」に特有の設計思想と、一歩間違えば夜間バッチを即座にアベンド（ABEND）へと導く厳格な制約が存在する。
今回は、`OPTIONS(MAIN)`プロシージャにおける`CHARACTER VARYING`引数を用いたPARM値の受け取りと、その裏に潜む最大長制限、そしてモダン化（マイグレーション）を見据えたアーキテクチャ上の留意点について、コンパイラの挙動を解剖しながら深く掘り下げていこう。
—
1. OPTIONS(MAIN) と CHARACTER VARYING 引数のメカニズム
PL/Iのメインプロシージャは、OS（z/OS）のEXECステートメントで指定されたJCLの`PARM=`文字列を、プログラムの引数として直接受け取ることができる。
コンパイラに対し「このプロシージャがエントリーポイントであり、OSからの制御を受け取る」と宣言するのが `OPTIONS(MAIN)` だ。そして、PARM値を受け取るための最も一般的かつ安全なデータ型が、`CHARACTER VARYING` である。
基本的な実装パターン
1
/ ————————————————————-
- JCL PARM受取りメインプロシージャのサンプル
- ————————————————————-
PARMDEMO: PROC(P_PARM_VAL) OPTIONS(MAIN);
/ 引数の宣言：最大長を明示したVARYING文字列 /
DCL P_PARM_VAL CHAR(100) VARYING;
/ 内部変数 /
DCL W_MSG_BUF CHAR(120);
/ PARMが渡されているかどうかの判定と処理 /
IF P_PARM_VAL = ” THEN
PUT SKIP LIST(‘警告: PARMパラメータが指定されていません。’);
ELSE
DO;
W_MSG_BUF = ‘受け取ったPARM値: ‘ || P_PARM_VAL;
PUT SKIP LIST(W_MSG_BUF);
/ ここにビジネスロジックを展開 /
END;
RETURN;
END PARMDEMO;
このコードは一見して非常にシンプルだが、アーキテクトの視点で見逃してはならないのが、`VARYING`文字列のデータ構造そのものである。
PL/Iの`CHARACTER VARYING`は、メモリ上で「2バイトの長さ接頭辞（Current Length Prefix）」＋「実データ本体」という構造で配置される。JCLのPARMで渡された文字列は、オペレーティングシステム（EXEC制御ブロック）から渡される際、先頭に2バイトの長さを付加された状態でこの引数領域にコピーされる。
—
2. 最大長制限の仕様とJCL PARMの「100バイトの壁」の罠
ここで、現場で最も頻発するトラブルの一つに言及しておかなければならない。それは最大長制限の仕様と、JCL自体の制約の混同である。
JCL側とPL/I側の制限事項
1. JCLの制約:
古き良きz/OSのJCLにおける`EXEC PGM=…,PARM=’…’`の記述では、PARM文字列全体で100バイト（正確には続行行を用いても1ステップあたり制限あり、基本的にはカタログドプロシージャ内も含め制約がきつい）という制約が歴史的に存在していた（近年のz/OSでは長大なPARMも許容されるケースが増えているが、レガシーなジョブストリームでは依然として100バイト制限を前提に組まれていることが多い）。
2. PL/I側の制約:
受ける側のPL/Iプログラムで `DCL P_PARMVAL CHAR(255) VARYING;` のように大きなサイズを定義することは言語仕様上、完全に合法である。しかし、JCL側から渡されるデータがそれを超えることは物理的に不可能であり、万が一JCL側が定義以上の長さを渡した場合、コンパイラが生成するコードの受渡領域でストレージ・オーバーレイ（バッファ超過）を引き起こし、最悪の場合は S0C4（保護例外） や S0C1（操作例外） といった致命的なアベンドを引き起こす。
アーキテクトの助言：
マイグレーションや機能追加でバッチの改修を行う際、「将来的に引数を増やすかもしれない」という理由で安易に受取側の`CHAR`長を巨大に設定し、JCL側の定義と不整合を起こすケースが後を絶たない。JCL側のPARM長と、PL/I側の`CHAR(n)`の定義長は、常に厳密にドキュメント化し、CI/CDパイプラインや静的解析ツールでバリデーションすべきである。
—
3. ポインタとベース変数を用いた動的パース（高度なデータ制御）
基幹システムの現場では、単一のPARM文字列の中に `DATE=20231031,MODE=BATCH,DEBUG=Y` のようなカンマ区切りの制御キーワードが複数詰め込まれているケースが多々ある。
これをきれいに構造化するために、PL/Iの強力な武器であるポインタ変数とベース変数（BASED変数）を組み合わせて、PARM文字列を動的に切り出すテクニックが使われる。
1
/ ————————————————————-
- VARYING文字列に対するポインタベース解析の例
- ————————————————————-
PARMPARSE: PROC(P_PARM) OPTIONS(MAIN);
DCL P_PARM CHAR(200) VARYING;
DCL P_WORK POINTER;
/ BASED変数の定義：任意のメモリアドレスをこの構造にマップする /
DCL 1 PARM_MAP BASED(P_WORK),
3 LEN FIXED BIN(15), / 2バイトの長さ接頭辞 /
3 BODY CHAR(180); / 実データ本体 /
/ 引数のアドレスを取得 /
P_WORK = ADDR(P_PARM);
PUT SKIP EDIT (‘実データの長さ: ‘, PARM_MAP.LEN) (A, F(5));
PUT SKIP EDIT (‘実データ本体: ‘, PARM_MAP.BODY) (A, A);
/ ここからスキャン処理やSUBSTRによる分解を行う /
RETURN;
END PARMPARSE;
このような低水準なメモリアクセスを許容する点が、PL/Iが「汎用機のC言語」と称される所以である。しかし、マイグレーション先であるJava（`String.split()`や正規表現）やC#の世界へこのロジックを移行する際、このポインタ操作をそのまま模倣しようとしてはならない。移行設計においては、PARMの仕様自体をJSONやXML、あるいはキーバリューストア的な設定ファイル読み込みへとモダナイズするのが正しいアーキテクチャ判断となる。
—
4. コンパイラオプションによる最適化とエッジケース対策
IBM Enterprise PL/Iコンパイラを使用する際、PARMの受け渡しや文字列操作を行うコードに対しては、適切なコンパイラオプションの選定が不可欠だ。
- `STGOWRFLOW` / `NOSTGOWRFLOW`:
ストレージ・オーバーフローの検知。本番稼働環境ではパフォーマンスを優先して`NOSTGOWRFLOW`を選択しがちだが、移行期やテストフェーズでは必ず有効化し、予期せぬメモリ破壊を検知できるようにすべきである。
- `TRUNC(STD)` vs `TRUNC(BIN)` vs `TRUNC(OPTIMIZE)`:
固定小数点数（`FIXED BIN`）との絡みで、PARMの長さを数値に変換して扱う際、このオプションの差異が計算結果やループ制御に微妙な影を落とす。PL/Iアーキテクトとしては、デフォルトの挙動に頼らず、コンパイラオプションはプロジェクト全体で統一された標準プロファイルを持つべきである。
また、CICSオンライン環境におけるトランザクション初期データ（`COMMAREA`）の受け渡しと、バッチのJCL `PARM` は概念が似て非なるものである点にも注意したい。CICSでは`EXEC CICS HANDLE CONDITION`や`ADDRESS COMMAREA`を用いるが、バッチの`OPTIONS(MAIN)`はあくまでz/OSのジョブステップ起動時の単発イベントである。混同して設計すると、オンライン・バッチ共通サブルーチン化の際に痛い目をみる。
—
5. レガシー移行（マイグレーション）への備え
Java、C#、あるいはクラウドネイティブなコンテナ環境へ基幹システムを移行する際、この「JCLのPARMとPL/Iメインプロシージャの結合」は、多くの場合、以下のようにモダナイズされる。
1. JCLの廃止 / オーケストレーションツールへの移行:
z/OSのJCLで流していたジョブは、統合ジョブスケジューラやApache Airflow、あるいはKubernetes上のJobマニフェストへと置き換わる。
2. 起動引数の標準化:
PL/Iの`OPTIONS(MAIN)`で受け取っていた`CHARACTER VARYING`は、移行先の言語における標準的なコマンドライン引数配列（`string[] args`）へとマッピングされる。
しかし、移行プロジェクトの現場で最も恐ろしいのは、「元のPL/Iプログラムが、PARMの空白パディングや大文字小文字の区別、異常値に対してどのような暗黙の挙動をしていたか」が誰にも分からないというブラックボックス化の呪縛だ。
だからこそ、現行のPL/Iコードが持つ仕様、特に今回解説した`CHARACTER VARYING`の境界値処理やメモリ構造に至るまでの深い理解が、移行設計の成否を分ける羅針盤となるのである。
レガシーシステムの深淵を覗くとき、システムはただコードの羅列ではなく、数十年分のビジネスの歴史そのものを語りかけてくる。その声を正確に聞き取るための技術的知見を、我々アーキテクトは常に研ぎ澄ませておかなければならない。
