PL/I ポインタの型変換とCASTの罠 ～レガシーコードの深淵に挑む～
おい、諸君。今日もメインフレームの片隅で、古（いにしえ）のPL/Iコードと格闘していることだろう。数々の大規模バッチ改修や、突如として現れる謎のデータ不整合に頭を悩ませた経験は、君たちも数えきれないほどあるはずだ。
今回は、PL/Iのポインタ操作、特に「型変換」と「CAST」について、現場で本当に役立つ、ちょっと踏み込んだ話をしようと思う。単なる言語仕様の羅列では、現場の混乱は解消されない。君たちが日々直面する「なぜ？」に、ベテランの視点から光を当てていく。
PL/Iプログラムの基本構造：PACKAGE、PROCEDURE、OPTIONS(MAIN)
まず、基本中の基本から確認しておこう。PL/Iプログラムは、通常 `PACKAGE` や `PROCEDURE` で構成される。特に、実行可能なプログラムのエントリーポイントとなるのは `OPTIONS(MAIN)` を持つ `PROCEDURE` だ。
MYPROG: PROCEDURE OPTIONS(MAIN);
/ ここにプログラムの本体処理を記述 /
DECLARE
PTR POINTER;
/ … ポインタを使った処理 … /
RETURN;
END MYPROG;
この `MYPROG` のような `PROCEDURE` の中で、我々は様々なデータ操作を行う。その中でも、ポインタはメモリ上の特定のアドレスを指し示す強力なツールだが、同時に誤った使い方をすると、デバッグ泣かせのバグを生み出す元凶にもなりうる。
ポインタの型変換とCASTの概念
PL/Iのポインタは、特定のデータ型に束縛されない「汎用」なアドレスを保持できる。これは柔軟性が高い反面、ポインタが指し示すメモリ領域に、どのようなデータが格納されているのかを、プログラム側で意識して管理する必要があることを意味する。
ここで登場するのが、「型変換」と「CAST」だ。
1. 暗黙の型変換（Implicit Conversion）
PL/Iでは、ポインタと他のデータ型の間で、ある程度の「暗黙の型変換」が行われることがある。しかし、これは非常に限定的であり、期待通りの動作をしない場合が多い。例えば、ポインタを直接数値として扱おうとすると、コンパイラによってはエラーになったり、意図しない結果になったりする。
DECLARE
PTR POINTER;
DECLARE
ADDR_VAL FIXED BINARY(31); / 32ビットシステムを想定 /
/ 実際のアドレス値を取得する（例: mallocやアロケーション関数など） /
/ PTR = … /
/ 暗黙の型変換を期待して代入しようとすると… /
/ ADDR_VAL = PTR; <-- これはコンパイラによる /
このように、ポインタ変数を直接数値変数に代入しようとしても、多くの場合、コンパイラは「型が違う」と警告またはエラーを出す。ポインタが保持しているのは「アドレス」という概念であり、そのアドレスが指し示す「データ」ではないからだ。
2. 明示的な型変換：CAST演算子
そこで必要になるのが、明示的な型変換、つまり `CAST` 演算子だ。`CAST` は、ポインタが指し示すメモリ領域を、指定したデータ型として解釈させたいときに使う。
構文は以下の通りだ。
CAST(pointer_expression AS data_type)
`pointer_expression` は、型変換したいポインタ変数や、ポインタを返す関数の結果など。`data_type` には、PL/Iの有効なデータ型を指定する。
例を見てみよう。あるメモリ領域を、`CHAR(n)` 型として扱いたい場合：
MYPROG: PROCEDURE OPTIONS(MAIN);
DECLARE
PTR POINTER;
DECLARE
BUFFER CHAR(100) BASED(PTR); / PTRが指す領域をCHAR(100)として参照 /
/ PTRに何らかのアドレスがセットされているとする /
/ PTR = … /
/ CASTを使って、PTRが指す領域をCHAR(100)として扱う /
DECLARE
TEMP_CHAR CHAR(100);
TEMP_CHAR = CAST(PTR AS CHAR(100)); / これでPTRの指す領域の内容がTEMP_CHARにコピーされる /
PUT SKIP LIST(‘CASTされた文字データ:’, TEMP_CHAR);
RETURN;
END MYPROG;
3. CASTとBASED変数の関係
`CAST` の概念は、PL/Iの `BASED` 変数と非常に密接に関連している。`BASED` 変数は、`POINTER` 変数に依存してメモリ上の領域を定義する。
MYPROG: PROCEDURE OPTIONS(MAIN);
DECLARE
PTR POINTER;
DECLARE
MY_STRUCT
STRUCTURE(
FIELD1 CHAR(10),
FIELD2 FIXED BINARY(15),
FIELD3 DECIMAL(5,2)
);
DECLARE
STRUCT_BASED CHAR(SIZE(MY_STRUCT)) BASED(PTR); / PTRが指す領域をMY_STRUCTのサイズで宣言 /
/ PTRにMY_STRUCTが配置されるべきメモリ領域のアドレスをセット /
/ PTR = … /
/ STRUCT_BASED を介してMY_STRUCTのメンバにアクセス /
PUT SKIP LIST(‘FIELD1:’, SUBSTR(STRUCT_BASED, 1, 10)); / FIELD1に相当する部分 /
/ FIELD2やFIELD3へのアクセスは、サイズやオフセットを考慮する必要があり、 /
/ 直接的なメンバアクセスではないため、安全とは言えない /
/ CASTを使えば、より構造化されたアクセスが可能になる /
DECLARE
CASTED_STRUCT LIKE MY_STRUCT;
CASTED_STRUCT = CAST(PTR AS LIKE MY_STRUCT); / PTRが指す領域をMY_STRUCT型としてキャスト /
PUT SKIP LIST(‘CASTされたFIELD1:’, CASTED_STRUCT.FIELD1);
PUT SKIP LIST(‘CASTされたFIELD2:’, CASTED_STRUCT.FIELD2);
PUT SKIP LIST(‘CASTされたFIELD3:’, CASTED_STRUCT.FIELD3);
RETURN;
END MYPROG;
`BASED` 変数を使うことで、ポインタが指し示すメモリ領域を、あらかじめ定義しておいた構造体として直接参照できる。これは、レコード入出力やVSAMアクセスで、ディスク上のレコードフォーマットをPL/Iの構造体として扱いたい場合に非常に強力な機能だ。
アライメントの罠（Alignment Trap）
さて、ここからが本題だ。`CAST` を使う際に、多くのプログラマが陥りやすい、そしてデバッグに非常に苦労する原因となるのが「アライメント」の問題だ。
CPUは、メモリ上のデータを特定の境界（例えば、2バイトデータなら偶数アドレス、4バイトデータなら4の倍数アドレス）で読み書きする方が効率が良い。この、データが配置されるべき「整列されたアドレス」のことをアライメントと呼ぶ。
PL/Iのコンパイラや、CPUアーキテクチャによっては、ポインタが指し示すメモリ領域に、本来そのデータ型が要求するアライメントを満たさないアドレスが含まれていると、以下のような問題が発生しうる。
1. パフォーマンスの低下: CPUがアライメントされていないデータを読み込むために、余計な処理（メモリへの再アクセスなど）が必要になり、パフォーマンスが著しく低下する。
2. 実行時エラー（ABEND）: 最悪の場合、CPUがアライメント違反を検知し、プログラムが異常終了（ABEND）する。特に、`0C4` (Protection Exception) や `0A9` (Data Exception) といった異常終了コードは、アライメント違反の可能性を示唆していることが多い。
アライメントの罠を避けるための実践的アプローチ
- `BASED` 変数と構造体の利用: レコード入出力やVSAMアクセスでは、ディスク上のレコードフォーマットをPL/Iの構造体として `BASED` 変数で定義するのが最も安全だ。コンパイラは、構造体全体のサイズやメンバのオフセットを適切に計算してくれる。
MYPROG: PROCEDURE OPTIONS(MAIN);
DECLARE
PTR POINTER;
DECLARE
RECORD_LAYOUT
STRUCTURE(
ID PIC ‘X(10)’,
QUANTITY PIC ‘9(5)B’, / Binary, 5 digits /
PRICE PIC ‘9(7)V99’ / Decimal, 2 implicit /
);
DECLARE
RECORD_BASED CHAR(SIZE(RECORD_LAYOUT)) BASED(PTR);
/ VSAMなどで読み込んだレコードをPTRにセット /
/ … /
/ RECORD_BASED を介して、構造体メンバのようにアクセス /
/ （ただし、直接メンバ名でアクセスできるわけではない） /
PUT SKIP LIST(‘ID:’, SUBSTR(RECORD_BASED, 1, 10));
/ QUANTITYやPRICEへのアクセスは、バイトオフセットとサイズを /
/ 自分で計算する必要がある。ここが煩雑な点。 /
/ CASTを使えば、より楽にアクセスできる場合も /
DECLARE
CASTED_RECORD LIKE RECORD_LAYOUT;
CASTED_RECORD = CAST(PTR AS LIKE RECORD_LAYOUT);
PUT SKIP LIST(‘CAST ID:’, CASTED_RECORD.ID);
PUT SKIP LIST(‘CAST QUANTITY:’, CASTED_RECORD.QUANTITY);
PUT SKIP LIST(‘CAST PRICE:’, CASTED_RECORD.PRICE);
RETURN;
END MYPROG;
この例では、`LIKE` キーワードを使って `RECORD_LAYOUT` と同じ構造を持つ `CASTED_RECORD` を定義している。これにより、`CAST` 後はメンバ名でのアクセスが可能になり、コードの可読性が向上する。
- `ALIGNED` / `UNALIGNED` 属性の理解: PL/Iでは、構造体のメンバや変数に `ALIGNED` または `UNALIGNED` 属性を指定できる。
- `ALIGNED`: デフォルト。データ型が要求するアライメント境界に配置される。
- `UNALIGNED`: アライメントを考慮せず、メモリ上の連続したバイトに配置される。
DECLARE
MY_DATA STRUCTURE(
A CHAR(10) UNALIGNED,
B FIXED BINARY(31) ALIGNED, / 4バイト境界に整列 /
C CHAR(5) UNALIGNED
);
`UNALIGNED` を指定することで、アライメントの制約を無視できるが、パフォーマンス低下のリスクを伴う。通常は、コンパイラやCPUのデフォルト（多くの場合 `ALIGNED`）に任せるのが良い。しかし、外部システムとのデータ交換や、特定のアライメントを強制したい場合には、この属性を意識する必要がある。
- `SIZE` ビルトイン関数の活用: `SIZE` 関数は、変数のデータ型が占めるバイト数を返す。`BASED` 変数でメモリ領域を確保する際や、`CAST` で変換する際のデータ長を正確に把握するために不可欠だ。
DECLARE
MY_VAR CHAR(20);
DECLARE
VAR_SIZE FIXED BINARY INITIAL(SIZE(MY_VAR)); / MY_VARのサイズ（20バイト）がセットされる /
- `OFFSET` 型の利用: `OFFSET` 型は、ポインタが指す領域からの相対位置を示す。構造体内のメンバへのオフセットを表現するのに便利で、アライメントの問題を抽象化してくれる場合がある。
DECLARE
PTR POINTER;
DECLARE
STRUCT_BASE STRUCTURE(
MEMBER1 CHAR(10),
MEMBER2 FIXED BINARY(15)
) BASED(PTR);
DECLARE
OFF_MEMBER2 OFFSET(STRUCT_BASE.MEMBER2); / STRUCT_BASEからのMEMBER2へのオフセット /
/ PTRにセットされるアドレス + OFF_MEMBER2 でMEMBER2にアクセス /
PUT SKIP LIST(‘MEMBER2 VALUE:’, GET_OFFSET_ITEM(PTR, OFF_MEMBER2)); /Pseudo-code for accessing via offset/
ただし、`OFFSET` の直接的な操作は、`BASED` 変数や `CAST` を介した間接的なアクセスに比べて、コードが読みにくくなる傾向がある。
ONユニットとポインタ：デバッグの切り札
ポインタ操作で問題が発生した場合、`ON` ユニットはデバッグの強力な味方となる。特に、`ON ERROR` や、特定の条件での `ON CONDITION` は、異常終了の直前に実行されるため、ポインタの値や関連する変数の状態をダンプするのに最適だ。
MYPROG: PROCEDURE OPTIONS(MAIN);
DECLARE
PTR POINTER;
DECLARE
DATA_AREA CHAR(50);
DECLARE
ERROR_DETECTED BIT(1) INIT(‘0’B);
ON ERROR SYSTEM; / デフォルトのON ERRORハンドラ /
/ 特定のエラー、例えばアライメント違反などで異常終了しそうな場合 /
/ ONCODEが特定の値を示す場合などに、独自のONユニットを設定 /
ON CONDITION(MY_ALIGN_ERR) / ユーザー定義条件 /
BEGIN;
ERROR_DETECTED = ‘1’B;
PUT SKIP LIST(‘!!! Alignment Error Detected !!!’);
PUT SKIP LIST(‘Pointer Value: ‘, PTR);
PUT SKIP LIST(‘Current ONCODE: ‘, ONCODE);
PUT SKIP LIST(‘Data Area (partial): ‘, SUBSTR(DATA_AREA, 1, 20));
SIGNAL MY_ALIGN_ERR; / 処理を再開させるか、終了させるか /
END;
/ … ポインタを使った処理 … /
/ ここでアライメント違反が発生すると、ON CONDITION(MY_ALIGN_ERR)が実行される /
/ 実際には、ONCODEの値を確認して、どのエラーかを判断するのが一般的 /
IF ERROR_DETECTED THEN
PUT SKIP LIST(‘Program terminated due to alignment error.’);
ELSE
PUT SKIP LIST(‘Processing completed successfully.’);
RETURN;
END MYPROG;
`ONCODE` ビルトイン関数は、発生したエラーコードを返す。このコードを分析することで、アライメント違反による `0C4` や `0A9` を特定し、`ON` ユニット内でポインタの現在の値や、関連するデータ領域の状況を詳細に記録することが、問題解析の第一歩となる。
まとめ
PL/Iのポインタと `CAST` は、メモリを直接操作できる強力な機能だが、アライメントという見えない壁が潜んでいることを忘れてはならない。
- `BASED` 変数と構造体を最大限に活用し、レコードフォーマットを正確に定義すること。
- `CAST` を使う際は、変換先のデータ型が要求するアライメントを意識すること。
- パフォーマンスが問題になる場合は、`ALIGNED`/`UNALIGNED` 属性や、CPUの挙動を理解すること。
- デバッグに迷ったら、`ON` ユニットと `ONCODE` を駆使して、異常終了寸前の状態を詳細に記録すること。
これらの知識と経験を積み重ねることで、君たちもレガシーコードの深淵に潜むバグと冷静に対峙できるようになるはずだ。
さあ、今日も一日、頑張ろうじゃないか！
