メインフレームの深淵：EXTERNAL属性によるグローバル変数共有と、その背後に潜む「魔」
諸君、今日もどこかで制御ブロックの海を泳いでいることだろう。メインフレームの移行現場において、最も設計者の頭を悩ませ、かつ最もバグの温床となるのが、モジュール間におけるデータ共有の作法だ。
特に、`EXTERNAL`属性。これは強力な武器だが、安易に使えばシステム全体を「追跡不可能なスパゲッティ」へと変貌させる毒でもある。今日は、PL/Iにおけるこの属性の挙動と、現代の移行プロジェクトにおいてこの設計をどう紐解くべきか、現場の知見を交えて語ろう。
—
1. EXTERNAL属性の真実：リンケージエディタの役割
PL/Iにおいて`EXTERNAL`を指定した変数は、コンパイル単位（ソースファイル）を超えて、リンケージエディタ（バインダ）によって同一の記憶領域を参照するように解決される。
/i
/ モジュールA：グローバル変数の定義元 /
DCL GLOBAL_DATA_AREA CHAR(256) EXTERNAL STATIC;
/ モジュールB：参照側 /
DCL GLOBAL_DATA_AREA CHAR(256) EXTERNAL STATIC;
ここで重要なのは、「コンパイラは型チェックを跨げない」という事実だ。モジュールAで`FIXED BIN(31)`と定義し、モジュールBで誤って`CHAR(4)`と定義しても、コンパイルは平然と通る。バインダは単に「名前が同じシンボル」のアドレスを合わせるだけで、データ構造の整合性など関知しないからだ。
移行時、特にJava等のオブジェクト指向言語へ移植する際、この「型を無視したメモリ共有」が最大の障壁となる。移行先でこれをそのまま`static`変数として実装するのは自殺行為だ。まずはこの共有領域を「共通データ領域」という明確な名前空間（例えばJavaならシングルトンやコンテキストオブジェクト）にカプセル化する設計から始めるべきだ。
—
2. ポインタとベース変数によるメモリ操作の危険領域
`EXTERNAL`変数にポインタを絡めると、問題は指数関数的に複雑化する。
/i
/ ポインタを用いた動的アクセス例 /
DCL PTR_TO_DATA PTR;
DCL BASED_DATA CHAR(100) BASED(PTR_TO_DATA);
/ 外部定義された領域を特定のアドレスとして扱う /
PTR_TO_DATA = ADDR(EXTERNAL_BUFFER);
/ この時点で BASED_DATA は EXTERNAL_BUFFER の別名となる /
BASED_DATA = ‘INITIALIZE’;
この手法は、CICSの`GETMAIN`で取得した共有メモリ領域を扱う際によく使われる。しかし、ここで最も恐ろしいのは、コンパイラ最適化による再順序付け（Reordering）だ。最適化レベルを上げると、コンパイラは「この変数はここで変更されない」と勝手に判断し、レジスタにキャッシュしてメモリの更新を反映させないことがある。
もしマルチスレッド環境や非同期タスク間でこの領域を共有しているなら、必ず`VOLATILE`属性を付与しておくこと。これがないと、ダンプを眺めても「メモリ上は正しい値なのに、プログラムは古い値を見ている」という、悪夢のようなデバッグに数日を溶かすことになる。
—
3. 実践：ダンプ解析と「符号反転」の罠
基幹バッチでよくあるトラブルが、パックデシマル（`PIC S9(7)V99 COMP-3`）の内部表現における符号反転だ。
/i
/ パックデシマル内部表現の意図的な操作 /
DCL PACKED_VAL PIC S9(7)V99 COMP-3;
/
- 稀に、IBMのメインフレームでは符号（最下位ニブル）が
- 0x0C(正)ではなく0x0D(負)になることがある。
- 外部データ連携時にこれが混入すると、計算結果が逆転する。
/
このような不整合が発生した際、ダンプリストから該当変数を特定するには、単に値を読むのではなく、「HEXダンプの末尾4ビット」を凝視する癖をつけろ。アベンド発生時、`CEE3204S`のような例外が飛んできたら、まずはデータが定義通りか、それとも外から来た不正なバイト列が悪さをしているかを疑うのが、百戦錬磨のアーキテクトだ。
—
4. 移行スペシャリストへの提言
JavaやC#への移行にあたり、`EXTERNAL`属性のコードをそのまま動的にマッピングしようと考えるな。それはレガシーの呪いを次世代に引き継ぐだけだ。
1. データ構造の可視化: 共有されている変数群を、DBテーブルや共有メモリ（Redisやインメモリキャッシュ）へ疎結合化せよ。
2. 型安全の強制: 共有データには必ず専用のクラスや構造体を用意し、直接的なアドレス操作を排除せよ。
3. オンライン・バッチの境界確認: CICSで使われている`COMMAREA`や`TSQ`（一時記憶域）と、バッチの`EXTERNAL`変数が混在している箇所は、移行の優先順位を最上位に置け。
コードは単なる命令の羅列ではない。そこには、数十年分のビジネスロジックと、先人たちが戦ってきた「妥協」の跡が刻まれている。それを解き明かすのが我々の仕事だ。
次回の記事では、`ON-UNIT`を使った例外ハンドリングと、CICSにおけるトランザクション・バックアウトの深淵について解説する。……メインフレームの静寂な熱狂を、また楽しもう。
