異言語呼出しの深淵：PL/Iから見るリンケージ規約と「見えざるメモリ」の制御術
IBMメインフレームの世界において、PL/Iはまさに「孤高の言語」です。CやJavaのような「予約語が厳格に定義された世界」とは異なり、PL/Iは予約語という概念をあえて排除しました。`IF`という変数名すら許容してしまうこの言語の柔軟性は、時に保守担当者を絶望の淵に追いやることもありますが、コンパイラを飼いならした者にとっては、これほど強力な武器はありません。
今回は、基幹システムのモダナイゼーションにおいても避けては通れない「外部モジュール呼出し（ASM/COBOL）」と、その背後で蠢くリンケージ規約の深淵について解説します。
—
1. 予約語なき世界の「ENTRY属性」とリンケージの鉄則
PL/Iには予約語がありません。そのため、コンパイラはコンテキスト（文脈）から識別子の意味を推論します。これは強力ですが、外部呼出しにおいては「型情報の不一致」が致命的なABEND（S0C4やS0C7）を招く主因となります。
他言語（ASMやCOBOL）を呼び出す際、必ず意識すべきは`ENTRY`属性によるインターフェースの明示です。特に重要なのが `OPTIONS` オプションの選択です。
1
/ COBOLサブルーチンを呼び出す際の標準的な定義例 /
DCL SUB_PROG ENTRY(
FIXED BIN(31), / 第一引数: 4バイト整数 /
CHAR(8) / 第二引数: 固定長文字列 /
) OPTIONS(COBOL); / COBOL規約に従いレジスタ管理を委譲 /
/ ここで重要なのは、引数の受け渡し規約を合わせること /
`OPTIONS(COBOL)`や`OPTIONS(ASM)`を付与することで、コンパイラはレジスタの退避復帰（Save Areaの処理）や、リンケージスタックの管理を相手側の規約に合わせます。これを怠ると、呼び出し先でレジスタが破壊され、呼び出し元に戻った瞬間にシステムが崩壊します。
2. BYADDR vs BYVALUE：ポインタが握る命運
マイグレーション時に最もバグを誘発するのが「引数の渡し方」です。PL/Iのデフォルトは `BYADDR`（アドレス渡し）ですが、C言語やモダンなAPIと連携する場合、`BYVALUE`（値渡し）が必須となります。
- BYADDR（デフォルト）: 変数のメモリ番地を渡します。COBOLの `BY REFERENCE` に相当します。
- BYVALUE: 変数の値をレジスタに直接ロードして渡します。
1
/ 値渡しによる効率的な通信 /
DCL CALL_ASM ENTRY(
FIXED BIN(31) BYVALUE, / 値そのものをレジスタ経由で渡す /
PTR BYADDR / メモリ上のアドレスを渡す（動的配列など） /
) OPTIONS(ASM);
【現場の知見】
特にパックデシマル（`DECIMAL FIXED`）を外部へ渡す際、内部表現の「符号ニブル」の扱いが各言語で異なることがあります。COBOLの `COMP-3` とPL/Iの内部表現は基本的には同一ですが、コンパイラオプションやプラットフォームの差異により、符号ビットが反転して解釈されるケースがあります。ダンプを解析する際は、該当アドレスを `DUMP` コマンドで追い、16進数レベルで符号ニブル（`C`なら正、`D`なら負）が期待通りか確認してください。
3. ポインタによる動的メモリ操作とエッジケース対策
PL/Iの真骨頂は、`BASED`変数と`POINTER`による自由自在なメモリ操作です。CICSオンライン処理において、GETMAINした領域をマップする際、この手法が不可欠となります。
1
DCL DATA_AREA CHAR(1024) BASED(P_AREA); / P_AREAポインタを基底にする /
DCL P_AREA PTR;
/ CICSのGETMAIN等で取得したアドレスを代入 /
P_AREA = ADDR(取得した領域の先頭);
/ あとは構造体のように扱う /
SUBSTR(DATA_AREA, 1, 10) = ‘HEADER’;
【アベンド対策の極意】
ここで発生する `S0C4（保護例外）` は、多くの場合「解放済みのポインタ参照」か「境界整列（Alignment）の不一致」です。特に `FIXED BIN(31)` 等を扱う際、アドレスが4バイト境界に整列されていないと、メインフレームのCPUアーキテクチャによっては性能劣化、あるいは例外が発生します。`ALIGNED` 属性を適切に付与し、コンパイラの最適化に頼りすぎない設計が、極限の信頼性を生みます。
4. 移行を見据えたアーキテクトへの提言
JavaやC#へのマイグレーションを担当する際、PL/Iのこうした「メモリ操作の柔軟性」をいかに抽象化するかが成功の鍵となります。
1. データ構造の平坦化: 構造体の中にある `UNION` や `DEFINED` によるメモリ共有は、そのままではモダン言語に移植できません。まずはデータレイアウトを整理し、型を厳格に分離することから始めてください。
2. SQL埋め込み処理の分離: `EXEC SQL` は、プリコンパイラが生成するDB2呼出しコードを含めて「ブラックボックス」化されています。これをDAO（Data Access Object）パターンへ移行する際は、動的SQLのバインド変数の型変換で必ずと言っていいほど精度落ちや符号問題が発生します。
PL/Iのコードを眺めていると、当時の先人たちが限られたメモリをいかに効率よく回そうとしたかという執念を感じます。その「歴史的な工夫」を理解せずして、単なる置換作業で移行を完遂することは不可能です。
システムアーキテクトとして、我々が守るべきは「コードの見た目」ではなく、その背後で流れる「ビットとバイトの整合性」です。次にダンプを覗くとき、そこにあるのは無機質な16進数ではなく、設計者の意志であるということを忘れないでください。
