はじめに：PL/I可変長文字列の「幽霊バイト」が引き起こす夜間バッチの悲劇
メインフレームの現場において、PL/I（Programming Language One）という言語は、まるで熟成されたウイスキーのように、一筋縄ではいかない深い歴史と独自の哲学を持っています。C言語やJavaの感覚でコードを書いていると、コンパイラが裏側で巧妙に隠蔽している仕様の牙城に足元をすくわれる。その代表格が、今回取り上げる `SCALARVARYING` 属性です。
基幹システムの夜間バッチが突如として「S0C4アベンド」を吐き出し、スナップダンプの海に沈む。原因を辿っていくと、COBOLから移行してきた文字列バッファや、オープン系（Java/C#）との間でJSONやバイナリを直接やり取りするインターフェースにおいて、可変長文字列（`VARYING`）の先頭に付く「見えない2バイト（長さフィールド）」の解釈違いに行き着く――。
今回は、PL/Iの識別子や予約語の緩やかな制約という懐の深さの裏に潜む、メモリ管理の極限領域、そしてマイグレーション現場でエンジニアを悩ませる `SCALARVARYING` の深淵へと踏み込んでいきます。
—
1. `SCALARVARYING` 属性の正体とメモリレイアウトの物理構造
PL/Iの `CHARACTER VARYING`（または `CHAR(n) VARYING`）変数を宣言した場合、デフォルトのスカラデータであれば、コンパイラは内部的に「実際の文字列長を格納する2バイトのプレフィックス（半精度整数：HFP）」と「データ本体」をセットで割り当てます。
しかし、この挙動は、外部のミドルウェア（DB2のVARCHAR列、CICSのCOMMAREA、あるいは他言語でビルドされたCの構造体）とデータをバイナリレベルで直結する際に、致命的なズレを生む原因となります。
ここで重要になるのが `SCALARVARYING` コンパイラオプションおよび属性指定です。
1
/ 典型的なVARYING変数の宣言と内部構造のイメージ /
DCL 1 EXT_RECORD,
3 DATA_LEN FIXED BIN(15), / 長さ保持領域（明示的に持たせる場合） /
3 DATA_BODY CHAR(100) VARYING; / VARYING属性 /
PL/Iのランタイムライブラリは、`VARYING` 変数に値を代入する際、自動的に先頭2バイトへ文字列の長さをビッグエンディアン（System/390のアーキテクチャに準拠）で書き込みます。
しかし、C言語の `char` や、Javaの `String`（UTF-16やプレフィックスなしのUTF-8/Shift-JIS）とデータを共有する場合、この先頭の2バイトが「ゴミデータ」または「不正な文字コード」として解釈され、深刻なデータ化けやトランザクション異常を引き起こすのです。
—
2. ベース変数とポインタを用いた動的メモリ操作のエッジケース
マイグレーションやレガシーシステムのチューニングにおいて、しばしば `ADDR` 組み込み関数とポインタを用いた低水準のメモリアクセスが行われます。ここで `SCALARVARYING` の挙動を誤認していると、メモリー破壊（Storage Violation）を引き起こします。
以下の実用的なコード例を見てください。ここでは、ポインタを用いて可変長文字列のプレフィックス領域を直接覗き込み、他言語連携用のストリームを組み立てる処理を模しています。
1
/ ================================================================= /
/ プログラム名: VARYINGSTR – SCALARVARYING制御とポインタ操作サンプル /
/ ================================================================= /
VARYINGSTR: PROC OPTIONS(MAIN);
/ 宣言部 /
DCL RAW_BUFFER CHAR(256) BASED(BUF_PTR);
DCL BUF_PTR POINTER;
/ VARYING文字列の宣言 /
DCL MSG_VARYING CHAR(100) VARYING;
DCL 1 WORK_AREA,
5 PREFIX_L FIXED BIN(15), / 長さ格納用 /
5 REAL_STR CHAR(100); / 実データ本体 /
DCL WORK_PTR POINTER;
DCL I FIXED BIN(31);
/ 1. 通常のVARYING代入 /
MSG_VARYING = ‘IBM ENTERPRISE PL/I ARCHITECTURE’;
/ 2. アドレスと先頭2バイト（長さ）の確認 /
WORK_PTR = ADDR(MSG_VARYING);
/ 注意: VARYING変数のポインタをそのまま指すと、先頭2バイトの長さ領域を指す /
DISPLAY(‘— VARYING MEMORY INSPECTION —‘);
DISPLAY(‘格納文字列長: ‘ || LENGTH(MSG_VARYING));
/ 3. 他言語（C言語等）の構造体へ安全にデータを転送するためのパッキング処理 /
/ プレフィックスの長さを明示的にWORK_AREAに分解する /
PREFIX_L = LENGTH(MSG_VARYING);
REAL_STR = MSG_VARYING; / コンパイラがデータ部のみを適切にコピー /
/ バッファポインタを使ったダンプ出力シミュレーション /
BUF_PTR = ADDR(WORK_AREA);
DISPLAY(‘転送用バッファ先頭2バイトの整数値(HFP): ‘ || PREFIX_L);
END VARYINGSTR;
このコードにおける最大のポイントは、`ADDR(MSG_VARYING)` が返すポインタが、データ本体の先頭ではなく、長さを示す2バイトのプレフィックスを指しているという点です。
これを意識せずに、C言語側の構造体ポインタにそのまま代入したり、DB2のホスト変数として誤ったオフセットでバインドすると、DB2側でSQLCODE -303（データ型変換エラー）や、最悪の場合はメインフレームのハードウェア例外（S0C4）による異常終了を招きます。
—
3. コンパイラオプションとマイグレーション時の罠
Enterprise PL/Iコンパイラを使用する際、文字列の扱いに関するオプション（例えば `ASCII` / `EBCDIC` の混在環境や、ストリングの長さを表す記述子の有無）は多岐にわたります。
JavaやC#へのマイグレーションプロジェクトにおいて最もエンジニアを悩ませるのが、「PL/Iが暗黙的に付加する記述子（Descriptor）と可変長プレフィックスの脱着」です。
1. CALL時の引数渡しの罠:
サブプログラムへ `CHAR VARYING` を `BY REFERENCE`（デフォルト）で渡す場合、PL/Iは「長さプレフィックスを含む領域へのポインタ」を渡します。これを移植先のJava（JNI経由）やC言語で受ける際、C側で `char` として受け取ると、最初の2バイトが文字化け（制御文字の混入）を起こします。
2. 対策としての `NONVARYING` への強制変換:
他言語連携やファイル出力（QSAMなど）を行うレコード定義では、極力 `VARYING` 属性を排除し、パディング（空白埋め）を前提とした `CHAR(n)`（固定長）へリファクタリングすることが、移行リスクを最小化する鉄則です。
—
4. アベンド（ABEND）発生時のダンプ解析とエッジケース
深夜、運用担当者から「U4038アベンド（またはS0C4）が発生し、バッチが異常終了した」との一報が入る。スナップダンプ（Sysdump）を広げ、ストレージプールを睨みつける時、`SCALARVARYING` の不整合は以下の兆候として現れます。
- 兆候1: 制御ブロックの破壊
ポインタ演算のミスにより、`VARYING` 変数の先頭2バイトの長さフィールドに、文字データ（EBCDICの文字コード）が直接上書きされてしまったケース。PL/Iのランタイムは次にその変数が参照された際、長さとして異常な巨大数値（例: `X’4040’` = 16448）を読み込み、メモリの範囲外（Storage Violation）へアクセスしてS0C4を引き起こします。
- 兆候2: 埋め込みSQL（DB2）におけるエッジケース
DB2の `VARCHAR` 列に対して、PL/I側の `CHAR(n) VARYING` ホスト変数をそのまま使用する場合、前述の通りPL/Iは先頭2バイトに長さを保持するためDB2との親和性は一見高いです。しかし、ストアドプロシージャとの間でC言語製のモジュールを挟むと、この2バイトのエンディアンやオフセットの解釈違いにより、SQLCODE -803やデータ切り捨てエラーが頻発します。この場合、コンパイル時にプリコンパイラオプションやホスト変数の構造体定義を見直し、明示的な長さ制御を行わせる必要があります。
—
おわりに：レガシーの構造美を理解し、次世代へ継承する
PL/Iという言語は、その自由度の高さゆえに「書いた人の数だけ書き方がある」と言われることがあります。しかし、その根底にあるメモリ管理の哲学――ハードウェアのアーキテクチャと密接に結びついたデータ表現の妙――を理解せずして、真のレガシー移行やモダナイゼーションを成功させることはできません。
`SCALARVARYING` が司るたった2バイトのプレフィックス。その挙動を完璧に掌握し、メインフレームの堅牢性とオープン系システムの柔軟性を橋渡しすることこそが、我々システムアーキテクトに課された使命です。
次回の夜間バッチでダンプと対峙した時、この記事があなたのデバッグの羅針盤となることを確信しています。
