PL/I構造体の深淵：レベル番号、メモリレイアウト、そしてマイグレーションの罠
基幹システムの心臓部で今なお脈動し続けるPL/I。特に構造体（Structure）の定義は、COBOLのそれとは一線を画す柔軟性と、裏を返せば「理解なき実装は即座にABENDを招く」という危うさを孕んでいます。
今日は、PL/Iにおける構造体定義の真髄と、それが現代的な言語へのマイグレーションにおいてどのような地雷原となるのか、アーキテクトの視点で紐解いていきます。
—
1. 構造体階層とメモリレイアウトの「暗黙の掟」
PL/Iの構造体は、1から255までのレベル番号で階層を定義します。COBOLの01〜77/88といった単純な階層とは異なり、PL/Iはアラインメント（境界調整）の概念がコンパイラオプションやプラットフォーム（z/OSか、あるいは他環境か）に強く依存します。
コード例：構造体の定義とLIKE属性の活用
1
/ 構造体の定義とLIKE属性による再利用 /
DCL 1 EMP_REC,
2 EMP_ID CHAR(8),
2 EMP_INFO,
3 DEPT_CODE CHAR(4),
3 JOIN_DATE CHAR(8),
2 SALARY_DATA,
3 BASE_PAY FIXED DEC(9, 0),
3 BONUS FIXED DEC(9, 0);
/ LIKE属性で定義をコピーしつつ、メモリレイアウトを維持 /
DCL 1 WORK_EMP_REC LIKE EMP_REC;
ここで重要なのは、`LIKE`属性が単なるコピーではなく、「コンパイル時にメモリレイアウトまで完全に同一の型として複製する」という点です。マイグレーションにおいて、この構造をJavaのPOJOやC#のstructにマッピングする際、パディング（埋め草）のバイト数を無視すると、バイナリデータ入出力で即座にデータ破壊が発生します。
—
2. アベンド（ABEND）を回避するポインタと動的メモリ操作
PL/Iの真骨頂は、`BASED`変数とポインタを用いた直接的なメモリ操作です。特にCICSオンライン処理では、通信領域（DFHCOMMAREA）を構造体でオーバーレイする際、オフセット計算を誤ると`S0C4`（保護例外）の餌食になります。
ベース変数を用いた動的バッファ操作
1
DCL P_BUFFER PTR;
DCL BASED_REC CHAR(1024) BASED(P_BUFFER);
/ 外部から取得したアドレスをポインタに設定 /
P_BUFFER = ADDRESS_FROM_CICS;
/ ポインタ経由で構造体をマップして参照 /
/ この時、アラインメントが一致していないとS0C4が発生する /
DCL 1 MAP_REC BASED(P_BUFFER),
2 FIELD_A CHAR(10),
2 FIELD_B FIXED BIN(31);
現場の知見： コンパイラオプションで `ALIGNED` を指定している場合、メンバー間には意図しないパディングが挿入されます。マイグレーション先の言語で構造体を定義する際は、`UNALIGNED`属性相当の詰め込みを意識しなければ、データ転送時のオフセットが一切合わないという悪夢を見ることになります。
—
3. パックデシマルの「符号反転バグ」との戦い
IBMメインフレームにおいて最も忌々しいバグの一つが、パックデシマル（`FIXED DEC`）の符号部（Zone/Digit）の不整合です。
- 問題の核心： PL/Iの内部データは、IBMのハードウェア仕様に基づき、負の数の符号が `0xC` や `0xD` ではなく、正しく処理されない形式（あるいはEBCDIC特有の表現）で渡されることがあります。
- 対策： 外部システムと連携する際は、必ず`HEX`ダンプを確認し、符号が`F`（正）、`C`（正）、`D`（負）のいずれであるかを確認してください。マイグレーション時には、この「符号ビットの解釈」を関数化し、ロジック全体で統一しなければなりません。
—
4. マイグレーションに向けたアーキテクチャ設計の指針
レガシー移行を成功させる鍵は、PL/I特有の「コンパイラによる自動最適化」を、移行先の言語でどう再現するかです。
1. アラインメントの可視化： `STORAGE`関数を使って、構造体の各メンバのオフセットをログ出力し、移行先言語のメモリレイアウトと比較してください。
2. 埋め込みSQLの挙動： DB2のホスト変数として構造体を使用している場合、SQLCAやSQLDAの扱いが言語ごとに異なります。特に`INDICATOR`変数の配列操作は、PL/Iのロジックを忠実に再現する必要があります。
3. CICS/IMSの制約： オンライン処理では、スタックオーバーフローを防ぐために`STORAGE`クラスを厳密に管理してください。PL/Iの`AUTOMATIC`変数はスタックに展開されますが、Javaのヒープ管理とはライフサイクルが大きく異なります。
最後に
PL/Iは古臭い言語ではありません。メモリという広大な荒野をポインタというナイフ一本で切り拓く、極めてプリミティブかつ強力なツールです。移行先の言語がいかに高機能であろうとも、私たちが向き合っているのは「0と1の並び」であることを忘れてはなりません。
コードの行間に潜むコンパイラの意図を読み解く力こそが、真のシステムアーキテクトに求められる最後の砦なのです。次回の記事では、`CONDITION`ハンドラによる例外処理の深掘りと、ダンプ解析における「レジスタの読み方」について語ろうと思います。
