VARYINGの深淵：PL/I可変長文字列が隠し持つ「先頭2バイト」の真実
メインフレームの現場で、長年「なんとなく」使われてきた `CHARACTER(n) VARYING`。
マイグレーションの現場において、Javaの `String` や C# の `string` と安易に等価変換して痛い目を見た経験はないだろうか。
PL/Iにおける `VARYING` は、単なる可変長文字列ではない。それは、コンパイラとハードウェアが密接に連携し、限られたメモリリソースを極限まで使いこなすための、古き良き「職人芸」の結晶だ。今回は、このデータ型の内部構造を暴き、トラブルシューティングの最前線で役に立つ知見を共有しよう。
1. 内部構造：先頭2バイトの「長さ情報」という呪縛
`CHARACTER(100) VARYING` を宣言したとき、メモリ上には「102バイト」が確保される。
この先頭2バイト（バイナリハーフワード）が、現在保持している文字列の長さを格納するエリアだ。
/i
DCL STR_VAR CHAR(100) VARYING;
/ 内部的には:
+0: 長さ (BINARY FIXED(15))
+2: 文字列実体 (CHARACTER(100))
/
この「長さ情報」を直接操作することは、言語仕様上は推奨されない。しかし、ダンプ解析で `S0C4` や `S0C7` に遭遇した際、この2バイトが破壊されているケースは枚挙に暇がない。
特に、ポインタを用いた動的メモリ操作（`BASED`変数）を行っている場合、境界調整（アライメント）のミスにより、この長さ情報がシフトしてしまうことが多々ある。
ダンプ解析の現場から
もし `STR_VAR` の内容が文字化けし、本来の長さ以上の値を参照しようとして `STORAGE OVERLAY` を引き起こしているなら、まず確認すべきは「先頭2バイトの値」だ。ここがEBCDICの制御コードや、パックデシマルの符号反転ビットと混ざっていないかを確認せよ。
2. パフォーマンスの暗部：暗黙の変換とコピーコスト
`VARYING` 変数を `CHARACTER(n)` （固定長）へ代入する際、コンパイラは内部で「長さ情報のチェック」と「必要に応じたパディング（スペース埋め）」を実行する。
大量レコードを処理するバッチプログラムにおいて、ループ内で `VARYING` を多用すると、この「コピーとパディング」がCPUコストを押し上げる。
/i
/ パフォーマンス改善の定石 /
DCL WRK_FIX CHAR(100);
DCL WRK_VAR CHAR(100) VARYING;
/ 代入のたびに長さ情報の更新とパディングが発生 /
WRK_FIX = WRK_VAR;
/ 頻繁な変換がボトルネックなら、最初から固定長で扱い、
長さ情報を別途管理するロジックの方が、実はメインフレームでは速い /
特に CICS オンライン環境では、`VARYING` を通信領域（COMMAREA）に直接配置するのは避けるべきだ。`EXEC CICS READ` 等で非構造的なデータが流し込まれた際、先頭2バイトが不正な値となり、その後の処理で無限ループや不正なメモリ参照を引き起こすリスクが高い。
3. マイグレーションにおける罠：パックデシマルとの混在
基幹システムのレガシーコードでは、構造体（`BASED`変数）の中で `VARYING` と `FIXED DECIMAL` が隣接しているケースが多い。
/i
DCL 1 MY_STRUCT BASED(P_PTR),
2 FIELD_A CHAR(20) VARYING,
2 FIELD_B FIXED DEC(5,0);
ここで、`FIELD_A` の最大長を拡張しようと `CHAR(30)` に変更したとする。この時、`FIELD_B` のオフセットがずれることは誰もが予測する。しかし、多くのエンジニアが失念するのは、アライメント（境界調整）だ。
`FIXED DECIMAL` は半バイト単位でメモリを占有するため、コンパイラオプションの `ALIGN` / `UNALIGNED` 指定によって、予期せぬパディングバイトが挿入される。このパディングを見落としたまま Java 側の DTO を設計すると、EBCDICからバイナリへの変換時にフィールドのズレが発生する。
4. アーキテクトへの提言：極限の信頼性を求めて
マイグレーション先が Java であろうと C# であろうと、PL/Iの `VARYING` が持つ「長さ＋実体」という二階層構造を、DTO（Data Transfer Object）層で忠実に再現すべきではない。
- 推奨アプローチ: 移行先では `String` 型として扱うが、読み込み時に「先頭2バイトを長さに変換し、その分だけ読み取る」という専用のデシリアライザを噛ませる。
- 埋め込みSQL対策: DB2等のホスト変数として `VARYING` を使う際は、必ず `VARCHAR` として定義し、プリコンパイラが生成する「長さ情報付きインジケータ」を正しくハンドリングすること。これを怠ると、SQL実行時に値が意図せず切り詰められる（Truncation）現象が発生する。
最後に
`VARYING` は、かつてのエンジニアたちが「限られたメモリでいかに柔軟に文字列を扱うか」と苦闘した跡地である。その構造を理解することは、単なる過去の遺産のメンテナンスではない。システムの「急所」がどこにあるかを把握し、モダナイゼーションにおけるデータ不整合という最大の敵を封じ込めるための、不可欠な技術的教養なのだ。
コードを眺める時、その背後にある「16進数の先頭2バイト」を透視できるようになれば、君も一人前のメインフレーム・アーキテクトと言えるだろう。
