PL/Iポインタの深淵へようこそ！ 型キャストの真実とアライメントの落とし穴
皆さん、こんにちは！ 最先端の技術を追いかける傍ら、基幹システムの心臓部で脈々と動き続けるIBMメインフレームの世界へようこそ。JavaやCOBOLのコードをバリバリ書いてきた皆さんにとって、PL/I（ピーエル・ワン）は少し古めかしく映るかもしれませんね。でも、ご安心ください。その「古さ」の中には、現代の言語設計にも通じる奥深さと、そして何より「現場の知恵」がぎっしり詰まっているんです。
今回は、そんなPL/Iの魅力の一端、特に「ポインタの型変換とCASTの概念」、そして「アライメントの罠」という、ちょっと玄人好みのテーマに挑んでいきましょう。難しそうに聞こえるかもしれませんが、一つずつ紐解けば「なるほど！」と膝を打つこと間違いなしです。怖がらないでくださいね、私がしっかりと寄り添ってご案内しますから！
—
1. 「ポインタ」って聞くと身構えちゃいますよね？ PL/Iにおけるその実体とは
Javaの世界では「参照型」として、あるいはC/C++の世界では「ポインタ」として、メモリ上の番地を直接扱う概念は皆さんにもお馴染みですよね。PL/Iにも、もちろんポインタが存在します。
PL/Iのポインタは、メモリ上の特定の場所を指し示す「番地情報」そのものです。他の言語との大きな違いは、PL/Iのポインタ変数自体は、それが「何を指し示すか」という型情報を持たない、という点にあります。まるで、ただのメモ書きに書かれた「住所」のようなものですね。その住所に何が建っているか（どんなデータがあるか）は、また別の話なんです。
じゃあ、どうやってその住所の先にあるデータを使うの？ と思いますよね。そこで登場するのが、PL/I独特の概念であるBASED変数です。
PL/I
DCL PTR_ADDR POINTER; / ポインタ変数の宣言。ただの「住所」を格納します /
DCL 1 MY_DATA BASED(PTR_ADDR), / PTR_ADDRが指し示す場所にあるデータ構造 /
2 FIELD_A FIXED BINARY(31),
2 FIELD_B CHAR(10);
この例だと、`PTR_ADDR`が指し示すメモリ領域を、`MY_DATA`という構造体として「見る」ことができます。`BASED(PTR_ADDR)`という記述が、「この構造体は`PTR_ADDR`が示すメモリ上に展開されているものとみなすよ」という意味なんです。
まるで、一つの土地（メモリ領域）に対して、用途に応じて「住宅地図」を用意したり、「商業施設案内図」を用意したりするようなイメージですね。PL/Iでは、この`BASED`変数を使って、ポインタが指す同じメモリ領域を、異なるデータ型として「見立てる」ことで、実質的な型変換（キャスト）を実現します。C/C++のように`(`型名`)`という明示的なキャスト演算子がないのがPL/I流なんですね。
—
2. なぜ異なる型へのマッピングが必要になるの？ レガシーシステムの現場事情
「そもそも、なんでそんなトリッキーなことしなきゃいけないの？」
ごもっともな疑問です。現代のプログラムでは、型安全性を高めるために、安易な型変換は避ける傾向にありますよね。でも、メインフレームのレガシーシステム、特に基幹業務のバッチ処理なんかでは、これが非常に重要なテクニックになる場面が多々あるんです。
想像してみてください。何十年も前に設計されたデータファイルやデータベースのレコード。そこには、容量や処理速度の制約から、非常に効率的（かつ複雑）な方法でデータが詰め込まれています。
- 例えば、1つの論理レコードの中に、取引種別によって異なるデータ構造が重なって格納されている。COBOLでいう`REDEFINES`句のオンパレード、みたいなイメージですね。
- あるいは、外部システムから受け取ったデータが、固定長ながら複数の異なるフォーマットを内包している。
- 通信バッファの中身を、特定のプロトコルヘッダとして解釈したり、その後ろのペイロードを別のデータ構造として解釈したり。
これら全て、同じメモリ領域を、その時々で異なるデータ構造として「解釈し直す」必要があるケースです。PL/Iでは、ポインタと`BASED`変数を使うことで、これを非常に柔軟に、そして効率的に実現できるんですね。
—
3. アライメントの罠、これが今日の主役です！
さて、ポインタと`BASED`変数で自由自在にデータの見方を変えられるのは便利です。でも、ここに「アライメント」という、ちょっとした落とし穴が潜んでいます。
3.1. アライメントって何？
アライメント（Alignment）とは、メモリ上にデータを配置する際の「整列ルール」のことです。CPUは、メモリからデータを読み書きする際、常に1バイトずつアクセスするわけではありません。多くの場合、2バイト、4バイト、8バイトといったまとまり（ワード）で効率的にアクセスします。
例えば、4バイトの整数データ（`FIXED BINARY(31)`など）を読み込む場合、CPUはメモリ上の番地が4の倍数になっている場所（0番地、4番地、8番地…）から読み込みたい、と考えるのが一般的です。もしデータが4の倍数ではない番地（例えば1番地）に配置されていたら、CPUは2回メモリにアクセスしたり、余計なシフト操作をしたりして、処理効率が落ちてしまう可能性があります。
このような理由から、多くのプログラミング言語やCPUアーキテクチャでは、データ型に応じて「このデータ型は〇バイト境界に配置してね」というアライメントルールが定められています。
- COBOLの`SYNCHRONIZED`句を覚えていますか？ あれはまさに、アライメントを意識してデータを特定の境界に整列させるための指示でしたよね。
- Javaの世界では、JVMがメモリ管理を行うため、開発者が直接アライメントを意識することは稀ですが、それでも内部的には特定のルールに従ってオブジェクトが配置されています。
3.2. PL/Iのアライメントルールと属性
PL/Iにも、もちろんアライメントルールがあります。データ型によってデフォルトのアライメントが決まっていますが、特に重要なのは以下の属性です。
- `ALIGNED`: そのデータが、システムのデフォルトアライメントルールに従ってメモリ上に配置されることを示します。例えば、`FIXED BINARY(31)`なら4バイト境界、`FIXED BINARY(15)`なら2バイト境界など。
- `UNALIGNED`: そのデータが、アライメントルールを無視して、直前のデータのすぐ後に配置されることを示します。つまり、1バイト境界に配置されます。
PL/Iの構造体（`STRUCTURE`）のメンバーは、デフォルトでは`ALIGNED`です。しかし、構造体宣言に`UNALIGNED`属性を付けると、その構造体のすべてのメンバーは`UNALIGNED`として扱われ、隙間なく詰め込まれることになります。
PL/I
/ 例：アライメントのデフォルトとUNALIGNED /
DCL 1 ALIGNED_DATA, / デフォルトはALIGNED /
2 F1 CHAR(1), / 1バイト /
2 F2 FIXED BINARY(15); / 2バイト境界に配置されるため、F1の後に1バイトのパディングが入る /
/ メモリレイアウトイメージ: [F1][パディング][F2_バイト1][F2_バイト2] /
DCL 1 UNALIGNED_DATA UNALIGNED, / UNALIGNEDを指定 /
2 F1 CHAR(1), / 1バイト /
2 F2 FIXED BINARY(15); / F1の直後に配置される /
/ メモリレイアウトイメージ: [F1][F2_バイト1][F2_バイト2] /
3.3. ポインタとBASED変数で型を「キャスト」する際のアライメントの罠
さて、本題です。ポインタと`BASED`変数を使って、あるメモリ領域を異なるデータ型として見立てる際、このアライメントが思わぬトラブルの元になることがあります。
具体例で見てみましょう。
外部ファイルから読み込んだ固定長レコード`INPUT_RECORD`があるとします。このレコードは`UNALIGNED`で、バイト単位でぎっしりデータが詰まっています。
PL/I
DCL 1 INPUT_RECORD UNALIGNED, / 外部ファイルから読み込んだ生データ（UNALIGNED） /
2 HEADER_INFO CHAR(10),
2 DATA_TYPE CHAR(1), / データ型を示すフラグ /
2 RAW_DATA CHAR(20); / 可変データ部分（20バイト） /
DCL P_RAW_DATA POINTER; / RAW_DATAの先頭を指すポインタ /
/ DATA_TYPEによって、RAW_DATA部分を異なる構造体として見たい /
DCL 1 DATA_FORMAT_A BASED(P_RAW_DATA) ALIGNED, / タイプAのデータ構造（ALIGNED） /
2 ID_NUM FIXED BINARY(31), / 4バイト整数、4バイト境界に配置したい /
2 NAME CHAR(16);
DCL 1 DATA_FORMAT_B BASED(P_RAW_DATA) UNALIGNED, / タイプBのデータ構造（UNALIGNED） /
2 ITEM_CODE CHAR(5),
2 QUANTITY FIXED BINARY(15); / 2バイト整数、1バイト境界に配置 /
/ メイン処理の一部 /
READ FILE(INPUT_FILE) INTO(INPUT_RECORD);
P_RAW_DATA = ADDR(INPUT_RECORD.RAW_DATA); / RAW_DATAの先頭アドレスをポインタに設定 /
IF INPUT_RECORD.DATA_TYPE = ‘A’ THEN DO;
/ ここで注意！ DATA_FORMAT_AはALIGNEDだが、P_RAW_DATAが指す場所はUNALIGNEDなRAW_DATAの途中 /
/ ID_NUMが4バイト境界にない場合、データ破壊やON ERROR条件の発生原因に！ /
PUT SKIP LIST(‘Type A ID:’, DATA_FORMAT_A.ID_NUM);
END;
ELSE IF INPUT_RECORD.DATA_TYPE = ‘B’ THEN DO;
/ こちらはDATA_FORMAT_BもUNALIGNEDなので安全 /
PUT SKIP LIST(‘Type B Item Code:’, DATA_FORMAT_B.ITEM_CODE);
END;
この例の`IF INPUT_RECORD.DATA_TYPE = ‘A’ THEN DO;` の部分が危険です。
`INPUT_RECORD`全体は`UNALIGNED`です。`HEADER_INFO`が10バイト、`DATA_TYPE`が1バイトなので、`INPUT_RECORD.RAW_DATA`は`INPUT_RECORD`の先頭から11バイト目の位置（オフセット10）から始まります。
もし`INPUT_RECORD`自体がメモリの0番地から配置されていたとすると、`RAW_DATA`は10番地からスタートします。
そして、`P_RAW_DATA`は10番地を指します。
ここで`DATA_FORMAT_A BASED(P_RAW_DATA) ALIGNED`として、`DATA_FORMAT_A.ID_NUM`にアクセスしようとします。`ID_NUM`は`FIXED BINARY(31)`なので、デフォルトで4バイト境界に配置されるべきデータ型です。しかし、`P_RAW_DATA`が指すのは10番地、これは4の倍数ではありません！
このような状況で`DATA_FORMAT_A.ID_NUM`にアクセスしようとすると、OSやPL/Iランタイムがアライメント違反を検知し、`ON ERROR`条件が発生してプログラムが異常終了したり（`STORAGE`条件が発生することも多いです）、あるいは意図しないゴミ値を読み込んでしまう（データが化ける）可能性があります。特に後者の場合、デバッグが非常に困難になります。
これが、PL/IのポインタとBASED変数を使った型変換における、アライメントの最も典型的な「罠」なんです。
—
4. トラブルシューティングの現場から：あの時、データが化けた理由
かつて私が遭遇した忘れられない事例があります。
あるバッチプログラムで、複雑な構造を持つレコードを読み込み、その一部を別の構造体として解釈して処理する部分がありました。テストデータでは問題なく動いていたのに、本番データで特定のレコードが来ると、急に処理がおかしくなり、最終的には異常終了するという現象です。
データの内容をダンプしてみると、本来数値であるべきフィールドが、まるで意味のない文字になっていました。「データが化けている！」と大騒ぎになり、原因究明に何日もかかりました。
最終的に判明したのは、まさに今回お話ししたアライメント違反でした。
問題のレコードは、データ構造の途中に`UNALIGNED`な`CHAR`型のフィールドが連続しており、その後に`ALIGNED`であるべき`FIXED BINARY`型のフィールドが続く、というものでした。`BASED`変数を使ってその`FIXED BINARY`フィールドを直接参照しようとした際に、参照元のアドレスがそのフィールドが本来要求するアライメント境界に合致していなかったのです。
デバッグの際には、`UNSPEC`組込み関数が非常に役立ちます。`UNSPEC(変数名)`とすると、その変数のメモリ上のバイト列をそのまま見ることができます。怪しい変数のバイト列をダンプし、想定している値と実際のバイト列を比較することで、「ああ、読み込み開始位置がズレているんだな」と気づくことができます。
PL/I
/ 例：UNSPECでメモリの内容を確認する /
DCL MY_VARIABLE FIXED BINARY(31);
MY_VARIABLE = 12345;
PUT SKIP LIST(‘MY_VARIABLE:’, MY_VARIABLE);
PUT SKIP LIST(‘UNSPEC(MY_VARIABLE):’, HEX(UNSPEC(MY_VARIABLE))); / メモリ上のバイト列を16進数で表示 /
—
5. じゃあどうすればいいの？ ポインタとBASED変数で安全に型を操る
このアライメントの罠を回避し、安全にポインタと`BASED`変数で型を操るには、いくつかの方法があります。
5.1. `UNALIGNED`属性を適切に使う
最も確実なのは、`BASED`変数で参照する構造体も、参照元のデータが`UNALIGNED`なのであれば、それに合わせて`UNALIGNED`属性を付けることです。
PL/I
/ INPUT_RECORDはUNALIGNED /
DCL 1 INPUT_RECORD UNALIGNED,
2 HEADER_INFO CHAR(10),
2 DATA_TYPE CHAR(1),
2 RAW_DATA CHAR(20);
DCL P_RAW_DATA POINTER;
/ DATA_FORMAT_AもUNALIGNEDにする！ /
DCL 1 DATA_FORMAT_A BASED(P_RAW_DATA) UNALIGNED, / ここが重要！UNALIGNEDにする /
2 ID_NUM FIXED BINARY(31),
2 NAME CHAR(16);
/ メイン処理の一部 /
READ FILE(INPUT_FILE) INTO(INPUT_RECORD);
P_RAW_DATA = ADDR(INPUT_RECORD.RAW_DATA);
IF INPUT_RECORD.DATA_TYPE = ‘A’ THEN DO;
/ これで安全にID_NUMにアクセスできます。ただし、性能はALIGNEDより落ちる可能性あり /
PUT SKIP LIST(‘Type A ID:’, DATA_FORMAT_A.ID_NUM);
END;
`UNALIGNED`属性を付けることで、PL/Iコンパイラは、そのデータが1バイト境界に配置されていることを前提にコードを生成します。そのため、CPUは必要に応じて複数回メモリにアクセスしたり、シフト操作を行ったりしますが、アライメント違反による異常終了やデータ破壊は防ぐことができます。
5.2. `REFER`オプションや中間バッファを活用する
もし、`ALIGNED`な構造体としてデータを扱いたいが、参照元が`UNALIGNED`な場合、一度`ALIGNED`な作業用バッファにデータをコピーしてから処理する方法も考えられます。
PL/I
DCL 1 WORK_DATA_A ALIGNED, / ALIGNEDな作業用構造体 /
2 ID_NUM FIXED BINARY(31),
2 NAME CHAR(16);
/ … 処理中 … /
IF INPUT_RECORD.DATA_TYPE = ‘A’ THEN DO;
/ RAW_DATAの内容をALIGNEDなWORK_DATA_Aにコピー /
WORK_DATA_A = DATA_FORMAT_A; / ここでDATA_FORMAT_AはUNALIGNEDとして定義されていると仮定 /
PUT SKIP LIST(‘Type A ID:’, WORK_DATA_A.ID_NUM);
END;
この場合、`DATA_FORMAT_A`を`UNALIGNED`で定義し、そこから`ALIGNED`な`WORK_DATA_A`へ代入することで、PL/Iが内部的にバイトコピーとアライメント調整を行ってくれます。ただし、コピー処理によるオーバーヘッドが発生します。
また、PL/Iには`REFER`オプションという、構造体メンバーのサイズを動的に指定できる強力な機能もあります。これを使うと、可変長のデータ構造をより柔軟に扱うことができますが、今回は深入りせず、また別の機会にお話ししましょう。
5.3. デバッグのヒント
- `ON SIZE` / `ON FIXEDOVERFLOW` / `ON STRINGSIZE` / `ON SUBSCRIPTRANGE`: PL/Iには非常に多くのON条件があります。これらを適切に`ON`句でトラップすることで、プログラムが異常終了する前に問題を検知し、デバッグ情報を出力することができます。
- `PUT DATA`: 変数の内容を名前と値の形式で出力してくれるデバッグに便利な機能です。`PUT DATA(MY_VARIABLE);`と書くだけで、`MY_VARIABLE=12345;`のように出力されます。
- `CHECK`条件: 特定の変数が変更されたり、プロシージャが呼び出されたりするたびに処理を実行できる、強力なデバッグツールです。
—
まとめ
PL/Iのポインタと`BASED`変数を使った型変換（キャスト）は、メインフレームのレガシーシステムにおいて、限られたリソースの中で複雑なデータを効率的に扱うための非常に強力なテクニックです。JavaやCOBOLの皆さんには、まるで`REDEFINES`をポインタで自由自在に操るような感覚、と伝わるでしょうか。
しかし、その自由度と引き換えに、アライメントという落とし穴が潜んでいることを忘れてはなりません。特に、`UNALIGNED`なデータの上で`ALIGNED`なデータ型として見立てようとすると、アライメント違反による異常終了やデータ破壊という痛い目を見ることになります。
今回のテーマは、まさにメインフレームの現場で遭遇する「あるある」トラブルの一つです。この記事を読んで、「ああ、あの時のトラブルはこれだったのか！」と感じていただけたら幸いです。
PL/Iは一見とっつきにくいかもしれませんが、その仕様の背景には、常に「いかに効率よく、堅牢に、そして柔軟に基幹業務を動かすか」という先人たちの知恵と工夫が詰まっています。怖がらず、一つずつその奥深さを探求していきましょう。きっと、現代のシステム設計にも活かせるヒントが見つかるはずですよ！
それでは、また次回の記事でお会いしましょう！
