なぜDESCRIPTOR属性が必要なのか？
メインフレームのCOBOLやPL/Iといった言語で開発をしていると、「呼び出し先で受け取るデータの長さが、実行のたびに変わる」という場面に遭遇します。例えば、ある時は10バイト、ある時は100バイトの文字列を処理する共通モジュールを作る場合、毎回ハードコーディングで長さを指定するのは現実的ではありません。
そこで活躍するのがDESCRIPTOR属性です。これを使うことで、呼び出し元からデータの「長さ」や「境界」といった情報を動的に渡し、プログラム側で柔軟に制御できるようになります。
基礎知識：記述子（Descriptor）とは何か
通常、メインフレームのサブルーチンにデータを渡す際、メモリのアドレスだけを渡すと、受け取り側は「そのデータがどこまで続くのか」を知ることができません。
ここでいう「記述子」とは、プログラムがメモリ上のデータを正しく解釈するための「メタデータ（付加情報）」を指します。具体的には、文字列の長さや、配列の次元・境界といった情報です。DESCRIPTOR属性を宣言に含めることで、システムは引数と一緒にこの「長さ情報」を裏側で自動的に管理・伝達してくれるようになります。
実装のポイント
DESCRIPTOR属性を使用する場合、呼び出し側の宣言と、受け取り側の引数宣言の両方で、データの長さを「（アスタリスク）」や動的な値として指定します。これにより、コンパイラに対して「この引数には記述子が付随するから、よしなに処理してくれ」という指示を出すことになります。
サンプルプログラム（PL/I風の記述例）
以下は、任意の長さの文字列を受け取ってログ出力する共通ルーチンのイメージです。
/ 呼び出し側：任意の長さの文字列を渡す /
DCL MSG1 CHAR(10) INIT('HELLO');
DCL MSG2 CHAR(20) INIT('MAINFRAME WORLD');
CALL SUB_ROUTINE(MSG1);
CALL SUB_ROUTINE(MSG2);
/ 受け取り側：DESCRIPTOR属性を使用して動的な長さを扱う /
SUB_ROUTINE: PROC(IN_DATA);
/ CHAR() DESCRIPTOR で、渡されたデータの長さを自動で取得 /
DCL IN_DATA CHAR() DESCRIPTOR;
/ 内部で長さを利用して処理を分岐させる例 /
/ コンパイラがIN_DATAの長さを自動的に認識します /
PUT SKIP LIST('受け取ったデータの長さは: ' || LENGTH(IN_DATA));
END SUB_ROUTINE;
応用と注意点：バグを避けるために
現代のJavaやC#などの言語では、文字列の長さ（.length）はオブジェクトのプロパティとして簡単に取得できます。しかし、メインフレームの低レベルなロードモジュール連携では、この記述子を手動で扱う必要がある場合があります。
注意すべき点：
1. コンパイラの不一致: 呼び出し側と呼び出し先でDESCRIPTORの有無が食い違っていると、メモリのオフセットがずれてしまい、最悪の場合「データ例外（S0C7）」や予期せぬメモリアクセス違反を引き起こします。
2. 言語間連携: COBOLからPL/Iを呼ぶ際など、異なる言語間で連携する場合は、記述子の持ち方が言語仕様によって異なるため、仕様書を必ず確認してください。
DESCRIPTOR属性を正しく理解することで、コードの汎用性が劇的に向上し、修正に強いプログラムを作成できるようになります。ぜひ現場の共通モジュール設計で活用してみてください。
コメント