導入：なぜ「物理長」の把握が必要なのか
メインフレーム開発において、COBOL等の言語で定義した数値型が「メモリ上で何バイトを占有しているか」を正確に把握することは、システム間連携の要です。特に、バイナリ電文のパース、ファイルI/Oのバッファ制御、あるいは現代的な外部システムとのデータ連携を行う際、ハードコードされたマジックナンバー（例：PIC S9(7) COMP-3 だから4バイト、といった決め打ち）は、仕様変更時のバグの温床となります。本稿では、STORAGE関数を用いた動的な物理長取得と、算術データ特有の考慮点について解説します。
基礎知識：算術データと物理表現のギャップ
メインフレーム（z/OS等）で扱われる算術データは、定義上の「桁数（精度）」と、メモリ上の「物理長（バイト数）」が必ずしも一致しません。
例えば、COMP-3（パック10進数）の場合、占有バイト数は「(桁数 + 1) / 2」の切り上げで決まります。また、DISPLAY形式であれば1桁1バイトとなるなど、型指定によってメモリレイアウトが大きく異なります。STORAGE関数は、これらコンパイラが計算した「実行時の物理的占有サイズ」をプログラム側から動的に問い合わせるための強力なメタ情報取得手段です。
実装：STORAGE関数の活用
STORAGE関数は、引数に指定した変数の現在の物理サイズをバイト単位で返します。これにより、レコード長が可変である場合や、動的にメモリを確保する際のサイズ計算を自動化できます。
サンプルプログラム：物理長取得の実践
以下に、PL/Iを用いた物理長取得のサンプルコードを提示します。COBOL環境では、同様のロジックをコンパイル時のデータレイアウト情報や、ポインタ演算を用いたユーティリティで実装するのが一般的です。
/ PL/I サンプル：変数の物理長を取得してパース処理に利用する /
DCL MY_DATA FIXED DEC(7) COMP-3; / 7桁のパック10進数 /
DCL LEN FIXED BIN(31);
/ STORAGE関数を用いて、コンパイラが決定した物理サイズを取得 /
/ ハードコードを避けることで、型定義変更時の修正漏れを防ぐ /
LEN = STORAGE(MY_DATA);
PUT SKIP LIST(‘MY_DATAの物理長は: ‘ || LEN || ‘ バイトです’);
/ 応用例：バイナリデータのコピー /
/ 外部から受け取ったバッファに対して、型のサイズ分だけメモリ操作を行う /
IF LEN > 0 THEN DO;
/ ここに実際のメモリアクセスやパース処理を記述 /
/ 物理長を動的に取得することで、メンテナンス性が飛躍的に向上する /
END;
応用・注意点：現場で陥りやすい罠
1. アライメントとパディングの考慮
構造体（STRUCT）全体に対してSTORAGEを適用する場合、メンバ間のアライメント調整用パディングが含まれることに注意してください。電文パース等で「純粋なデータ部のみの長さ」が必要な場合は、個別のフィールドに対してSTORAGEを実行する必要があります。
2. 移行時の注意（REDEFINESとの兼ね合い）
REDEFINES句でメモリを重ねている場合、STORAGE関数が返すのは「その変数の定義上のサイズ」です。複数の型を重ねている箇所では、意図した方のサイズが正しく取得できているか、デバッグ時に必ずダンプを確認してください。
3. 算術演算との混同を避ける
STORAGEはあくまで「メモリ上の占有領域」を返すものであり、数値の「有効桁数（精度）」を返すものではありません。数値データを取り扱う際は、定義上の桁数（精度）を扱う関数と、物理長を扱うSTORAGE関数を明確に使い分けることが、堅牢なプログラム作成の第一歩となります。
コメント