はじめに：PL/Iにおける「識別子の自由」と裏腹の内部構造
こんにちは。長年、金融や公共の基幹システムを支えるIBMメインフレームと向き合い、数々のレガシーマイグレーションを主導してきたシステムアーキテクトです。
JavaやC#といったモダンな言語に慣れ親しんだエンジニアが、初めてPL/Iのコードベースに触れたとき、まず驚くのが「予約語の少なさ」です。PL/Iには、COBOLの「DISPLAY」やC言語の「int」のような厳格なキーワードがほとんどありません。`IF`や`THEN`といった制御文でさえも、コンテキストによっては単なる識別子（変数名）として使えてしまう。この圧倒的な自由度は、Language/C（LE）ランタイムとコンパイラの高度な字句解析・構文解析の賜物です。
しかし、この「言語仕様の懐の深さ」は、時にシステムアーキテクトにとって悩ましいブラックボックスを生み出します。その最たる例が、VARYING属性を持つ可変長文字列（VARCHAR）の内部構造と、LENGTH関数が裏側で行っている記述子（Descriptor）参照のメカニズムです。
今回は、基幹システムのバッチ処理やオンライン（CICS）、さらにはオープン系へのマイグレーション現場でエンジニアを苦しめる、この「可変長文字列の裏側」について、コンパイラの挙動とメモリレイアウトの観点から徹底的に解き明かしていきましょう。
—
1. VARYING属性のメモリレイアウトと記述子の正体
PL/Iで `DCL 01 W_REC, 03 W_LEN FIXED BIN(15), 03 W_DATA CHAR(100) VARYING;` のような可変長文字列を定義したとき、メモリ上では一体何が起きているでしょうか。
C言語の `char` や Java の `String` オブジェクトの参照とは異なり、PL/Iの VARYING 文字列は、文字列本体のメモリ領域の直前（上位アドレス側）に、現在の長さを格納するための2バイト（あるいは4バイト）の長さフィールド（プレフィックス）を必ず伴います。これが俗に言う「記述子（Descriptor）」、あるいはプログラミングの現場で「隠しプレフィックス」と呼ばれる領域です。
+———————–+—————————————+
| 長さフィールド (2B) | 文字列本体データ (Nバイ卜) |
| (CURRENT LENGTH) | (MAX LENGTH分の領域確保) |
+———————–+—————————————+
^ ^
| +— ポインタが指すべきアドレス (ベース変数)
+— 実際の物理メモリの先頭
通常、PL/Iのソースコード上で `WK_LEN = LENGTH(W_DATA);` と記述すれば、コンパイラは最適なマシン語命令（MVCやLHなど）を生成し、このプレフィックスの値を安全に取得してくれます。
しかし、基幹システムのパフォーマンスチューニング、あるいはCICSの通信領域（COMMAREA）やDB2のホスト変数との間で、ポインタ（POINTER）と基底変数（BASED）を用いた動的メモリ操作、いわゆる「ストリークな領域切り出し」を行う必要に迫られた瞬間、この内部構造を知らないエンジニアは致命的な罠に踏み込みます。
—
2. ポインタとベース変数による実務コード例：罠と正しいアプローチ
例えば、外部から渡された生（Raw）のバイト列を、特定の構造体としてマッピングして処理するバッチプログラムを考えてみましょう。ここで、VARYING変数をそのままBASED変数として定義し、誤ったポインタ操作を行うと、一発でS0C4（Protection Exception）やデータ化けアベンドを引き起こします。
以下の実務的なコード例を見てください。
1
—————————————————————-
- プレフィックスとVARYING文字列のメモリマッピング検証プログラム
—————————————————————-
DEMO_VARYING: PROC OPTIONS(MAIN);
/ 1. 作業用変数の定義 /
DCL 1 SYS_AREA BASED(P_AREA),
3 V_LEN FIXED BIN(15), / 可変長文字列の長さプレフィックス /
3 V_STR CHAR(50) VARYING; / 可変長文字列本体 /
DCL RAW_BUFFER CHAR(100) INIT(‘ ‘); / 外部からの受信バッファ模擬 /
DCL P_AREA POINTER;
DCL L_ACTUAL FIXED BIN(31);
/ 2. ポインタをバッファのアドレスに設定 /
P_AREA = ADDR(RAW_BUFFER);
/ 3. 【危険なパターン】VARYING変数に対して直接値を代入 /
/
注意: V_STRは VARYING属性を持つため、コンパイラは
「V_STRの先頭2バイト」を長さプレフィックス領域とみなします。
ポインタP_AREAが指す位置を誤ると、メモリ破壊の元凶になります。
/
V_STR = ‘HELLO MAINRAME’;
/ 4. LENGTH関数による長さにアクセス /
L_ACTUAL = LENGTH(V_STR);
DISPLAY(‘CURRENT LENGTH: ‘ || L_ACTUAL);
/
【アーキテクトの知見】
もし、外部から受信した固定長レコードの中に「前半2バイトが長さ、
後半がデータ」というフォーマットの項目が存在する場合、
これをそのまま VARYING 変数として BASED 定義すると、
コンパイラが期待するプレフィックス構造と合致し、
LENGTH関数や文字列結合（||）の挙動が完全に一致するため、
非常にエレガントに処理できます。
/
END DEMO_VARYING;
このコードにおける最大のポイントは、「PL/Iコンパイラは VARYING 変数を扱う際、プログラマが明示しなくとも、常に先頭の2バイト（または4バイト）を暗黙的に長さとして参照・更新している」という点です。
—
3. コンパイラオプションと最適化の罠
IBM Enterprise PL/Iコンパイラを使用する際、パフォーマンスを極限まで高めるために `OPTIMIZE(2)` などの最適化レベルを適用することが一般的です。ここで、システムアーキテクトとして絶対に知っておなければならないのが、「記述子参照の最適化とアライメント（境界調整）」の挙動です。
アライメントの不一致によるスローダウンと例外
VARYING文字列がハーフワード境界（2バイト境界）またはフルワード境界（4バイト境界）に正しく配置されていない場合、特に `BASED` 変数を用いて動的にメモリをキャストした際に、System/390アーキテクチャのCPUは「Addressing Exception (S0C4)」や「Specification Exception (S0C6)」を発生させます。
特に、COBOLからPL/Iへの移行時によくあるのが、COBOLの `PIC X(n)` や `COMP-3` が混在するレコードレイアウトを、そのままPL/Iの `BASED` 構造体に割り当てるケースです。PL/I側で `ALIGNED` 属性と `UNALIGNED` 属性の指定を誤ると、コンパイラが自動挿入するパディング（パディングバイト）の位置がズレ、`LENGTH` 関数が指し示すプレフィックスの位置が狂い、文字化けや意図しない長さ（ゴミデータ）を返すバグへと直結します。
—
4. エッジケース対策：埋め込みSQL（DB2）およびCICS環境での注意点
基幹システムの現場では、純粋なPL/Iの計算処理だけでなく、DB2のホスト変数やCICSのCOMMAREAを介したデータ授受が日常茶飯事です。ここでも「記述子参照」が絡む特有のエッジケースが存在します。
DB2ホスト変数としての VARCHAR
DB2のテーブル定義で `VARCHAR` カラムからデータをフェッチする場合、PL/I側のホスト変数には以下のように定義します。
1
DCL 1 DB_REC,
3 EMP_NAME,
5 LEN FIXED BIN(15),
5 TEXT CHAR(50);
あるいは、PL/Iの `CHAR(50) VARYING` をそのままホスト変数として渡すことも可能です。プリコンパイラ（SQLプレコ）は、`VARYING` 属性を検知すると、自動的にDB2が要求する「2バイトの長さ + データ本体」の構造へ変換するコードを展開します。
しかし、マイグレーションの現場でよくあるのが、オープン系（Java/PostgreSQLなど）へ移行する際に、この「先頭2バイトの長さプレフィックス」を考慮し忘れてバイナリデータをそのまま移行し、DB2のストアドプロシージャやCICSの領域外参照でアベンドを引き起こすトラブルです。移行設計の段階で、全てのVARYING変数がどのようにメモリ上でシリアライズされるかをドキュメント化し、検証しておく必要があります。
—
5. ダンプ解析の現場から：S0C4/S0C7アベンド時の記述子確認手法
深夜のバッチ運用中、突如として発生した `S0C4`（ストレージ保護例外）あるいは `S0C7`（データ例外）。コンパイルリストとCEEDUMP（Language Environmentのダンプ）を広げたとき、あなたはどうやって原因を特定しますか？
VARYING文字列に起因するバグの多くは、「プレフィックスに格納された長さ（LENGTH）が、実際のメモリ領域の最大長（MAX_LENGTH）を超過している」という状態から発生します。ポインタ経由で不正な長さを書き込んでしまった場合、後続の文字列操作命令（`ASSIGN` や `CAT`）が暴走します。
ダンプリーディングの勘所
1. CEEDUMPのStorage部を確認し、問題の変数が割り当てられているアドレスを特定する。
2. そのアドレスの直前2バイト（Hex表示）を確認する。
3. 例えば、`CHAR(50) VARYING` であるにもかかわらず、プレフィックスの値が `0035`（十進数で53）など、定義された最大長（50）を超える値が入っている場合、メモリ破壊（オーバーラン）が確実視されます。
このような現場の修羅場をくぐり抜けてきたアーキテクトだからこそ言えるのは、「PL/Iの文法エラーはコンパイラが教えてくれるが、メモリレイアウトと記述子の不整合は、動体稼働するまで沈黙して牙をむく」ということです。
—
おわりに：レガシーの底力を知る者たちの役割
PL/Iの LENGTH 関数が裏側で行っている記述子参照は、単なるシンタックスの糖衣ではありません。それは、限られたメインフレームのハードウェア資源を極限まで効率的に使い倒すために設計された、先人たちの知恵の結晶です。
JavaやC#へのマイグレーションを進めるにあたり、「古い言語だから」「ブラックボックスだから」と敬遠するのではなく、その言語仕様の底流にあるメモリ管理思想をここまで深く理解しているからこそ、移行先のモダンな環境においても、堅牢でパフォーマンスに優れたアーキテクチャを設計することができるのです。
レガシーシステムのモダナイゼーションに挑むすべてのテックリード、そしてPL/Iの深淵に挑むエンジニア諸氏の健闘を祈ります。
