領域の境界線を見極める：PL/Iにおける動的メモリ操作とデバッグの極意
メインフレームの心臓部で鼓動を打つPL/I。JavaやC#のガーベッジコレクションに慣れた世代には、この言語のメモリ管理は時に「古臭い」と映るかもしれません。しかし、基幹システムのアーキテクトとして、我々が扱うのはビットとバイトの厳密な統治下にある世界です。
今日は、動的メモリの深淵を覗くための武器、`LENGTH`関数と`STG`関数（およびその周辺知識）について、現場の「泥臭い」トラブルシューティングの観点から掘り下げていきます。
—
1. 動的メモリの現在地を「視る」：LENGTHとSTGの真価
PL/Iにおいて、`LENGTH`関数と`STG`（Storage）関数は、単なる仕様上の存在ではありません。特に、可変長文字列（`VARYING`属性）や、動的割り当てされた構造体を扱う際、これらは「防波堤」となります。
LENGTH関数：文字列の「実質」を知る
`LENGTH`は、単に定義上の最大長を返すのではなく、現在の有効長を返します。これがバグの温床となるのは、SQL（DB2）とのインターフェースです。
/i
DCL STR_VAR CHAR(100) VARYING;
/ DB2からFETCHした際、VARCHAR列はLENGTHで実長を確認しないと
後続のサブルーチンでゴミデータを拾う可能性がある /
IF LENGTH(STR_VAR) = 0 THEN DO;
/ 空文字判定のつもりが、実は未初期化のゴミが残っているケース /
END;
STG関数：ポインタの先にある真実
一方、`STG`関数は、変数が実際に占有しているストレージサイズをバイト単位で返します。特に、`DEFINED`属性や`BASED`変数を用いた構造体のオーバーレイを行う際、コンパイラのパディング（位置合わせ）によって構造体のサイズが予測とズレることは日常茶飯事です。
—
2. 実践：ベース変数とポインタによる動的メモリ操作
基幹システムの設計において、メモリの動的確保（`ALLOCATE`）は避けて通れません。しかし、ここで最も恐ろしいのは、ポインタの「野良化」と、それに起因するアベンド（S0C4など）です。
/i
DCL MY_PTR POINTER;
DCL 1 MY_STRUCT BASED(MY_PTR),
2 KEY_CODE CHAR(4),
2 DATA_VAL FIXED BIN(31);
/ メモリ確保直後にSTGでサイズを確認し、ログへ出力する癖をつけよ /
ALLOCATE MY_STRUCT;
PUT SKIP LIST(‘ALLOCATED SIZE: ‘ || STG(MY_STRUCT));
ここで重要なのは、「コンパイラオプションと最適化」です。`OPTIMIZE(3)`をかけた際、コンパイラは「使用されていない」と判断した変数をレジスタに隠蔽し、ダンプ解析を極めて困難にします。検証環境では必ず`GONUMBER`や`SOURCE`オプションを有効にし、シンボル情報が保持される状態でデバッグを行うことが鉄則です。
—
3. 現場で唸る「エッジケース」：パックデシマルとCICS
移行プロジェクトにおいて、Javaへの変換時に最も頭を抱えるのが、PL/I特有の「パックデシマル（`FIXED DEC`）」の内部表現と、`CICS`環境下でのストレージ破壊です。
パックデシマルの符号反転バグ
PL/Iの`FIXED DEC`は、最下位ニブルに符号（正なら`C`、負なら`D`）を持ちます。古いオンライン処理で、この符号ビットを強引に書き換えてフラグとして流用するテクニックが稀に存在します。マイグレーション先が符号ビットを無視する仕様だと、計算結果が突然、正負逆転する悪夢を見ることになります。
CICSにおけるストレージ・オーバーレイ
`CICS`環境では、`EXEC CICS GETMAIN`で確保した領域を超えて書き込むと、即座にトランザクションがアベンドしません。隣接する他トランザクションのメモリを汚染し、全く関係ない場所でバグが顕在化します。
- 対策： `STG`関数を用いて、割り当て領域の境界に番兵（Sentinel）を置き、定時チェックを行うサブルーチンを挟むのが、古強者のやり方です。
—
4. アーキテクトとしての提言：移行に向けた備え
レガシーマイグレーションを成功させる鍵は、現在のPL/Iプログラムが「メモリに対してどう振る舞っているか」を、Java等の高レイヤー言語のロジックに正確に翻訳することにあります。
- ポインタ演算の排除: ポインタによるメモリ操作は、可能な限り配列の添字やオブジェクトのリスト構造に置き換える。
- データ構造の正規化: `DEFINED`や`UNION`による「型を無視したデータ共有」は、Java等の厳格な型付け言語では天敵です。移行前に、まずは共通データ領域をDTO（Data Transfer Object）として構造化し直すことから始めてください。
PL/Iは、機械に近い位置で呼吸する言語です。その挙動を理解することは、システムの本質を理解することと同義です。ダンプの16進数リストと`STG`関数の値が一致したとき、あなたは初めて、そのプログラムの「真の姿」を制御下に置くことができるのです。
次回の更新では、`CONTROLLED`属性のスタック制御と、大規模バッチにおけるストレージリークの追跡手法について、さらに深く解説します。現場の諸君、今日もメインフレームの安定稼働のために、慎重にデバッグを続けましょう。
