金融機関や大規模流通基幹システムの心臓部で、何十年も止まることなく稼働し続けているIBMメインフレーム。その世界において、PL/I（Programming Language One）はCOBOLと並び称される巨塔です。
今回は、PL/Iのコードがコンパイルされる際に、コンパイラが裏で何を行っているのか――特に `OPTIMIZE(2)` および `OPTIMIZE(3)` という強力な最適化オプションが、機械語レベルのレジスタ割り当てや、夜間バッチのアベンド解析（SYSUDUMP/CEEDUMP）にどのような影響を及ぼすのかについて、現場のテックリードやマイグレーション設計者の視点から深く掘り下げていきたいと思います。
—
1. 予約語を持たないPL/Iの柔軟性と、最適化のジレンマ
PL/Iの最もユニークな特徴の一つに、「言語仕様上の予約語（Reserved Words）を持たない」という設計思想があります。例えば、`IF` や `THEN` さえもコンテキストによっては変数名として宣言可能です（非推奨ではありますが）。
この「自由度の高さ」は、構文解析（パーサー）やそれに続く最適化フェーズにおいて、コンパイラに高度な推論を要求します。特にポインタやベース変数を用いた動的メモリ操作が絡むと、コンパイラは「このポインタが指す領域と、あのローカル変数の領域がオーバーラップしているかもしれない（エイリアシング問題）」という最悪のケースを常に考慮しなければなりません。
しかし、開発者がコンパイラに `OPTIMIZE(2)` や `OPTIMIZE(3)` を指示した瞬間、コンパイラはその安全弁を外し、アグレッシブなコード生成を開始します。
1
/ 最適化の恩恵と罠が潜む動的メモリ操作の例 /
DCL 1 W_MEMBER_REC BASED(P_MEMBER_PTR),
5 MBR_ID CHAR(8),
5 MBR_STATUS CHAR(1),
5 MBR_BALANCE FIXED DEC(11,2);
DCL P_MEMBER_PTR POINTER;
DCL W_WORK_BAL FIXED DEC(11,2);
/ 最適化レベルによってはメモリアクセスがレジスタ上にキャッシュされる /
W_WORK_BAL = MBR_BALANCE;
CALL CALC_INTEREST(W_WORK_BAL);
MBR_BALANCE = W_WORK_BAL;
このようなコードにおいて、`OPTIMIZE(3)` が指定されると、コンパイラは `MBR_BALANCE` の値を汎用レジスタや浮動小数点レジスタ（あるいはEnterprise PL/Iのアーキテクチャに応じた専用レジスタ）にロードし、メモリ（ストレージ）への書き戻しを極限まで遅延、あるいは省略します。
—
2. OPTIMIZE(2|3) がもたらすレジスタ割り当ての現実
`OPTIMIZE(2)` はオブジェクトコードのサイズと実行速度のバランスを取る標準的な最適化ですが、`OPTIMIZE(3)` に引き上げると、インライン展開、ループ最適化、そして何よりも「変数のレジスタ常駐化（Register Allocation）」が極限まで推し進められます。
基幹システムの現場でよくあるのが、「本番バッチでのみ発生する謎のデータ不整合」です。テスト環境（多くは `OPTIMIZE(0)` または `OPTIMIZE(1)` でビルドされている）では再現せず、本番リリースした途端に落ちる。この原因の多くは、最適化によってメモリ上の値が最新化されていないタイミングで別のアドレスから参照されたり、非同期のCICSタスク間でストレージの整合性が崩れたりすることにあります。
パックデシマルの内部符号反転バグと最適化の影
特に注意すべきは、`FIXED DECIMAL`（パック10進数）の演算です。PL/Iでは暗黙の型変換や符号操作が頻発しますが、古いコンパイラや特定のパッチレベルでは、最適化によってレジスタ内に保持されたパックデータのゾーン・ニック部分の扱いに起因する符号反転バグ（S0C7の原因となる不正データの生成）が誘発されることがあります。メモリストレージ上では正しい値に見えても、レジスタ内での演算過程でパッキングが崩れる現象は、まさにアーキテクチャの深淵を覗く思いがするトラブルです。
—
3. アベンド（ABEND）発生時、ダンプ解析の難易度が跳ね上がる理由
システムが突如として S0C4 や S0C1、あるいはLanguage Environment（LE）によるCEEDUMPを吐いて異常終了したとき、アーキテククトの腕の見どころとなります。
しかし、コンパイラ最適化が有効なバイナリのダンプ解析は、初学者の想像を絶する難しさがあります。
1. 変数が「消滅」する
ダンプリスト（LIST/OFFSETオプション付きコンパイルリスト）を頼りに該当変数のオフセットを確認しても、`OPTIMIZE(3)` が適用されていると、その変数は独立したメモリ領域を持たず、汎用レジスタ（例: R6やR11など）の割り当てに「溶けて」消えています。変数の現在値を知るためには、ストレージダンプではなく、PSW（Program Status Word）やレジスタ・スナップ（Registers at time of ABEND）を逆アセンブルして追う必要があります。
2. 命令の並べ替え（Instruction Scheduling）
パイプラインハザードを避けるため、コンパイラはソースコードの記述順とは全く異なる順序で機械語命令を生成します。ソース上の「この行でアベンドした」という確信が、逆アセンブル結果では数行先、あるいは手前の命令実行時のレジスタ汚染に起因していることが多々あります。
—
4. マイグレーション（Java/C#等への移行）における設計上の示唆
現在、レガシーマイグレーションのプロジェクトにおいて、PL/Iで書かれた数十万ステップのコアロジックをJava（Spring Boot）やC# (.NET Core)へ移植する作業が数多く行われています。
ここで最も重要なアーキテクチャ的教訓は、「PL/Iの最適化前提のタイトなコードや、ベース変数によるメモリのハックを、そのままオブジェクト指向言語に直訳してはならない」ということです。
- ポインタとベース変数のカプセル化
PL/Iの `BASED` ストレージによる動的オーバーレイは、Javaの `ByteBuffer` やC#の `unsafe` コンテキストでエミュレート可能ですが、保守性を著しく低下させます。移行先のモダン言語では、これを明確なデータ構造（DTO / Domain Model）と不変オブジェクト（Immutable Object）として再設計し、コンパイラの「最適化の魔法」に頼らない、安全で予測可能なメモリモデルに落とし込むべきです。
- 埋め込みSQL（DB2）およびCICS通信のエッジケース
CICSオンラインやDB2のホスト変数において、PL/Iのデータ属性とSQLのデータ型がミリ単位で一致している前提で最適化されたコードは、JavaのJPA/Hibernate層へ移行する際に型ミスマッチの温床となります。特に `CHAR` のブランクパディングや `FIXED BINARY` のバイト境界の扱いは、最適化レベルに関わらず、移行時の厳密な単体・結合テストで暴く必要があります。
—
まとめ
IBMメインフレームにおける PL/I の `OPTIMIZE(2|3)` は、ハードウェアの性能を極限まで引き出し、秒単位を争う巨大バッチの実行時間を削り取るための最強の武器です。しかしそれは同時に、ソースコードと機械語の間の乖離を広げ、デバッグの難易度を跳ね上げる諸刃の剣でもあります。
レガシーシステムの改修や、将来的なオープン系へのマイグレーションを成功させるためには、単に「動くコードを書く」のではなく、「コンパイラが裏で何を行っているのか」というハードウェアとソフトウェアの境界線を見据えた、深いシステムアーキテクチャの知見が不可欠なのです。
