PL/I動的文字列のサイズ：LENGTH関数とSTG関数、その奥深き世界
PL/Iの世界に足を踏み入れた者ならば、一度は「可変長文字列（VARYING）のサイズをどうやって取得するのか？」という疑問に直面したはずだ。LENGTH関数とSTG関数。一見、似たような役割を持つこの二つの関数だが、その振る舞い、そして背後にあるメモリ管理の思想は、我々のようなメインフレームの骨格を理解しようとする者にとって、非常に興味深い示唆に富んでいる。特に、基幹システムのレガシー移行を任されるテックリードやシステムアーキテクトの諸氏にとっては、この違いを正確に把握することが、品質の高い移行設計、そして予期せぬアベンド（ABEND）との戦いを有利に進めるための鍵となる。
LENGTH関数：文字列の「現在地」を知る
まず、LENGTH関数だ。これは、VARYING属性を持つ文字列変数が、その瞬間に保持している文字数を返してくれる、非常に直感的で使いやすい関数である。
DCL MY_STRING VARCHAR(100) VARYING;
MY_STRING = ‘HELLO PL/I’;
PUT SKIP LIST(‘現在の文字列長: ‘ || LENGTH(MY_STRING));
このコードを実行すると、当然ながら「現在の文字列長: 8」と表示される。`VARCHAR(100)`で最大100文字を格納できる領域が確保されていても、LENGTH関数が教えてくれるのは、あくまで現在格納されている「実効長」に過ぎない。まるで、広大な倉庫に荷物を詰め込んでいる時、LENGTH関数は「今、この棚には何個の荷物が入っているか」を教えてくれるようなものだ。
STG関数：ストレージの「懐の深さ」を知る
一方、STG関数は、VARYING文字列変数が「割り当てられているストレージ全体」のサイズをバイト単位で返す。これは、LENGTH関数とは根本的に異なる情報だ。
DCL MY_STRING VARCHAR(100) VARYING;
MY_STRING = ‘HELLO PL/I’;
PUT SKIP LIST(‘割り当て済みストレージサイズ: ‘ || STG(MY_STRING) || ‘ バイト’);
このコードを実行した場合、VARYING文字列変数の内部構造を考慮すると、単に100バイトが返されるわけではない。VARYING属性の文字列変数は、実際には「現在の長さ」と「最大長」の情報を保持するためのオーバーヘッドを持つ。PL/Iのコンパイラ実装やバージョンによって多少の差異はあり得るが、一般的には、最大長を表す2バイト（または4バイト）の長さフィールドに加えて、実際の文字列データが格納される領域が確保される。したがって、上記の例では、例えば「102 バイト」（長さフィールド2バイト + 最大長100バイト）のような値が返されることになるだろう。
STG関数は、倉庫の「棚全体の広さ」に相当する。荷物の数に関わらず、その棚がどれくらいのスペースを持っているかを示しているのだ。
なぜ、この違いが重要なのか？ – レガシー移行の観点から
ここからが本題だ。LENGTH関数とSTG関数の違いは、単なる学術的な興味に留まらない。基幹システムの移行、特にJavaやC#といったモダンな言語へのマイグレーションにおいては、この二つの関数の挙動を正確に理解することが、ストレージ管理、パフォーマンスチューニング、そして何よりも「アベンドしない」移行を実現するための生命線となる。
1. 動的メモリ操作とポインタの罠
PL/Iでは、`BASED`変数とポインタを駆使することで、低レベルなメモリ操作が可能になる。VARYING文字列変数も、内部的にはポインタを介してストレージが管理されていると考えることができる。
DCL MY_STRING VARCHAR(100) VARYING BASED(P);
DCL P POINTER;
/ ここでMY_STRINGが指すメモリ領域を適切に確保・解放する必要がある /
/ 例: CALL MALLOC(ALLOC_SIZE) -> P = ADDR(ALLOCATED_AREA); /
/ 領域確保後 /
MY_STRING = ‘INITIAL DATA’;
PUT SKIP LIST(‘LENGTH: ‘ || LENGTH(MY_STRING)); / 現在のデータ長 /
PUT SKIP LIST(‘STG: ‘ || STG(MY_STRING)); / 確保された領域全体 /
JavaやC#では、ガベージコレクションがメモリ管理を代行してくれるが、PL/I、特にメインフレームの環境では、開発者が明示的にメモリを確保し、解放する必要がある場面も少なくない。`BASED`変数とポインタ、そして`ALLOCATE`や`FREE`といったステートメント（あるいはC言語ライクな`MALLOC`/`FREE`相当の組み込み関数）を組み合わせることで、柔軟なメモリ管理が可能になる。
この時、LENGTH関数で取得できるのは、あくまで「現在入っているデータ」のサイズだ。もし、このデータサイズに基づいて、後続の処理でメモリ領域の再配置やコピーを行おうとした場合、STG関数で取得できる「確保済みのストレージサイズ」を考慮しないと、データが溢れてしまったり、逆に無駄に大きな領域を確保し続けてしまったりする可能性がある。
2. コンパイラオプションと最適化の影
PL/Iコンパイラは、様々なオプションによってコードの振る舞いや最適化レベルを調整できる。例えば、`OPTIMIZE(n)`オプションは、コンパイラがどれだけ積極的にコードを最適化するかを制御する。
LENGTH関数やSTG関数がどのように展開されるかは、これらのコンパイラオプションに影響されることがある。あるオプション設定では、LENGTH関数がレジスタ操作だけで即座に値を取得できるのに対し、別の設定では、VARYING変数の内部構造を辿るための追加の命令が生成されるかもしれない。
移行作業においては、既存のPL/Iソースコードをそのままコンパイルするのではなく、ターゲット環境や目的に応じてコンパイラオプションを再検討する必要がある。その際、LENGTH関数やSTG関数といった、一見単純な関数であっても、その生成コードに違いが生じる可能性を念頭に置くべきだ。これは、パフォーマンスのボトルネックを見つけ出す際にも、あるいは移行後の予期せぬパフォーマンス低下の原因を特定する際にも、非常に重要な視点となる。
3. アベンド（ABEND）発生時のダンプ解析：STG関数の視点
基幹システムの現場で最も恐れられているのは、やはりアベンド（ABEND）だ。特に、データ破損やストレージ関連のエラーに起因するアベンドは、原因特定が困難を極める。
例えば、`FIXED OVERFLOW`や`STRING SIZE`といった例外が発生した場合、ダンプ（ dump ）を解析することになる。この時、VARYING文字列変数のサイズに関わる問題であれば、LENGTH関数とSTG関数の値は、問題の切り分けに決定的な役割を果たす。
- LENGTH関数の値が異常に大きい、あるいは期待値と異なる場合: 文字列操作のロジックに誤りがあり、本来格納されるべきでないデータが書き込まれている可能性がある。
- STG関数の値が、本来想定していた最大長よりも短い場合: メモリ確保の段階で問題が発生しているか、あるいはVARYING変数が本来持つべき領域が確保されていない可能性がある。
ダンプ解析では、コンパイラによって生成されたアセンブリコードを追いながら、変数のアドレスや値を確認していく。STG関数が返す「割り当て済みストレージサイズ」は、その変数が参照しているメモリ領域の「境界」を示す重要な手がかりとなるのだ。この境界を越えたアクセスが、アベンドの原因である可能性が高い。
4. パックデシマル（Packed Decimal）の内部符号反転バグとの連携
PL/Iでよく使われるパックデシマル（`PIC S9(n)V`など）には、内部符号の反転という、地味ながらも厄介なバグが存在しうる。これは、特定の演算やデータ変換の際に、符号ビットが意図せず反転してしまう現象だ。
VARYING文字列変数とパックデシマルを組み合わせた処理、例えば、文字列から数値を変換する際などに、このバグが顕在化することがある。LENGTH関数で取得した文字列長に基づいて、パックデシマルへの変換処理を行おうとした際に、もしその文字列が不正な符号情報を含んでいた場合、LENGTH関数はあくまで「文字数」しか返さないため、問題の発見が遅れる可能性がある。
一方、STG関数は、その文字列が占める「物理的な領域」を示す。この物理的な領域の中に、不正なパックデシマルデータが含まれている場合、STG関数が示すサイズと、そのデータとして期待されるサイズとの間に乖離が生じるかもしれない。ダンプ解析においては、この乖離を捉えることが、パックデシマル関連のバグを早期に発見する糸口となる。
5. 埋め込みSQL（DB2）とCICSオンライン処理のエッジケース
基幹システムがDB2データベースやCICSオンライン処理と連携している場合、VARYING文字列変数の扱いはさらに複雑になる。
- 埋め込みSQL: SQLステートメントにPL/IのVARYING文字列変数をバインドする際、ホスト変数として渡されるのは、通常「実効長（LENGTH関数で取得できる値）」とそのデータ本体である。しかし、データベース側でのデータ保存や、SQLエラーのメッセージ処理などにおいては、その変数が本来持てる「最大長（STG関数から推測される領域サイズ）」を考慮する必要が出てくる。例えば、DB2のVARCHAR型カラムにデータをINSERTする際、PL/I変数の実効長がカラムの最大長を超えていなくても、STG関数で示される領域全体に不正なデータが含まれていると、予期せぬエラーを引き起こす可能性がある。
- CICSオンライン処理: CICS環境では、画面定義（DBCS、 BMS ）やトランザクション間でのデータ受け渡し（COMMAREA、Channel）において、フィールド長が厳密に定義されている。VARYING文字列変数をこれらのインターフェースで使用する場合、LENGTH関数で取得した実効長が、画面定義やCOMMAREAの定義長を超えないように注意する必要がある。さらに、COMMAREAなどの動的なデータ領域の管理において、STG関数が示す「確保済みストレージサイズ」を意識したプログラミングが求められる場面もある。例えば、COMMAREAのサイズを動的に変更しながらデータをやり取りする場合、STG関数で現在の領域サイズを把握し、必要に応じて領域の再確保やデータコピーを行うといった設計が考えられる。
まとめ：信頼性向上のための「両輪」
LENGTH関数とSTG関数。これらは、PL/Iにおける動的文字列のサイズを扱う上で、まさに「両輪」のような関係にある。LENGTH関数は「現在地」、STG関数は「懐の深さ」。どちらか一方だけを見ていては、システムの全体像を見誤る可能性がある。
レガシー移行においては、既存のPL/Iコードの挙動を正確に理解し、それをターゲット言語の機能にマッピングしていく必要がある。この際、VARYING文字列変数のサイズに関する問題は、データ破損、パフォーマンス劣化、そしてアベンドといった、移行プロジェクトの成否を左右する重大なリスクとなりうる。
- LENGTH関数: 現在のデータサイズを正確に把握し、ロジックの妥当性検証や、データ変換処理の基盤とする。
- STG関数: 確保されているメモリ領域全体を把握し、ストレージリークの防止、バッファオーバーフローの回避、そしてポインタ操作における境界チェックの設計に役立てる。
これらの関数を深く理解し、適切に使い分けることは、単にPL/Iのテクニックを習得することに留まらない。それは、メインフレームという巨大なシステムが、いかにして長年にわたって高い信頼性を維持してきたのか、その本質に触れる行為でもある。我々システムアーキテクトは、この知識を武器に、より堅牢で、より効率的な、そして何よりも「安心」できるシステムを次世代へと引き継いでいく責務があるのだ。
