PL/I VARYING文字列の深淵：先頭2バイトの構造と動的メモリ管理の罠
基幹システムの現場で長年メインフレームと向き合ってきたアーキテクトなら、深夜のトラブルシューティングで一度や二度、ストレージ・ダンプ（Core Dump）の海に溺れかけた経験があるはずだ。
「なぜ、この可変長文字列（`CHARACTER VARYING`）を表示しようとすると、先頭にゴミのようなバイナリが混じるのか？」
「なぜ、DB2への埋め込みSQLでこの変数をホスト変数として渡した途端に、SQLCODE -302（値の切り捨てまたは数値変換エラー）が返るのか？」
JavaやC#といったモダン言語の文字列操作に慣れ切った若いエンジニアが、PL/Iのレガシーコードに手を出して最初にハマるのが、この`VARYING`属性の内部構造である。今回は、IBM Enterprise PL/Iコンパイラの内部挙動を解剖し、制御ブロックの正体から、マイグレーション時における致命的なエッジケース、そしてアベンド（ABEND）回避のための実践的な知見までを徹底的に解説しよう。
—
1. VARYING文字列の制御ブロック構造：先頭2バイトの真実
PL/Iの `CHARACTER(n) VARYING` （または `CHAR(n) VARYING`）は、一見するとC言語のヌル終端文字列やJavaの `String` オブジェクトのように扱えるが、そのメモリ上の実態は完全に異なる。
コンパイラは、`VARYING` 変数に対して「長さ情報（2バイトの半精度整数）」＋「実際の文字列データ（nバイト）」という連続した領域を割り当てる。
+——————-+—————————————–+
| 長さ情報 (2バイト) | 文字列データ (実データ長分) |
| (Current Length) | (Maximum n bytes) |
+——————-+—————————————–+
この先頭2バイト（Binary Halfword / 影の長さフィールド）には、現時点でその変数に格納されている有効な文字列の長さがビッグエンディアン（System/390アーキテクチャのネイティブ形式）で格納される。
動的メモリ管理とベース変数の罠
PL/Iでは、この内部構造を意識してポインタやベース変数（`Based Variable`）を操作することが可能だ。しかし、一歩踏み誤れば、ストレージ違反によるS0C4アベンドの直撃を受ける。
以下のコード例を見てほしい。実務のバッチ処理や、マイグレーション時のデータ構造解析で頻繁に遭遇するパターンだ。
DCL 1 DUMP_AREA BASED(P_AREA),
5 V_LEN FIXED BIN(15), / 先頭2バイトの長さフィールド /
5 V_DATA CHAR(100); / 実データ領域 /
DCL P_AREA POINTER;
DCL MY_VAR CHAR(100) VARYING;
DCL WORK_STR CHAR(100);
/ MY_VARのストレージアドレスをポインタにセット /
P_AREA = ADDR(MY_VAR);
/ 【警告】これはコンパイラ最適化や処理系依存の危険な操作である /
DISPLAY(‘現在の長さ: ‘ || V_LEN);
ここで重要なのは、`ADDR(MY_VAR)` が指すアドレスは、「長さ情報を含んだ領域の先頭」を指しているという点だ。もし、C/S環境やJavaへのマイグレーション（リライト）を行う際、この先頭2バイトの存在を無視して単なる「文字列のポインタ」として移行先へ渡してしまうと、移行先プログラムは先頭の2バイトを文字データの一部と誤認し、文字化けや予期せぬパースエラーを引き起こす。
—
2. コンパイラオプションによる最適化とアベンド（ABEND）の解析
IBM Enterprise PL/Iコンパイラでは、アライメント（境界調整）に関するコンパイラオプション（`ALIGNED` / `UNALIGNED`）が生成コードのパフォーマンスとストレージレイアウトに決定的な影響を与える。
`VARYING` 文字列は、デフォルトで `UNALIGNED` として扱われることが多い。これは、ストレージの無駄を省くためにバイト境界に隙間なく配置されることを意味するが、メインフレームのハードウェア特性上、奇数境界にあるハーフワード（2バイト）へのアクセスは、CPUのマイクロコードによるエミュレーションや性能劣化（場合によっては例外）を招くことがある。
ダンプ解析の現場から：S0C4/S0C7の温床
オンラインCICS環境や大規模バッチで `S0C4`（保護例外）が発生した際、ストレージ・ダンプをIPCSなどで解析すると、以下のような現象にぶち当たる。
1. 長さ情報の破壊: 不適切なポインタ演算や、外部サブルーチン（COBOLやアセンブラ）からの誤った領域上書きにより、先頭2バイトの長さフィールド（`V_LEN`）に `X’FFFF’` や実サイズを超える数値（例：宣言値 `100` に対し `255`）が書き込まれている。
2. コンパイラの文字処理ルーチンによる暴走: PL/Iの組み込み関数（例えば `SUBSTR` や連結演算子 `||`）が実行された際、内部の長さ情報を信頼してメモリスキャンを行いが、宣言された最大長を超えてリードしようとして `S0C4` アベンドが発生する。
ダンプ上で `VARYING` 変数を見つけるときは、文字データの直前にある2バイトのバイナリ値に注目せよ。そこに格納されている数値が、実際の文字列の長さと一致しているかを確認するのが、熟練アーキテクトの定石である。
—
3. 埋め込みSQL（DB2）およびCICSにおけるエッジケース対策
基幹系PL/Iプログラムの多くは、DB2（SQL）やCICS（画面・通信制御）と密に結合している。ここでも `VARYING` 属性はいくつかの「罠」を仕掛けてくる。
DB2ホスト変数としての落とし穴
DB2の `VARCHAR` カラムに対応させるため、PL/I側で以下のように `VARYING` 変数を定義することは日常茶飯事だ。
DCL DB_EMP_NAME CHAR(50) VARYING;
EXEC SQL
SELECT EMP_NAME
INTO :DB_EMP_NAME
FROM EMPLOYEE
WHERE EMP_ID = :W_EMP_ID;
プリコンパイラ（DB2 Coprocessor）は、この `VARYING` 変数を内部的に「長さフィールド（2バイトの半精度整数）」と「データフィールド（固定長CHAR）」の構造体に展開してSQLを生成する。
しかし、エッジケースとして注意すべきは以下の点だ。
- パックデシマルの内部符号反転や変形データ: これが直接 `VARYING` に絡むことは稀だが、ホスト変数構造体の不整合や、DB2からのデータフェッチ時に長さフィールドが不正な値で返された場合、SQLCODE -302 や -802（データ例外）を引き起こす。特に、他システムからファイル経由でインポートしたデータをそのままDB2へ流し込むバッチでは、事前に `VERIFY` 組み込み関数等でデータの正当性を担保しなければならない。
- CICSの通信領域（COMMAREA）やプロトコル変換において、COBOLの `PIC X(n)`（固定長）とPL/Iの `VARYING` をインターフェースとして直接やり取りする場合、先頭2バイトの存在を忘れてパディング（空白埋め）の計算を誤ると、メッセージ全体のオフセットが大きくずれ、オンラインシステム全体の沈黙を招くことになる。
—
4. マイグレーション・アーキテクトとしての提言
もし現在、貴社が「PL/IレガシーシステムのJava/C#へのオープン化・モダナイゼーション」のプロジェクトを推進しているならば、この `VARYING` の仕様こそが、トランスレーション（機械的変換）ツール泣かせのポイントであることを理解しておくべきだ。
1. 機械的変換の限界: 多くの自動変換ツールは、PL/Iの `VARYING` をターゲット言語（Javaの `String` やC#の `string`）に単純に置き換える。しかし、ポインタを使って先頭2バイトを直接操作しているようなスパゲッティコードや、アセンブラとの混成コードが存在する場合、変換ツールは完全にお手上げとなる。
2. 事前リファクタリングの重要性: マイグレーションの成否は、移行前のコードベースにおいて、このようなトリッキーなベース変数やポインタによる `VARYING` 操作を、安全な標準的構文へ事前にリファクタリングできるかどうかにかかっている。
結びに代えて
PL/Iの言語仕様は、ハードウェアの構造（メインフレームのアーキテクチャ）と極めて密接に結びついている。単なる「古い構文」として切り捨てるのではなく、そのメモリ管理のメカニズム──先頭2バイトの制御ブロックに秘められた意図を理解し尽くすことこそが、基幹システムの信頼性を守り抜き、安全な次世代アーキテクチャへ移行するための唯一にして最大の近道なのである。
