汎用機の深淵：OPTIONS(MAIN)とJCL PARMの「危うい」作法
基幹システムの現場で、長年稼働し続けるPL/Iプログラム。その入り口である `OPTIONS(MAIN)` プロシージャにおけるパラメタ受け取りは、一見単純なようでいて、実はコンパイラとOSの仕様が交錯する極めて繊細な領域だ。
現代のJavaエンジニアが `String[] args` を気軽に見るのとは訳が違う。我々が扱うのは、OSのレジスタに積まれたアドレスであり、JCLのEXEC PARMで指定された「長さ」と「実データ」という、極めて生々しいバイト列の集合体なのだ。
1. JCL PARMをCHARACTER VARYINGで「正しく」受け取る
多くの現場で散見される過ちは、PARMを固定長文字列（CHARACTER(n)）で受け取り、末尾の空白をトリムして処理するような安易な実装だ。しかし、システム間の連携やバッチ制御を設計する際、`VARYING` 属性を正しく活用せねば、意図せぬアベンドやメモリ破壊を招く。
標準的な定義方法は以下の通りだ。
1
/ —————————————————————– /
/ メインプログラム：PARMの安全な受け取り方 /
/ —————————————————————– /
MAIN_PGM: PROCEDURE(PARM_PTR) OPTIONS(MAIN);
/ ポインタで受け取ることで、OSから渡されたパラメータ領域を直接参照する /
DCL PARM_PTR POINTER;
/ VARYING属性で宣言し、先頭2バイトの長さ情報をPL/Iに解釈させる /
DCL PARM_INPUT CHARACTER(100) VARYING BASED(PARM_PTR);
/
- 注意：IBMメインフレームの仕様では、PARMの先頭2バイトは長さ情報(H)である。
- VARYINGで宣言すればコンパイラが自動的にその構造をマップしてくれるが、
- JCL側での指定ミスや、他言語(COBOL)との混在環境では、
- このポインタの指す先をダンプで精査する必要がある。
/
IF LENGTH(PARM_INPUT) > 0 THEN
PUT SKIP LIST(‘入力パラメータ: ‘ || PARM_INPUT);
ELSE
PUT SKIP LIST(‘パラメータなし’);
END MAIN_PGM;
2. なぜ「ベース変数」を使うのか
なぜ `BASED` 変数を使うのか。それは、メインフレームの限られたメモリリソースを効率的に使い、かつ「動的」なデータ長に対応するためだ。
大規模マイグレーションにおいて、この `PARM_PTR` を `ADDR()` 関数で細工し、CICSのCOMMAREA（共通領域）や、DB2の埋め込みSQLで取得した可変長データとマッピングさせる手法を多用する。これを安易に固定長で定義すると、データが短い場合に「パックデシマルの内部符号反転」のような、見た目では判別できない数値計算エラーを誘発する温床となる。
3. ABEND解析の最前線：ダンプが語る「真実」
もし、この `PARM_INPUT` へのアクセスで `0C4`（保護例外）が発生した場合、諸君は何を見るべきか。
1. レジスタの値: `PARM_PTR` が指すアドレスが、本当に有効なメモリ領域を指しているか。
2. JCLのEXEC PARM: `PARM=’…’` のクォーテーションの閉じ忘れにより、パラメータが期待値と全く異なる形で解釈されていないか。
3. コンパイラオプション: `TRAP(ON,SPIE)` が設定されているか。
特に、CICS環境下でこのコードを流用する場合、`OPTIONS(MAIN)` の扱いは非常に危険だ。CICSはメインプログラムの起動を制御するため、通常、トランザクションの起動パラメタは `DFHEIVAR` 等の通信領域を通じて渡される。`EXEC PARM` に依存した設計は、バッチとオンラインの共用ロジックにおいて最大の障壁となる。
4. マイグレーションに向けた提言
JavaやC#への移行を検討しているアーキテクト諸氏に言いたい。
現在のプログラムが、「ポインタ演算」や「BASED変数による構造体のオーバーレイ」を駆使している場合、単純なソースコード変換は破滅を意味する。
- パックデシマル(COMP-3): Java側で `BigDecimal` に変換する際、末尾の符号ニブル（C, D, F）の扱いをどう実装するか。
- 埋め込みSQL: DB2のホスト変数として定義された構造体が、メモリ上でどう配置されているか（アライメント問題）。
これらを理解せずに「動けばいい」というコード変換を行うと、本番稼働後の不可解なバグに数年単位で苦しむことになる。PL/Iの `OPTIONS(MAIN)` におけるPARM処理は、まさにその「ハードウェアとソフトウェアの境界線」を象徴する場所だ。
このコードがどのようなバイト列を期待しているのか。コンパイラのリストファイル（`LIST`オプション）を出力し、生成されたアセンブラコードと照らし合わせる。その泥臭い作業こそが、真のシステムアーキテクトへの唯一の道であると、私は確信している。
—
本日の教訓：
「ポインタを制する者は、メインフレームのラストマイルを制する」
パラメータの受け渡し一つ取っても、そこにはOSの設計思想が刻まれている。それを忘れた時、システムは静かに沈黙する。
