【入門編】ENTRY属性とプロシージャ呼び出し規約 – PL/Iの基本構文とデータ制御実践ガイド

「予約語なし」の衝撃！PL/IにおけるENTRY属性と呼び出し規約の深淵へ

皆さん、こんにちは。メインフレームの世界へようこそ。
JavaやCOBOLから来たエンジニアの皆さんが、最初にPL/Iのコードを見たとき、必ずと言っていいほど直面するのが「あれ？この言語、予約語がないの？」という驚きです。

今日は、そんなPL/Iの自由奔放で少しミステリアスな世界を、メインフレームの現場で生き残るための「ENTRY属性」と「呼び出し規約」という切り口で紐解いていきたいと思います。

—

まず、初心者が一番驚くのがここです。PL/Iには、Javaの`public`や`static`のような「絶対に使ってはいけない予約語」が存在しません。

例えば、`IF`や`THEN`、`DO`という言葉さえも、変数名として使えてしまうのです。
1
/ PL/Iの怪奇：こんな変数宣言も通ってしまいます /
DCL IF FIXED BIN(31); / IFという名前の変数 /
DCL THEN CHAR(10); / THENという名前の変数 /

IF = 10;
THEN = ‘SUCCESS’;

「これ、コンパイラはどうやって判断しているの？」と不安になりますよね。実は、PL/Iコンパイラは「文脈（コンテキスト）」を非常に賢く読み取ります。後ろに続く記号や構造を見て、「ああ、これは制御文じゃなくて変数だな」と判断しているのです。

この「自由さ」は、時にバグの温床にもなりますが、PL/Iの歴史が持つ「何でもありの柔軟性」を象徴する仕様です。

—

さて、本題の「プロシージャ呼び出し」です。メインフレームのバッチ処理では、数百のモジュールを連結して一つのシステムを動かします。その際、他のプログラムを呼び出すための「窓口」となるのが`ENTRY`属性です。

他の言語で言う「インターフェース宣言」に近いのですが、ここで重要なのが「どうやってデータを渡すか」というルールです。

メインフレームのプログラミングにおいて、ここを理解しているかどうかで、メモリ破壊という「悪夢」に遭遇する確率が激減します。

現場では、「大きなデータ（配列や構造体）はBYADDRで、小さなフラグやカウンタはBYVALUEで」というのが鉄則です。

—

実際のコードを見てみましょう。外部プロシージャ `CALC_PROC` を呼び出す例です。

1
/ 呼び出し元プログラム /
MAIN_PGM: PROC OPTIONS(MAIN);

/ 外部プロシージャへの窓口を宣言 /
/ 1つ目はアドレス渡し、2つ目は値渡しと明示する /
DCL CALC_PROC ENTRY(PTR, FIXED BIN(31) BYVALUE);

DCL DATA_AREA CHAR(100);
DCL COUNT FIXED BIN(31) INIT(5);

/ ADDR関数でメモリ上の場所を明示的に渡す /
CALL CALC_PROC(ADDR(DATA_AREA), COUNT);

PUT SKIP LIST(‘処理が完了しました’);

END MAIN_PGM;

メインフレームのリンケージエディタ（モジュールを結合する職人）は、この`ENTRY`属性の定義を見て、呼び出し元と呼び出し先の「引数の型」が一致しているかを厳密にチェックします。もしここが食い違っていると、実行時にメモリの境界を越えてしまい、システムが異常終了（アベンド）することになります。

—

PL/Iの移行や保守を行う際、最も恐ろしいのは「暗黙の型変換」です。
PL/Iは気を利かせて、勝手に型を変換して計算を完遂しようとします。これは便利に見えますが、基幹システムにおいては「意図しない精度低下」を引き起こす最大の敵です。

PL/Iは確かに古く、独特のクセがあります。しかし、それはメインフレームという「超巨大で堅牢な仕組み」を支えるために磨き上げられてきた機能美です。

「予約語がない」という自由は、裏を返せば「書き手の意図を最大限尊重する」という懐の深さでもあります。一つひとつの宣言の意味を紐解いていけば、必ずPL/Iという言語の頼もしさに気づくはずです。

もし現場で「謎の挙動」に遭遇したら、まずは`ENTRY`属性と`BYADDR`の挙動を疑ってみてください。そこには必ず、答えがありますよ。

それでは、次回のメインフレーム技術解説でお会いしましょう！