こんにちは。メインフレームの世界へようこそ。
あなたがこれまでJavaやCOBOLで培ってきた経験は、この「PL/I」という広大な宇宙を旅するための素晴らしい羅針盤になります。PL/Iは1960年代に生まれた言語ですが、その設計思想は極めてモダンで、実は非常に合理的です。「難しそう」「古臭い」という先入観は、今日この瞬間、一旦ロッカーに預けてしまいましょう。
今回は、PL/Iプログラムの「入り口」であり、大規模開発の要となるPACKAGE（パッケージ）ブロックについて、現場の知見を交えて紐解いていきます。
—
1. PACKAGEって何者？：プログラムの「家」を整理する
Javaであればクラス、COBOLであればプログラム単位（ID DIVISIONなど）がその境界となりますよね。PL/Iにおいて、その役割を担うのが`PACKAGE`です。
かつてPL/Iが生まれた頃、プログラムは一つの大きな袋に詰め込まれていました。しかし、システムが巨大化するにつれ、「どこまでが外部から見えていいのか」「どこからが内部の秘密なのか」を制御する必要が出てきました。そこで登場したのが`PACKAGE`です。
イメージとしては、「一つのファイル（コンパイル単位）という名前の大きな家」を想像してください。その家の中に、たくさんの`PROCEDURE`（部屋）があるわけです。
1
/ ひとつのコンパイル単位（ソースファイル）の始まり /
MY_PROGRAM: PACKAGE EXPORTS(MAIN_PROC);
/ 内部だけで使いたい秘密の計算ロジック（外部からは見えません） /
SECRET_CALC: PROCEDURE(A, B) RETURNS(FIXED BIN(31));
RETURN(A + B);
END SECRET_CALC;
/ 外部（JCLなど）から呼び出されるメインの入り口 /
MAIN_PROC: PROCEDURE OPTIONS(MAIN);
DCL X FIXED BIN(31) INIT(10);
DCL Y FIXED BIN(31) INIT(20);
DCL RESULT FIXED BIN(31);
RESULT = SECRET_CALC(X, Y); / 内部の部屋を呼び出す /
PUT SKIP LIST(‘結果は: ‘ || RESULT);
END MAIN_PROC;
END MY_PROGRAM;
—
2. なぜPACKAGEを使うのか？：スコープという「見えない壁」
Javaの`private`や`public`を思い浮かべてみてください。`PACKAGE`を使う最大のメリットは、「外部に公開するインターフェース」と「内部の隠蔽」を明確に分けられることです。
- EXPORTS句の魔法: `PACKAGE EXPORTS(MAIN_PROC);` と書くことで、「このファイルの外から呼んでいいのは `MAIN_PROC` だけですよ」と宣言しています。`SECRET_CALC` はどれだけ頑張っても外からは見えません。
- 名前衝突の回避: 大規模開発では、似たような名前のサブルーチンが乱立しがちです。「あ、その名前のサブルーチンは別のチームも使ってるよ！」という悲劇を、このスコープ制御が未然に防いでくれるのです。
—
3. OPTIONS(MAIN) ： 「ここがスタート地点だ」と告げる合図
`PROCEDURE`の末尾に付く `OPTIONS(MAIN)` は、OS（メインフレームならz/OS）に対して、「プログラムを実行するときは、ここから動かしてくれ」と伝えるための「起動スイッチ」です。
Javaでいうところの `public static void main(String[] args)` と全く同じ役割ですね。PL/Iでは、一つのパッケージの中に複数のPROCEDUREを書けますが、`OPTIONS(MAIN)`が付いているのは一つだけにするのが鉄則です。
—
4. 初学者がつまずきやすい「データ宣言」の入り口
PL/Iが少し奇妙に見えるのは、`DCL`（DECLARE）というキーワードで全てを宣言するからかもしれません。
- FIXED BIN(31): 31ビットの整数型です。Javaの `int` と同じ感覚で使えます。
- CHAR(10): 10文字の固定長文字列。
- INIT(…): 初期値設定。
「なぜそんなに細かい指定が必要なの？」と思うかもしれませんが、メインフレームの世界では、「メモリを1バイト単位で正確に管理すること」が、システムの安定稼働とコスト削減に直結するからです。この厳密さが、実はバグを減らす強力な武器になります。
—
最後に：怖がらなくて大丈夫です
PL/Iは、型システムが非常に強力で、コンパイラが「お節介」なほど親切にエラーを指摘してくれます。Javaの柔軟性やCOBOLの堅牢さを、いいとこ取りしたような言語だと感じていただけるはずです。
もし実務で「パッケージの範囲外から変数が参照できない！」と悩んだら、まずは`PACKAGE`の`EXPORTS`定義を見直してみてください。多くの場合、答えはそこに隠れています。
一つずつ、ゆっくりと紐解いていきましょう。あなたのメインフレーム・エンジニアとしてのキャリアが、ここからより深く、実りあるものになることを応援しています！
それでは、また次回の記事でお会いしましょう。質問や「こんなコードが知りたい」というリクエストがあれば、いつでもコメント欄で教えてくださいね。
コメント