CICS×PL/Iの深淵：EIBとCOMMAREAのメモリ操作を極める
メインフレームの現場で長く生き残っていると、「なぜこの処理はこんなに堅苦しい書き方をしているのか」と後輩から問われることがある。特にCICS（Customer Information Control System）環境下でのPL/Iプログラムは、まるで古の呪文のように見えるかもしれない。だが、その背後にはメモリ管理の極意と、バグを未然に防ぐための冷徹な設計思想が隠されている。
今回は、CICS連携の要である`DFHEIBLK`と`DFHCOMMAREA`について、現場の「生きた知見」を共有しよう。
—
1. CICSプログラムの「お作法」：PROCEDUREの入り口
PL/IでCICSプログラムを書く際、`OPTIONS(MAIN)`は必須だ。だが、それ以上に重要なのは、CICSから渡される制御ブロックをどう「型付け」するかにある。
/i
/ CICS連携メインプログラムの標準構造 /
MYPROG: PROCEDURE(DFHEIBLK, DFHCOMMAREA) OPTIONS(MAIN);
/ IBM提供のCICSインターフェースブロックの定義 /
DCL DFHEIBLK PTR BYADDR;
/ 通信用エリアのポインタ定義 /
DCL DFHCOMMAREA PTR BYADDR;
/ 実際のマッピング用構造体（後述） /
DCL 1 COMMAREA_LAYOUT BASED(DFHCOMMAREA),
3 TRANS_ID CHAR(4),
3 RETURN_CODE FIXED BIN(15),
3 DATA_AREA CHAR(1024);
/ 以下、処理ロジック /
ここで若手がよく躓くのが、`DFHCOMMAREA`のハンドリングだ。CICSは、プログラムが呼び出されるたびにこのアドレスを渡してくる。もしCOMMAREAが渡されなかった場合（長さが0の場合）、ポインタを参照した瞬間にSOC4（保護例外）が飛ぶ。これを防ぐための「防御的コーディング」が、ベテランの嗜みというものだ。
—
2. COMMAREAのメモリマッピングとポインタ操作
現場では、COMMAREAを単なる「データの受け渡し場所」と考えてはいけない。これは「共有メモリ」だ。`BASED`変数を使って構造体を被せることで、PL/Iの強力なデータ操作機能が使えるようになる。
/i
/ COMMAREAの長さチェックは鉄則 /
IF EIBCALEN = 0 THEN DO;
/ 初期呼び出し時の処理：COMMAREAがない場合の初期化 /
…
END;
ELSE DO;
/ COMMAREAに型を被せてアクセス /
/ EIBのEIBCOMPLはCICSが自動管理するEIBフィールド /
IF TRANS_ID = ‘ACTV’ THEN DO;
/ ビジネスロジックをここに記述 /
CALL PROCESS_DATA;
END;
END;
ここで活用すべきなのが、`ADDR`関数と`LENGTH`関数だ。特に構造体のサイズを動的に判定する際、`LENGTH(COMMAREA_LAYOUT)`を使うことで、ハードコーディングされたマジックナンバーを排除できる。これは後の改修時に、構造体のメンバーを追加した際のバグを劇的に減らす。
—
3. ONユニットによる「予期せぬ事態」への備え
CICS環境下では、バッチのような単純な異常終了は許されない。`ON`ユニットを使って、異常系を適切に制御フローへ組み込むのがシステムアーキテクトの腕の見せ所だ。
/i
/ エラーハンドリングの定石 /
ON ERROR BEGIN;
PUT SKIP LIST(‘UNEXPECTED ERROR OCCURRED’);
/ ここでCICSのABEND処理を呼ぶか、ログを出力して正常終了させる /
CALL CICS_ABEND_LOGIC;
END;
ただし、`ON`ユニットを乱用すると、どこで例外が発生したか追跡困難になる。特定のデータ操作やVSAMアクセスに限定して適用するのが、保守性を保つ秘訣だ。
—
4. 現場で使えるデバッグのコツ：なぜか動かない時のチェックリスト
最後に、トラブルシューティングで必ず確認すべきポイントを挙げておく。
1. アライメントの不一致: `ALIGNED`属性をサボっていないか？ CICSのメモリマップと構造体のオフセットがずれると、データが化ける。基本は`ALIGNED`を明示せよ。
2. DFHEIBLKの型: コンパイル時に`DFHEIBLK`を正しく定義していないと、EIBフィールド（`EIBDATE`, `EIBTIME`など）にアクセスした際にコンパイルエラーになる。`CICS`プリプロセッサが正しく動作しているか確認を怠るな。
3. ストリングの範囲外アクセス: `SUBSTR`を使う際、`LENGTH`チェックを省略している箇所はないか？ `ON STRINGRANGE`をテスト環境で有効にしておくと、開発中に潜在的なバグをあぶり出せる。
結び：古き良き言語の強み
PL/Iは、その歴史の長さゆえに「古い」と思われがちだが、データ構造の定義能力とポインタ操作の柔軟性は、現代の言語にも引けを取らない。特にCICSのような高負荷・高信頼性が求められる環境では、この「メモリを直接御する感覚」こそが、堅牢なシステムを作る最後の砦となる。
コードを書くときは、常に「このメモリアドレスは誰が管理しているのか？」を自問自答してほしい。その一瞬の迷いが、本番環境での障害を未然に防ぐのだから。
さて、次はVSAMのレコードアクセスにおけるバッファ管理について掘り下げてみるとしよう。準備はいいか？
