汎用機の深淵：PARM引数とVARYING属性の「正しい」ハンドリング
基幹システムの現場において、JCLの`PARM`パラメータはバッチ処理の制御権を握る重要なインターフェースだ。しかし、この数バイトの文字列が、時にシステム全体を揺るがすアベンド（ABEND）の火種となることを、どれほどのエンジニアが意識しているだろうか。
今回は、PL/Iにおける`PARM`の受け取りと、`CHARACTER VARYING`属性を駆使した「堅牢な文字列ハンドリング」について、コンパイラの実装レベルまで掘り下げて解説する。
1. PARM受け取りの「罠」とVARYINGの正体
PL/Iの`MAIN`プロシージャでパラメータを受け取る際、安易に`CHARACTER(100)`のような固定長を指定していないだろうか？ 汎用機のコンパイラは、`PARM`で渡されたデータを、先頭2バイトに長さ情報（Halfword）を持つ「PL/I形式の可変長文字列」として解釈する。
これを安全かつスマートに扱うには、`VARYING`属性の活用が不可欠だ。
1
/ MAINプロシージャでのパラメータ定義 /
MAIN_PROC: PROC(PARM_IN) OPTIONS(MAIN);
/
- VARYING属性により、内部的に長さ情報とデータ領域を分離して管理。
- コンパイラは自動的に先頭2バイトの長さ情報を解釈する。
/
DCL PARM_IN CHAR(100) VARYING;
/
- 万が一、JCL側で定義した長さとプログラム側の受け取り長が不一致の場合、
- 固定長定義だとゴミデータやメモリ破壊の原因になるが、
- VARYINGであれば境界チェックが適正に機能する。
/
IF LENGTH(PARM_IN) > 0 THEN DO;
/ ここに制御ロジック /
END;
END MAIN_PROC;
2. ポインタとベース変数によるメモリ操作の極意
マイグレーション案件でJavaやC#へ移行する際、最も障壁となるのがPL/I特有の「ポインタによる動的メモリ操作」だ。特に`BASED`変数を使ってストレージ上の構造体を直接マッピングする手法は、性能面で極めて効率的だが、一歩間違えればS0C4（Protection Exception）の餌食となる。
もし、`PARM`から受け取った文字列を解析し、特定の制御構造体にマッピングするならば、`ADDR`関数と`BASED`変数を組み合わせるのがプロの流儀だ。
1
DCL PARM_PTR PTR;
DCL 1 CTL_STRUCT BASED(PARM_PTR),
2 LEN FIXED BIN(15),
2 DATA_VAL CHAR(8);
/ 動的にメモリをマッピングし、バッファオーバーランを回避する /
PARM_PTR = ADDR(PARM_IN);
3. マイグレーションを成功させる「ダンプ解析」の視点
移行設計において、最も恐ろしいのは「レガシー環境では動いていたが、新環境でNULLの扱いが変わりアベンドする」というケースだ。特に`PACKED DECIMAL`と`CHAR`の変換ミスや、内部符号反転（F/C/Dの混在）によるデータ例外（S0C7）は、単なるコード変換では見抜けない。
私がコンサルティングに入る際、必ず確認するのがコンパイラオプションの`CHECK`と`SUBSCRIPTRANGE`だ。
- CHECK: 配列境界や数値変換の妥当性を厳格にチェックする。
- SUBSCRIPTRANGE: 配列の添字範囲外アクセスを検出し、即座にダンプを吐かせる。
これらは本番稼働時にはパフォーマンス上の理由でオフにするのが定石だが、「移行検証フェーズでは絶対にオンにする」のが鉄則だ。これなしでダンプを解析しようとするのは、暗闇の中で宝探しをするようなものだ。
4. エッジケースへの備え：DB2とCICS
CICSオンラインやDB2埋め込みSQLで`VARYING`変数を使う場合、`VARCHAR`列とのマッピングに注意が必要だ。SQLのホスト変数として渡す際、PL/Iの`VARYING`変数は、先頭2バイトの長さ情報を含んだデータとしてDB2エンジンに認識される。
もし、Javaへの移行を睨んでいるのであれば、この「長さ＋データ」というバイナリ構造を、移行先でどのようなクラスとして再現するか（例えば`String`ではなく、`byte[]`をラップした専用の構造体クラスにするなど）を、現時点で設計レベルで定義しておく必要がある。
結び：技術の本質を見極める
PL/Iは、極めて厳格でありながら、同時にメモリを自由に操る力を持った言語だ。現代の高級言語に慣れきった世代には「古い言語」と映るかもしれないが、そのメモリ管理の思想には、計算機の基本動作が凝縮されている。
移行作業とは、単なるコードの書き換えではない。そのプログラムが「なぜそのように書かれたのか」という設計意図を読み解き、現代のアーキテクチャへと昇華させる作業だ。
もし貴方のプロジェクトでS0C4やS0C7の亡霊に悩まされているなら、まずは`PARM`の定義と、変数のメモリ配置を今一度見直してほしい。答えは必ず、その「メモリの境界線」に落ちているはずだ。
