【実務・中級編】DECLAREレベル番号による構造体階層の定義とネスト制限 – PL/Iの基本構文とデータ制御実践ガイド

メインフレームの背骨を設計する:PL/I構造体と階層定義の「極意」

諸君、お疲れ様。今日も今日とてJCLの海に潜り、SYSOUTの山を掻き分けていることだろう。

PL/Iは、その柔軟性ゆえに「何でも書けてしまう」言語だ。だが、基幹システムの保守において、データレイアウトを司る「DECLARE文」の作法を誤ると、後々データ異常や予期せぬパディングに泣くことになる。今日は、PL/Iの構造体の基本、特にレベル番号の階層と、現場で必須となる`LIKE`属性を使った再利用性について、ベテランの視点から紐解いていこう。

1. 構造体の階層:レベル番号の「黄金律」

PL/Iではレベル1から255までの階層を作れる。だが、現場のコードで5階層を超えるような設計を見たときは注意が必要だ。それは大抵、設計の複雑化を招き、修正時のインパクト解析を困難にする。

1
/ 構造体定義の基本例 /
DCL 1 RECORD_AREA,
2 HEADER,
3 REC_TYPE CHAR(4),
3 PROC_DATE FIXED BIN(31),
2 DETAIL,
3 DATA_COUNT FIXED BIN(15),
3 ITEM_LIST(10), / 10要素の配列 /
4 ITEM_CODE CHAR(8),
4 AMOUNT DEC FIXED(11,2);

レベル番号は、親よりも大きい数字を子に与える。このシンプルさがPL/Iの強みだ。ここで重要なのは、「メモリレイアウトは定義した順番通りに連続する」という原則だ。VSAMのI/Oバッファにマップする場合、この順序がそのままレコード構造と一致しなければならない。

2. LIKE属性で「車輪の再発明」を防ぐ

保守の現場で最も恐ろしいのは、似たような構造体をあちこちに別個に定義し、片方の修正を忘れて不整合を起こすことだ。ここで活用すべきが`LIKE`属性である。

`LIKE`を使えば、既存の構造体定義をそっくりそのままコピーできる。これは単なるコードの再利用ではない。「データレイアウトの正当性を担保する」ための強力な武器だ。

1
/ 共通コピーブック(INCLUDEメンバー)で定義された構造体 /
/ 以下の定義は別メンバーに存在すると仮定 /
/ DCL 1 COMMON_HEADER_TEMPLATE, … /

DCL 1 TRANSACTION_A,
LIKE COMMON_HEADER_TEMPLATE, / ヘッダー部分は共通化 /
2 DETAIL_INFO CHAR(100);

DCL 1 TRANSACTION_B,
LIKE COMMON_HEADER_TEMPLATE, / これでヘッダーの整合性は100%保証される /
2 DETAIL_INFO CHAR(200);

もしヘッダーに変更があった場合、テンプレートを直せばすべての構造体が追従する。これは大規模バッチ改修における「修正漏れ」を物理的に封じ込める、賢いエンジニアのやり方だ。

3. VSAMアクセスとONユニットの連携

VSAMから読み込んだレコードを構造体にマッピングする際、構造体の定義と実際のレコード長が一致していないと、悲惨な結末が待っている。

ここで役立つのが`ONCODE`と`ONCOND`だ。エラーが起きた際に「どこで」「何が」起きたかを特定するために、構造体操作とエラーハンドリングをセットで覚えておく必要がある。

1
/ VSAMレコード読み込み時の構造体制御 /
READ FILE(VSAM_FILE) INTO(RECORD_AREA);

/ エラー発生時に詳細を出力して異常終了させる(ONユニット) /
ON CONDITION(IO_ERROR) BEGIN;
PUT SKIP LIST(‘!!! VSAM IO ERROR !!!’);
PUT SKIP LIST(‘ONCODE: ‘, ONCODE());
STOP;
END;

現場のエンジニアへ:デバッグのコツ

最後に一つ、現場で役立つ知恵を授けよう。

構造体のオフセットを調べるために、`ADDR`組み込み関数と`STORAGE`組み込み関数を使いこなしてほしい。特に、複雑なネスト構造を持つ巨大な構造体で「なぜかデータがずれる」という事象に遭遇した際、各メンバの先頭アドレスを計算して比較すれば、コンパイラが挿入した暗黙のパディング(アライメント調整)が一目瞭然になる。

  • POINT: `ALIGNED` と `UNALIGNED` の違いを意識せよ。デフォルトはコンパイラオプションに依存するが、VSAM等の固定長ファイルとのマッピングなら `UNALIGNED` を明示するのが基幹系では定石だ。

PL/Iは古い言語と言われるが、その堅牢なデータ制御能力は、現代の疎結合なシステム設計においても色褪せることはない。コードの一行一行が、大規模システムの安定稼働を支えていることを忘れないでくれ。

何か不明点があれば、またいつでも聞いてくれ。現場からは以上だ。

タイトルとURLをコピーしました