制御された混沌：PL/IにおけるCONTROLLEDストレージの深淵と設計の鉄則
メインフレームの現場で長く生き残ってきたシステムアーキテクトであれば、一度は`CONTROLLED`属性の悪夢に遭遇したことがあるはずです。静的領域（STATIC）の安心感や、スタック領域（AUTOMATIC）の自動管理とは異なり、`CONTROLLED`はプログラマに「神の権限」と「全責任」を同時に与えます。
今回は、基幹システムの心臓部を支えるPL/Iの動的メモリ管理について、単なる構文解説を超えた「生存戦略」を語ります。
—
1. CONTROLLED属性の本質：スタックの外側で生きる変数
PL/Iにおける`CONTROLLED`変数は、OSのストレージ管理に直接的なリクエストを投げます。`ALLOCATE`が実行されるたびに、新しいスタックフレームが生成されるのではなく、ヒープ領域にメモリが確保され、既存の同名変数はスタック状に「プッシュ」されます。
/i
/ CONTROLLED属性による動的確保の基本 /
DCL MY_BUFFER CHAR(1024) CONTROLLED;
/ 確保：ストレージがヒープに割当てられる /
ALLOCATE MY_BUFFER;
/ 複数回ALLOCATEすると、古いものはスタック状に隠蔽される /
/ この挙動を理解していないと、FREEし忘れたメモリがリークとして蓄積される /
FREE MY_BUFFER; / 解放：直近のALLOCATEが解放され、隠れていたものが再度現れる /
ここで重要なのは、`FREE`を忘れた時の挙動です。特にCICS環境の擬似会話型トランザクション（Pseudo-conversational）でこれをやらかすと、タスク終了までメモリが解放されず、Storage Violation（S0C4やS0C6）を誘発する一因となります。
2. ポインタとベース変数：動的構造体の制御
マイグレーション時に頭を悩ませるのが、`BASED`変数と`ADDR`関数、そしてポインタの組み合わせです。これらは、COBOLの`REDEFINES`やJavaの`ByteBuffer`的なメモリ操作をPL/I流に実現する手法ですが、アライメントの不一致には細心の注意が必要です。
/i
DCL MY_PTR POINTER;
DCL MY_STRUCT BASED(MY_PTR) CHAR(200);
/ GETMAIN/STORAGE OBTAINに相当する動的確保 /
ALLOCATE MY_STRUCT;
/ DB2の埋め込みSQLでNULLフラグを扱う際によく見るパターン /
/ パックデシマル(FIXED DEC)の内部表現に直接触れる際は注意が必要 /
【現場の教訓：パックデシマルの内部符号】
メインフレーム移行時、特に外部システムとのデータ連携において、パックデシマルの符号ビット（`X’F’`や`X’C’`、`X’D’`）が正しく変換されず、DB2のホスト変数に格納した瞬間に`SQLCODE -802`（算術例外）を吐くケースが多発します。`CONTROLLED`や`BASED`でメモリを直接操作する場合、コンパイラが自動的に行う変換がスキップされることがあるため、必ず`HEX`ダンプで符号バイトを検証してください。
3. メモリリークとアベンドの解析：ダンプを読む技術
PL/Iプログラムが`S0C4`（保護違反）で落ちた時、まず確認すべきは`CEE3DMP`（Language Environmentダンプ）です。
- ALLOCATEの不整合: `FREE`を呼び出しても、その領域がまだ有効なポインタにリンクされているか？
- ストレージ・オーバーレイ: `CONTROLLED`変数の境界を超えてデータを書き込んでいないか？
特に`OPTIONS(MAIN)`の基幹バッチで、特定の条件下でしか発生しないメモリリークは、稼働後の長期運用でしか露見しません。これを防ぐためには、`PL/I`コンパイラオプションの`CHECK(SUBSCR, STORAGE)`を開発環境で徹底することが鉄則です。本番環境でこれをオフにするとしても、設計段階で「メモリの寿命」と「解放のタイミング」をシーケンス図に明記する文化をチームに根付かせてください。
4. マイグレーションに向けたアーキテクチャの視点
JavaやC#への移行を検討しているアーキテクト諸氏へ。PL/Iの`CONTROLLED`変数や`BASED`変数は、移行先言語のオブジェクト指向設計における「ライフサイクル管理」の概念と一対一で対応しません。
- PL/Iの思考: 「必要なときにメモリを確保し、使い終わったら明示的に捨てる」
- 近代言語の思考: 「GC（ガベージコレクション）に任せる」
このパラダイムシフトを埋めるには、単なるコードの書き換えではなく、「メモリ管理のオーナーシップ」を明確にするリファクタリングが必要です。`FREE`すべき箇所が不明確なレガシーコードをそのままクラス化すると、移行先でメモリリークの温床となります。
最後に：深淵を覗く者へ
PL/Iは、機械の挙動をありのままに記述できる、極めて実直で強力な言語です。`CONTROLLED`属性は、そのパワーを制御するための「手綱」です。
移行プロジェクトにおいて、この「手綱」の引き方を理解せず、安易に自動変換ツールに頼ることは、爆弾を抱えたままモダンな言語へ移植するようなものです。まずはダンプを読み、メモリマップを書き出し、なぜその領域が必要なのかをコードから読み解く。その泥臭いプロセスこそが、世界最高峰のシステムを維持する唯一の道だと私は信じています。
何か特定のモジュールでメモリ管理の設計にお悩みであれば、いつでも詳細なダンプの読み方から議論しましょう。汎用機の知識は、いつの時代も陳腐化しない最強の武器なのですから。
