PL/Iの「予約語なき世界」と、ENTRY属性が握るシステム運命の鍵
メインフレームの心臓部で稼働し続けるPL/Iのコードを眺めていると、時折、現代の言語にはない特異な「自由」を感じることがある。その筆頭が「予約語を持たない」という設計思想だ。
若い世代のエンジニアは「IFが変数名に使えてしまう」ことに戦慄するが、これは単なる言語の不備ではない。PL/Iは文脈によって識別子の意味を決定する。この「コンテキスト依存の柔軟性」こそが、数十年前に書かれたコードを現代のコンパイラでも（設定次第で）コンパイル可能にしている一因だ。しかし、この自由は、外部プロシージャとの境界線において、しばしば「ABEND（異常終了）」という冷徹な回答となって我々に牙を剥く。
今回は、移行プロジェクトの現場で最もハマりやすい「ENTRY属性」と「リンケージ規約」の深淵に切り込む。
—
1. ENTRY属性の「静かなる嘘」とリンケージの不整合
外部プロシージャを呼び出す際、PL/Iでは`DECLARE`文で`ENTRY`属性を定義する。ここでの指定が、実体とわずかでも食い違った瞬間に、OS（z/OS）は慈悲もなくメモリアクセス違反を投げる。
特に危険なのが、デフォルトの引数渡し規約だ。PL/Iはデフォルトで`BYADDR`（アドレス渡し）を選択するが、C言語や現代の言語とのインターフェースにおいては、これが致命傷になる。
/i
/ 外部モジュール呼び出し定義の例 /
DCL EXT_MOD ENTRY(
FIXED BIN(31) BYADDR, / デフォルト：アドレス渡し /
CHAR(8) BYVALUE / 明示的な値渡し /
) EXTERNAL;
/
- ここで重要なのは「BYADDR」が暗黙的に適用される点だ。
- Java等へマイグレーションする際、この「アドレス渡し」の期待値を
- 「値渡し」と誤解して設計すると、ポインタ経由でメモリを破壊し、
- 数時間後のバッチ処理でS0C4が発生するという悪夢を見る。
/
2. ポインタとベース変数によるメモリ操作の「禁じ手」
PL/Iの`BASED`変数は、特定のメモリアドレスを構造体としてマッピングする強力な機能だ。しかし、これは「型安全性」という現代的な安全装置を完全に無効化する。
特に、DB2のSQLDA（SQL Descriptor Area）を扱う際や、CICSの通信領域（COMMAREA）をパースする際にこの機能を使う場合、アライメント（境界調整）には細心の注意が必要だ。
/i
DCL MY_PTR PTR;
DCL MY_BUFFER CHAR(100) BASED(MY_PTR);
DCL 1 MY_STRUCT BASED(MY_PTR),
5 FIELD_A FIXED BIN(31),
5 FIELD_B CHAR(96);
/
- 構造体の境界調整に失敗すると、フィールドのオフセットがズレる。
- 特に「パックデシマル(FIXED DEC)」の内部符号（CやDなど）を
- 読み取る際、バイト境界を跨ぐとS0C7（データ例外）が待っている。
/
3. パックデシマルの罠：内部表現と符号反転
レガシー移行で最も頭が痛いのが、EBCDIC環境で長年蓄積されたパックデシマルデータの扱いだ。PL/Iの`FIXED DEC`は、メモリ上ではニブル単位で詰め込まれている。
もし移行先がJava/C#であれば、これらを`BigDecimal`に変換する際、`0x0F`（正）や`0x0C`（正）、`0x0D`（負）といった符号の扱いで計算結果が狂う。現場で最も多いトラブルは、「COBOL/PL/I側で定義されていた符号なしパック値が、移行先のロジックで予期せぬ負数として解釈される」というケースだ。
4. コンパイラ最適化とダンプ解析の心得
`OPTIMIZE(2)`以上の最適化をかけると、コンパイラは「未使用」と判断した変数をレジスタに保持し、メモリ上の値を更新しなくなる。これに気づかず、ダンプを覗いて「なぜメモリの値が書き換わっていないのか？」と悩むのは、アーキテクトとしては初歩的な過ちだ。
- デバッグの極意: 本番障害調査でダンプを解析する際は、まず`CEE3DMP`の出力を読み解き、レジスタ（R13等のSave Area）を追う。PL/Iのスタックフレーム構造を理解していれば、呼び出し元プロシージャのローカル変数がどこにあるかは一目瞭然だ。
アーキテクトからの提言
PL/IからJava/C#等への移行を成功させる鍵は、「コードの直訳」ではなく「メモリレイアウトの再定義」にある。
1. ENTRY属性の徹底的な型定義: すべての外部呼び出しに`BYVALUE`/`BYADDR`を明示せよ。
2. アライメントの統一: `ALIGNED`属性を明示的に付与し、コンパイラの最適化による勝手なパディングを排除する癖をつけよ。
3. インターフェースの抽象化: CICS等のオンライン処理では、通信領域をそのまま渡すのではなく、一度DTO（Data Transfer Object）へ変換するレイヤーを挟む設計にすべきだ。
PL/Iは、書き手を選ばない言語ではない。しかし、その挙動を深く理解し、コンパイラの「意図」を読み解ける者にとっては、これほどまでに信頼性が高く、緻密な制御が可能な言語も他にない。レガシーシステムの移行は、単なる言語置換ではない。それは、過去40年間に蓄積された「メインフレームの知恵」を、現代的なアーキテクチャへと昇華させる儀式なのだ。
さあ、ダンプリストを手に、もう一度コードの深淵へ潜ろうではないか。
