PL/Iの「PACKAGE」という境界線：大規模マイグレーションにおけるスコープ制御の深淵
メインフレームの現場で長年生き抜いてきた諸君なら、一度は目にしたことがあるはずだ。数万行に及ぶ巨大なソースコード。その先頭に鎮座する `PACKAGE` ステートメント。単なるコンパイル単位の箱だと侮ってはいけない。これは、あなたの書いたコードが「システムという巨大な海」の中でどう振る舞うかを定義する、最初の防波堤なのだ。
今日は、PL/Iの `PACKAGE` ブロックが持つスコープ制御の妙と、それが現代のマイグレーションプロジェクトにおいてどのような「技術的負債」あるいは「資産」となり得るかについて、深掘りしていこう。
—
1. PACKAGEの真実：可視性の境界線を制御せよ
PL/Iにおける `PACKAGE` は、単に複数の `PROCEDURE` をまとめるコンテナではない。最も重要なのは、`EXTERNAL` 属性と `INTERNAL` 属性の境界線だ。
/i
/ パッケージ定義：この外部インターフェースがシステム全体の安定性を左右する /
MY_BATCH_MODULE: PACKAGE EXPORTS(MAIN_PROC);
/ プライベートなヘルパー。外部から隠蔽することで名前衝突を防ぐ /
INTERNAL_PROC: PROCEDURE;
/ ここはパッケージ外からは絶対に見えない。安全地帯だ /
END INTERNAL_PROC;
/ 公開されるメインエントリポイント /
MAIN_PROC: PROCEDURE OPTIONS(MAIN);
DCL X FIXED BIN(31) INIT(0);
CALL INTERNAL_PROC;
END MAIN_PROC;
END MY_BATCH_MODULE;
なぜこれが重要か？JavaやC#への移行を考えてみればいい。PL/Iの `INTERNAL` プロシージャは、オブジェクト指向言語でいうところの `private` メソッドだ。しかし、PL/Iの古いコードベースでは、何でもかんでも `EXTERNAL` にして、リンカ（HEWL/Binder）のシンボルテーブルを汚染しているケースが散見される。
マイグレーション時にこの「隠蔽」を正しく解釈しなければ、移行先で予期せぬ名前解決エラー（Unresolved External Symbol）や、誤ったメソッド呼び出しによるアベンドの嵐に見舞われることになる。
—
2. 動的メモリとポインタ：最適化の罠
基幹バッチで最も恐ろしいのは、`BASED` 変数と `POINTER` を駆使したメモリ操作だ。特に `PACKAGE` 内で共有されるデータ構造をポインタで受け渡す際、コンパイラの最適化（`OPTIMIZE(2)` や `(3)`）が牙を剥くことがある。
/i
DCL P POINTER;
DCL MY_BUFFER CHAR(80) BASED(P);
/ コンパイラ最適化が有効な場合、Pが指す先の値をレジスタにキャッシュする挙動がある /
/ 外部から非同期にメモリが書き換わったとしても、キャッシュされた値が使われるリスクだ /
ここで重要なのは、`VOLATILE` 属性を正しく付与することだ。特にCICS環境でストレージを共有している場合、この指定を怠ると、特定のタイミングでだけ「パックデシマルの内部符号が反転しているように見える」といった、追跡困難な怪奇現象を引き起こす。ダンプを解析して、「なぜ値が変わっていないのに計算結果が違うのか」と夜通し悩む諸君、まずはこの `VOLATILE` の付与を疑え。
—
3. 埋め込みSQLとCICS：境界線を越えるリスク
`PACKAGE` を超えてDB2を呼び出す際、あるいはCICSの `EXEC CICS` 命令を叩く際、最も注意すべきは「静的SQLのバインド」だ。
パッケージ単位でプリコンパイルを行う際、`DCL` されたホスト変数（`FIXED DEC` など）の精度が正しくDB2の列定義と合致しているか？もし `PACKAGE` 内で共通変数として定義されたホスト変数が、別のプロシージャで異なる精度で再定義されているような「魔境」があったら、マイグレーション以前に即刻コードの断捨離が必要だ。
現場の教訓：
- パックデシマルの符号問題: PL/Iの `FIXED DEC` は、内部形式で `X’F’` や `X’C’` を符号として持つ。Javaへの移行時、これを単なる数値型として扱うと、符号ビットの解釈で必ずコケる。`BigDecimal` の変換ルーチンには、必ずこの「汎用機の符号仕様」をハードコーディングすること。
- ダンプ解析の極意: `PACKAGE` を使用している場合、異常終了時の `CEE3250C` などのメッセージで、どのシンボルがどのスコープにあるかを特定するために、必ず `LIST(ON)` でコンパイルリストを出力しておくこと。コンパイラ最適化で変数が消滅している場合、`OFFSET` からソース行を逆算する能力が、アーキテクトとしての生命線になる。
—
結びに：レガシーは「過去」ではなく「現在」の資産である
PL/Iの `PACKAGE` 構造を理解することは、単なる構文の習得ではない。それは、IBMメインフレームが数十年にわたって培ってきた「メモリ管理の厳格さ」と「名前空間の秩序」を理解することに他ならない。
移行先のJavaやC#がどれほどモダンであっても、この「厳格さ」を無視すれば、バッチの信頼性は崩れ去る。コードを一行修正する前に、まずは `PACKAGE` の境界線を見つめ直してほしい。そこに、システムの設計思想が全て刻まれているはずだから。
もし、今まさに移行の障壁に突き当たっているなら、いつでもここへ戻ってきなさい。我々アーキテクトには、コンパイラが吐き出す警告メッセージ一つひとつに、先人たちの意図を読み解く義務があるのだから。
コメント