PL/Iの「LENGTH」関数とVARYING属性：コンパイラの深淵を覗く
メインフレームの現場で長年PL/Iコードを眺めていると、時折「なぜここでアベンドするのか」という壁に突き当たることがある。特に、CICSの通信領域（COMMAREA）やDB2のホスト変数におけるデータ操作において、`LENGTH`組み込み関数が返す値の解釈を誤ると、それは致命的なデータ破壊や、夜間のバッチジョブを停止させるS0C4への招待状となりかねない。
今回は、PL/Iの「予約語を持たない」という自由奔放な設計思想が、`LENGTH`関数の挙動にどのような影を落としているのか、そして移行スペシャリストが絶対に押さえておくべき「記述子（Descriptor）」の正体について深掘りしていこう。
—
1. 固定長 vs VARYING：LENGTHが返す「真実」
まず、基本を再確認したい。PL/Iにおいて`CHARACTER(n)`と宣言された固定長文字列と、`CHARACTER(n) VARYING`の挙動は、内部表現において全く別物である。
- 固定長文字列 (`CHAR(10)`): 宣言された長さ（10）を常に返す。メモリ上は連続したバイト列として確保される。
- VARYING文字列 (`CHAR(10) VARYING`): 実効長を示す「プレフィックス（2バイトのバイナリ値）」＋「データ本体」で構成される。`LENGTH`関数は、このプレフィックス部分を読み取って値を返す。
マイグレーション先のJavaやC#では、文字列の長さはオブジェクトのプロパティとして管理されるが、PL/Iではこれがコンパイラによって生成される「記述子（Descriptor）」に依存している。
実務コード例：ポインタを用いた記述子の直接参照
以下のコードは、`VARYING`変数の内部構造をポインタでハックし、実効長を直接操作するような場面を想定している。
/i
DCL STR_VAR CHAR(20) VARYING INIT(‘IBM_MAINFRAME’);
DCL PTR_STR PTR;
DCL 1 STR_DESC BASED(PTR_STR),
2 LEN_PREFIX FIXED BIN(15), / プレフィックス部分 /
2 DATA_PART CHAR(20); / データ本体 /
PTR_STR = ADDR(STR_VAR);
/ LENGTH関数は内部的にLEN_PREFIXを参照している /
PUT SKIP LIST(‘LENGTH:’, LENGTH(STR_VAR));
/ 危険な操作：記述子を直接いじると、後続のDB2処理や
CICS出力で予測不能なガベージが混入する原因となる /
LEN_PREFIX = 5;
—
2. 記述子（Descriptor）とアベンドの相関関係
JavaやC#への移行を検討する際、最も頭を抱えるのがこの「記述子」の存在だ。PL/Iはプロシージャ呼び出し時に、変数のアドレスだけでなく、その変数の属性情報を格納した記述子をスタック経由（またはレジスタ経由）で渡すことがある。
もし移行先の言語で`String`型をそのまま受け取ろうとすると、このプレフィックス（2バイト）をデータの一部として誤読し、画面上に「謎の制御文字」が表示される、あるいはDB2のパックデシマル変換時に`SQLCODE -180`（日付/時刻形式エラー）や数値変換エラーが発生する。
トラブルシューティングの勘所
- S0C4発生時: `VARYING`変数にポインタをキャストしてアクセスしようとして、プレフィックスの領域を考慮せずオフセット計算を誤るケースが多い。
- パックデシマルの内部符号反転: `PIC S9(7) COMP-3`などのフィールドをポインタ操作で無理やり書き換える際、符号部分（ニブル）を破壊してしまい、DB2の行挿入時にアベンドする。これは「データの中身」だけを見て「記述子のメタ情報」を無視した時に起こる典型的なミスだ。
—
3. 最適化とコンパイラ・オプションの罠
PL/Iコンパイラ（Enterprise PL/I）の最適化オプション（`OPT(2)`や`OPT(3)`）を有効にすると、コンパイラは「この変数は変更されないはずだ」と推測し、`LENGTH`関数の結果をレジスタにキャッシュすることがある。
特にポインタを使ってメモリを直接書き換えるような「お行儀の悪い」コーディングをしている場合、コンパイラの最適化によって、メモリ上の値は変わっているのに、プログラム側は古い`LENGTH`値を使い続けるという怪奇現象が発生する。
対策:
1. `VOLATILE`属性の活用: 外部から変更される可能性のある共有メモリ領域などは、必ず`VOLATILE`を付与し、コンパイラの安易なレジスタ最適化を抑制すること。
2. ダンプ解析: `CEEDUMP`を取得した際、`STORAGE`コマンドでプレフィックスの2バイトを確認する習慣をつけること。ここが宣言値と乖離していれば、メモリ破壊の犯人は確定だ。
—
結論：レガシー移行への提言
PL/Iは、ハードウェアの特性をプログラマが直接制御できる、非常に強力かつ恐ろしい言語だ。マイグレーションプロジェクトにおいて、単なる構文変換ツールに依存して「機械的に変換」しようとするのは、基幹システムの保守性を著しく低下させる。
特に`VARYING`属性と`LENGTH`関数の関係性は、単なる文字列操作ではなく、メインフレームのメモリモデルそのものを象徴している。移行先がJavaであれC#であれ、この「メタ情報と実データの分離」というアーキテクチャを、いかにオブジェクト指向の範疇で安全にラップできるか。そこに、真のシステムアーキテクトの腕の見せ所がある。
枯れた技術と侮るなかれ。この深い制御の歴史を知る者だけが、モダンなシステムでも「壊れない基幹系」を構築できるのである。
