1. 導入：なぜVARYINGの管理が重要なのか
メインフレームのCOBOLやPL/I開発において、可変長文字列（VARYING）はメモリ効率と処理速度を両立させるための必須技術です。しかし、JavaやPythonなどのオープン系言語に慣れたエンジニアにとって、「最大長（p）」と「現行長（q）」の概念は混乱の元になりがちです。本稿では、この2つの属性を正しく理解し、バッファオーバーフローやデータ切り捨てを防ぐための実務的なTipsを解説します。
2. 基礎知識：VARYINGの仕組み
VARYING宣言を行うと、コンパイラは内部的に「文字列の現行長を保持する領域」と「実際のデータ領域」を確保します。
・p（最大長）：メモリ上に確保される物理的な最大サイズです。一度宣言すると変更できません。
・q（現行長）：現在格納されているデータの長さです。代入操作のたびにシステムが自動的に更新します。
例えば、DCL S CHAR(100) VARYINGの場合、最大100バイトまで格納可能ですが、’HELLO’を代入した瞬間、qは5になります。このqを意識せずに固定長と混同して扱うと、予期せぬデータ欠損を招く恐れがあります。
3. 実装と解決策
実務では、MOVE命令や代入を行う際、受取側の最大長（p）を超過しないか、あるいは送信側の現行長（q）が意図した値かを確認する必要があります。特に外部システムとの連携時や、DBへの一括ロード時には、以下の論理フローを徹底してください。
1. バリデーション：送信側の現行長が受信側の最大長を超えていないか事前にチェックする。
2. 切り捨て制御：あえて切り捨てる場合は、明示的にサブストリング関数等を使用し、仕様として明文化する。
3. 長さの再計算：連結処理などを行った場合、必ずLENGTH関数で現行長を再取得する。
4. サンプルプログラム（PL/I準拠）
以下に、現行長を意識した安全な代入処理のサンプルコードを提示します。
/ 最大長100のVARYING変数 /
DCL DATA_IN CHAR(200) VARYING;
DCL DATA_OUT CHAR(100) VARYING;
DCL WORK_LEN FIXED BIN(15);
/ 入力データの現行長を取得 /
WORK_LEN = LENGTH(DATA_IN);
/ 最大長(100)を超える場合は切り捨て、超えない場合はそのまま代入 /
IF WORK_LEN > 100 THEN DO;
/ 100文字に切り詰めて代入 /
DATA_OUT = SUBSTR(DATA_IN, 1, 100);
END;
ELSE DO;
/ そのまま代入（現行長も自動的に更新される） /
DATA_OUT = DATA_IN;
END;
/ 処理後の現行長を確認 /
PUT SKIP LIST(‘現在のデータ長は:’ || LENGTH(DATA_OUT));
5. 応用・注意点：オープン系移行時の罠
メインフレームからJava等へ移行する際、最も注意すべきは「最大長」という概念の消失です。JavaのStringクラスは可変長ですが、メインフレームの「CHAR(100) VARYING」という宣言が持っていた「100文字まで」という物理制約はプログラム側からは見えなくなります。
移行プロジェクトでは、メインフレーム側の宣言値をDBの桁数制限（VARCHAR(100)）と突き合わせ、ビジネスロジック層で必ずバリデーション関数を実装してください。これを怠ると、メインフレーム側ではエラーにならなかった「長すぎるデータ」がデータベースの桁溢れを引き起こし、基幹システム全体のデータ整合性を損なう重大なバグに直結します。
コメント