導入：なぜ「LIKE属性」の制約を知る必要があるのか
メインフレームのPL/I開発において、既存のデータ構造を再利用する際、LIKE属性は非常に強力なツールです。しかし、LIKE属性には「宣言時に属性を上書きできない」という重要な制約があります。この仕様を理解せずにコーディングを行うと、コンパイルエラーに直面するだけでなく、予期せぬデータ不整合を引き起こすリスクがあります。本稿では、この制約の意図と、安全な実装方法について解説します。
基礎知識：LIKE属性とは「クローン」である
LIKE属性は、ある変数のデータ構造をそのままコピーして新しい変数を作成する仕組みです。現代のプログラミング言語におけるクラスの「継承」と似ていますが、本質的には「クローン（複製）」です。
一度LIKEで定義すると、元の変数（テンプレート）が持つデータ型、配列サイズ、構造体定義がすべて引き継がれます。この厳格な制約があるからこそ、プログラム間でのデータ交換において、型の不一致を防ぎ、安全性を担保することが可能となっています。
実装：属性のオーバーライドは「禁止」されている
以下のコード例のように、LIKEを使って宣言した変数に対して、個別に属性（FIXED BINなど）を付与することはできません。
サンプルプログラム
/ 誤った宣言例 /
DCL OLD_REC CHAR(80);
/ 下記の宣言はコンパイルエラーとなります /
DCL NEW_REC LIKE OLD_REC FIXED BIN;
/ 正しい宣言例：テンプレートを修正し、必要であれば型を分ける /
DCL 1 TEMPLATE_STRUCT,
5 FIELD_A CHAR(10),
5 FIELD_B FIXED BIN(31);
/ 構造をそのまま利用する /
DCL NEW_DATA LIKE TEMPLATE_STRUCT;
/ 注意：もし型を変えたい場合は、LIKEを使わずに個別に定義し直すのが原則です /
DCL ALT_DATA CHAR(10);
DCL ALT_NUM FIXED BIN(31);
応用・注意点：テンプレート変更時の影響範囲
LIKE属性を使用する際の最大の注意点は、「テンプレート側を変更した時の波及効果」です。
1. 静的解析の徹底: テンプレートとなる構造体を変更した場合、その構造体をLIKEで参照している全モジュールを再コンパイルする必要があります。影響範囲がモジュールを跨ぐ可能性があるため、変更前には必ずクロスリファレンスツール等で影響範囲を洗い出してください。
2. 保守性の向上: 逆に言えば、共通定義体（Copybook）でテンプレートを一元管理していれば、ビジネスロジックの変更に合わせて一括でデータ構造を更新できるという大きなメリットがあります。
「LIKE属性は便利だが、変更には強い責任が伴う」という認識を持ち、大規模なデータ交換を行うシステムほど、テンプレートの管理を厳格に行うようにしましょう。
コメント