【PL/I学習｜豆知識】メインフレーム技術者の知恵袋：PL/I構造体におけるアスタリスク()指定の活用術

未分類

2026.06.11

導入：なぜ「名前なし」の定義が重要なのか

メインフレームのレガシーシステムを保守していると、ファイル定義や通信電文の構造体の中に、奇妙な「（アスタリスク）」を見かけることはありませんか？これは単なる記述ミスではなく、PL/Iにおいて「物理的な領域は確保するが、プログラムからはアクセスさせない」ことをコンパイラに明示する重要なテクニックです。このTipsを知ることで、予約領域の管理を厳格化し、意図せぬデータ書き換えリスクを未然に防ぐことができます。

基礎知識：構造体とアスタリスクの役割

PL/Iの構造体（STRUCTURE）は、複数のデータをひとまとめにして扱うための仕組みです。通常、各要素には「名前（メンバ名）」を付けますが、ファイルフォーマットの仕様書には「予備（Reserved）」という領域がしばしば登場します。
この時、ダミー変数名（例：dummy01）を付けてしまうと、プログラマが誤ってその領域に値を代入できてしまいます。一方、アスタリスクをメンバ名に指定すると、コンパイラはその領域へのアクセスを構文エラーとして弾くため、プログラムレベルでの「参照不可」を強力に保証できるのです。

実装と解決策：安全な予約領域の確保

実装は非常にシンプルです。構造体宣言の中で、メンバ名を記述すべき場所にアスタリスクを置くだけです。これにより、データ構造の物理的な位置（オフセット）を維持しつつ、安全性を高めることができます。

サンプルプログラム

以下のコードは、電文定義などで予約領域を設ける際の標準的な書き方です。

/ 構造体定義例 /
DCL 1 RECORD_HEADER,
    2 TRANS_ID    CHAR(4),  / 取引ID /
    2 SEQ_NO      FIXED BIN(15), / シーケンス番号 /
    2            CHAR(10), / 予約領域：外部からアクセス不可 /
    2 STATUS_CODE CHAR(1);  / ステータス /

/ 以下の記述はコンパイルエラーとなるため、誤操作を防止できる /
/ RECORD_HEADER. = '1234567890'; /

応用・注意点：現場での運用と落とし穴

このテクニックを活用する上で、現場技術者が特に注意すべき点が一つあります。それは「DEFINED属性」を使った参照の有無です。
過去の古いプログラムでは、予約領域の先頭アドレスを基準にして別の変数を定義（DEFINED）し、裏道的にデータにアクセスしているケースが稀にあります。現代風のコードにリプレイスする際、単に「アスタリスクだから不要だろう」と削除してしまうと、既存のDEFINED変数がずれてしまい、深刻なバグを引き起こす可能性があります。
修正を行う際は、対象の構造体全体を検索し、DEFINEDによるメモリのオーバーレイが行われていないかを必ず確認してください。名前を付けないことは「アクセスを遮断する」という強力な設計意図があることを忘れないようにしましょう。