こんにちは！メインフレームの世界へようこそ。
COBOLの「堅牢さ」やJavaの「オブジェクト指向」に慣れ親しんだ皆さんが、次にPL/Iという言語に出会ったとき、最初に抱く感想はたいてい「自由すぎて怖い」というものです。でも安心してください。PL/Iは、型システムさえ理解すれば、これほどまでにエンジニアの意図を汲み取ってくれるパワフルな言語はありません。
今回は、PL/Iにおいて「お作法」として最も重要でありながら、初心者が一番泣きを見やすい「ENTRY属性と外部プロシージャのインターフェース定義」について、現場の視点から紐解いていきます。
—
なぜ「ENTRY宣言」をサボってはいけないのか？
JavaやC#では、別のクラスや関数を呼び出すとき、コンパイラが「引数の型や数は合っているか？」を厳格にチェックしてくれますよね。しかし、PL/Iの古いコードベースでは、「何も宣言せずに外部プロシージャを呼ぶ」という書き方ができてしまいます。
これが、メインフレーム現場における「真夜中の異常終了（ABEND）」の最大の温床です。
悪い例：宣言を省略すると何が起きるか
例えば、`CALC_TOTAL` という計算用プロシージャがあるとして、こんな風に呼ぶとします。
1
/ 宣言を省略！コンパイラは「まあ、適当に動くやろ」と放置する /
CALL CALC_TOTAL(WK_PRICE, WK_TAX);
もし `CALC_TOTAL` 側が「最初の引数は整数(FIXED BIN)だ」と思って待ち構えているのに、メイン側から「浮動小数点(FLOAT)」を投げつけたらどうなるでしょう？ コンパイラは文句を言いません。しかし、実行時にメモリ上のビット列を無理やり解釈しようとして、計算結果が化けるか、最悪の場合はメモリアクセス違反でプログラムが吹き飛びます。
—
ENTRY属性で「約束事」を明文化しよう
PL/Iでは、呼び出すプロシージャの入り口（ENTRY）をあらかじめ教えてあげることで、コンパイラに「お目付け役」になってもらいます。これが `ENTRY` 属性です。
正しい書き方の例
1
/ 外部プロシージャ CALC_TOTAL のインターフェースを宣言する /
DCL CALC_TOTAL ENTRY(FIXED BIN(31), FIXED BIN(31)) EXTERNAL;
/ これでコンパイラが「型が違うよ！」と指摘してくれるようになる /
DCL WK_PRICE FIXED BIN(31) INIT(1000);
DCL WK_TAX FIXED BIN(31) INIT(80);
CALL CALC_TOTAL(WK_PRICE, WK_TAX);
この `DCL (Declare)` があるだけで、コンパイラは「引数が2つで、両方とも32ビットの整数型であること」を強制します。もし引数の数が合わなければ、コンパイル時にエラーを吐いて止めてくれます。「動いてから悩む」のではなく「動く前に直す」。これこそが、メインフレーム開発の鉄則です。
—
PL/Iの「奇妙な属性」との付き合い方
初心者が一番戸惑うのは、PL/Iのデータ型には「メモリの配置」まで指定できる属性があることでしょう。
- FIXED BIN(31): 32ビットの整数。Javaのintに近いですが、PL/Iでは「符号付き・なし」やビット長を細かく制御できます。
- CHAR(10): 固定長文字列。COBOLのPIC X(10)と同じ感覚でOKです。
- OPTIONS(MAIN): プログラムの「入り口（エントリーポイント）」であることを宣言します。
ここで注意点。`ENTRY` を書く際、引数に `BYADDR` や `BYVALUE` という属性が付くことがあります。
- BYADDR: データの「場所（アドレス）」を渡す（デフォルト）。
- BYVALUE: データの「値そのもの」を渡す（C言語の関数に近い挙動）。
「あれ、なんで値が変わらないんだ？」と悩んだら、この引き渡し方の属性がズレていることが多いです。まずは「デフォルトはアドレス渡し（参照渡し）」ということを覚えておいてください。
—
現場のエンジニアから最後に伝えたいこと
PL/Iは、メモリの配置や型定義に対して非常に誠実な言語です。コンパイラが冷たいのは、あなたのプログラムを「壊れないように守ろうとしているから」に他なりません。
1. 他言語の常識を持ち込まない: 「なんとなく動く」を期待せず、必ず `DCL` で型を明示しましょう。
2. ENTRY宣言は「契約書」: 呼び出し元と呼び出し先の約束事です。これをサボると、デバッグという名の泥沼が待っています。
3. コンパイラの警告を無視しない: PL/Iのコンパイラが出す `W`（Warning）は、現場では「エラー」と同義です。
最初は呪文のように見える構文も、一つずつ紐解いていけば、これほど論理的で美しい言語はありません。メインフレームの深淵へ、自信を持って一歩を踏み出してください。
もし「どうしても型の不一致が消えない！」といったトラブルがあれば、またいつでも相談してくださいね。コードの裏側にある「なぜ？」を一緒に解き明かしましょう。
