PL/IとCICSの深淵へ：データマッピングの「お作法」をマスターしよう
こんにちは。メインフレームの世界へようこそ。
JavaやCOBOLの経験がある方にとって、PL/Iという言語は少し「自由すぎて怖い」と感じるかもしれませんね。でも安心してください。PL/Iは、型システムとメモリ管理の深淵を知るための最高の手引書です。
今日は、CICS環境で避けては通れない「DFHCOMMAREA（通信領域）」とPL/I構造体のマッピングについて、現場の知見を交えて紐解いていきましょう。
—
1. PL/Iには「予約語」がない？ 自由すぎる命名の罠
まず驚かれるのが、PL/Iには「予約語」という概念が（厳密には）存在しないことです。`IF`という変数名すら定義できてしまいます。
- COBOLなら： `IF`は命令語なので変数名には使えません。
- PL/Iなら： `DCL IF FIXED BIN(15);` と書けば、それは立派な変数になります。
一見便利そうですが、可読性が地獄になるのは目に見えていますよね。現場では「標準命名規約」が絶対です。識別子は「意味のある英単語」を使い、言語仕様の隙間を突くようなトリッキーな命名は避けるのが、長く愛されるシステムを作るコツです。
—
2. CICS通信領域と「Based変数」の魔法
CICSでプログラム間通信を行う際、`DFHCOMMAREA`というメモリ領域を使います。ここにはCOBOLのCOPY句で定義されたデータレイアウトが流れてくるわけですが、PL/Iではこれをどう受け取るか。
ここで登場するのがBased変数です。これは「データの場所（アドレス）を指し示すポインタ」のようなものだと考えてください。
/i
/ 通信領域の構造体定義 /
DCL 1 COMMAREA_LAYOUT BASED(P_COMMAREA),
2 TRAN_ID CHAR(4), / トランザクションID /
2 DATA_LENGTH FIXED BIN(15), / データ長 /
2 FILLER CHAR(2), / 境界調整用 /
2 USER_DATA CHAR(100); / 本丸のデータ /
/ CICSから受け取ったアドレスをセットするポインタ /
DCL P_COMMAREA PTR;
`BASED(P_COMMAREA)` と宣言することで、この構造体は「メモリ上のどこかにある実体を、この型で解釈するよ」という宣言になります。非常に強力ですが、アライメント（境界調整）という落とし穴があります。
—
3. アライメントの落とし穴：なぜ「FILLER」が必要なのか
メインフレームのデータ型には「自然な境界」があります。例えば、`FIXED BIN(31)`（4バイト整数）は、メモリの4バイト境界（アドレスが4の倍数）から始まってほしい、というCPUのわがままがあるのです。
もし、`CHAR(1)`の直後に`FIXED BIN(31)`を配置すると、コンパイラは気を利かせて内部的に「隠しパディング（隙間）」を挿入します。しかし、COBOL側がそのようなパディングを考慮していない場合、データがズレて読み取られるという大惨事が起きます。
現場での回避策：ALIGNEDとUNALIGNED
PL/Iでは、この挙動を明示的に制御できます。
- `ALIGNED`: パディングを許容して境界に合わせる（処理速度優先）。
- `UNALIGNED`: パディングを入れず、詰めて配置する（ストレージ効率と他言語互換優先）。
CICSのマッピングでは、基本的に `UNALIGNED` を明示して、COBOLの構造体と1対1で一致させるのが定石です。
/i
DCL 1 COMMAREA_LAYOUT UNALIGNED, / 隙間を入れない宣言 /
2 TRAN_ID CHAR(4),
2 DATA_LENGTH FIXED BIN(15),
2 USER_DATA CHAR(100);
—
4. 実践：CICS READでデータを読み込む
では、実際にプログラム内でどう使うかを見てみましょう。
/i
/ DFHCOMMAREAのアドレスを取得してマッピング /
P_COMMAREA = DFHEICAP; / CICSの通信領域ポインタを取得 /
/ 構造体を介して安全にデータアクセス /
IF COMMAREA_LAYOUT.TRAN_ID = ‘ABCD’ THEN DO;
/ データの処理ロジック /
CALL PROCESS_DATA(COMMAREA_LAYOUT.USER_DATA);
END;
/ 書き込み時はWRITEではなく、CICSのSEND等で領域を返却 /
最後に：怖がらなくて大丈夫です
「ポインタ」や「メモリ境界」といった言葉を聞くと、Javaエンジニアの方は身構えてしまうかもしれません。でも、PL/Iにおいてこれらは「データの見え方を定義するメガネ」を掛け替えるようなものです。
まずは、「他言語とやり取りするデータ構造には常に `UNALIGNED` をつける」。これさえ守れば、CICSとのやり取りでデータが化けることはまずありません。
レガシーなシステムは、実はとても論理的で美しい世界です。一つずつ紐解いていけば、必ずあなたの武器になります。何か詰まったら、いつでもまた聞きに来てくださいね。一緒にデバッグしましょう！
