現場の「地雷」を踏まないために：PL/IにおけるENTRY宣言とインターフェースの整合性
基幹システムの保守・運用、あるいはJavaやC#へのマイグレーション計画の最前線にいる諸君なら、一度は目にしたことがあるはずだ。「なぜか特定の条件下でだけ、変な値が返ってくる」「CICSのオンライン処理が突然S0C4で落ちる」。
その原因の多くは、コードのロジックそのものではなく、プロシージャ境界を跨ぐ際の「インターフェースの不整合」に潜んでいる。今日は、PL/Iにおいて最も軽視されがちだが、最も恐ろしい「ENTRY属性」の重要性について、現場の血肉となった知見を共有しよう。
—
ENTRY属性は「単なる気休め」ではない
PL/Iのコンパイラは、コンパイル単位が異なれば、呼び出し先が何者であるかを知る術を持たない。デフォルトのまま外部プロシージャを呼び出せば、コンパイラは「引数は妥当である」と性善説で動く。これが悲劇の始まりだ。
1
/ 呼び出し側の誤った実装例 /
/ ENTRY宣言を怠ると、コンパイラは引数の型チェックを放棄する /
DCL SUB_PROG ENTRY EXTERNAL;
DCL V_AMT FIXED BIN(31) INIT(100);
CALL SUB_PROG(V_AMT); / 呼び出し側はBIN(31)のつもり /
もし、呼び出し先の `SUB_PROG` が `FIXED DEC(15,2)` を期待していたらどうなるか。内部ではビット列の解釈が完全に食い違い、計算結果がゴミになるか、あるいは運が悪ければアベンドを免れて「正常な異常値」が本番データに書き込まれる。これを防ぐ唯一の防御壁が、明示的なENTRY宣言である。
型の不一致が引き起こす「見えない地雷」
特に恐ろしいのは、パックデシマル（FIXED DEC）の符号ビットが関与するケースだ。
メインフレームのパックデシマルは、末尾のニブルが符号（C/D/F等）を表す。もしENTRY宣言で引数の精度を誤って定義した場合、コンパイラはアライメントを無視してメモリを操作することがある。
1
/ 正しいENTRY宣言の作法 /
DCL SUB_PROG ENTRY(FIXED DEC(15,2) BYADDR) EXTERNAL;
`BYADDR`（デフォルトだが明示を推奨）を用いる場合、呼び出し側と呼び出し先でメモリレイアウトが一致していなければ、ポインタ経由で渡されたアドレス領域の「隣の変数」を破壊する。これが原因のS0C4やデータ破壊は、ダンプを取っても「なぜかスタックのここが書き換わっている」という不可解な状況しか残さない。
—
マイグレーションの視点：アーキテクチャの断絶をどう埋めるか
現在、多くの案件でPL/IからJava等へのリライトが進んでいるが、ここで最も問題になるのが「PL/I特有の暗黙の型変換」と「ENTRY属性による型チェックの甘さ」の温床である。
- 動的メモリ操作の危険性:
`BASED` 変数と `POINTER` を駆使した処理は、PL/Iの真骨頂だが、マイグレーション先（C#の `unsafe` やJavaの `ByteBuffer`）では、アライメントの概念が異なる。PL/Iは `ALIGNED` と `UNALIGNED` でメモリ配置を細かく制御できるが、これを他言語に移植する際は、必ず構造体のパディングを意識したパッキング定義を入れなければならない。
- DB2/CICSの境界条件:
埋め込みSQL（EXEC SQL）を使用している場合、ホスト変数の定義がENTRY宣言を跨ぐ際、プリコンパイラがどう解釈しているかを常に注意する必要がある。特に、`VARCHAR` 型の長さを保持するプレフィックス領域の取り扱いは、言語間変換で最もバグりやすいポイントだ。
—
実務でのトラブルシューティング：ダンプを読み解く鍵
もし、君たちの管理するシステムで原因不明のアベンドが頻発しているなら、まずは全ソースの `ENTRY` 宣言を総点検することをお勧めする。
1. コンパイラオプションの再確認: `AGGREGATE` や `LIST` オプションを有効にして、コンパイルリストの「Attribute Table」を確認せよ。ENTRY宣言のシグネチャが、実際の実装と完全に合致しているか？
2. ダンプ解析の定石: アベンド発生時のレジスタ（R1）を確認し、呼び出し先へ渡されたパラメタリストのアドレスを追え。渡されたアドレスにある値が、期待する型（パックデシマルなのか、バイナリなのか）と合致しているか、16進数でダンプを眺める。ここでパックデシマルの符号ビットが `F` 以外（例えば不正な `A` 等）になっていれば、それは呼び出し側からのメモリ破壊か、定義不一致の証左だ。
最後に：スペシャリストとしての矜持
PL/Iという言語は、非常に強力だが、同時に非常に無慈悲だ。プログラマを信じすぎるがゆえに、誤ったコードに対しても全力で実行しようとする。
次世代のシステムを構築する際、PL/Iのこうした「自由度」を、型安全な現代言語の「制約」にどう落とし込むか。それこそが、レガシー移行を担うアーキテクトに求められる真の技量だ。ENTRY属性を疎かにする者は、いつか必ずコードの迷宮で道に迷うことになる。
諸君、コードを書くときは常に「このインターフェースは、本当に契約通りか？」と自問自答してほしい。その疑念こそが、堅牢な基幹システムを支える唯一の基盤なのだから。
