メインフレームの深淵：RECORD対STREAM、その「生死」を分かつ境界線
レガシーシステムの移行現場において、最も軽視され、かつ最大の地雷となるのが入出力モードの選定だ。PL/I（Programming Language One）という言語は、その多機能さゆえに「何でもできる」と思われがちだが、基幹システムの心臓部では、そのモード選択一つで処理時間が数倍に跳ね上がり、最悪の場合は原因不明のABENDを誘発する。
今日は、RECORDモードとSTREAMモードの挙動を、コンパイラ最適化と動的メモリ管理の観点から深掘りする。
—
1. STREAMモードの「便利さ」という名の罠
STREAMモード（`GET/PUT LIST`, `EDIT`）は、データ変換と編集をコンパイラに丸投げできる。これは小規模なレポート作成には適しているが、数百万件のトランザクションをさばくバッチ処理において、これをメインの入出力に据えるのは自殺行為だ。
STREAMモードは、内部で複雑なフォーマット変換処理を介在させる。この変換処理はCPUサイクルを激しく消費するだけでなく、内部バッファのフラッシュタイミングが制御しにくい。特に、DB2への埋め込みSQLと混在させた場合、コンパイラが挿入する変換コードと、DB2のランタイムが期待するデータ形式の間で予期せぬアライメントの不整合が起きることがある。
STREAMモードの限界とリスク
- CPUオーバーヘッド: 文字列変換に伴う`EDIF`命令相当の処理がループ内で回るため、コストはRECORD比で無視できない。
- バッファ管理: `PUT SKIP`や`PAGE`などの制御文字が介在し、物理的なレコード長を予測不能にする。
—
2. RECORDモードこそが「汎用機の魂」
バッチ処理の高速化を追求するなら、RECORDモード（`READ/WRITE`）一択だ。これは物理的なデータブロックをそのままメモリ上の構造体にマッピングする。いわば「生のメモリ操作」に近い。
RECORDモードでの動的メモリ操作
以下のコード例は、効率性を最大化するためのベース変数（Based Variable）とポインタ操作の基本形だ。
1
/ 構造体の定義 /
DCL 1 TBL_REC BASED(P_TBL),
2 KEY_ID CHAR(8),
2 DATA_VAL FIXED DEC(9,0); / パックデシマル /
DCL P_TBL POINTER;
DCL BUF_AREA CHAR(128) BASED(P_TBL);
/ 領域確保とマッピング /
ALLOCATE TBL_REC;
/ 直接読み込みによるオーバーヘッドの最小化 /
READ FILE(INPUT_DD) INTO(BUF_AREA);
/
- 重要な注意点:
- パックデシマル(FIXED DEC)の符号ビットは、メインフレーム特有の
- 0xC/0xD/0xF を利用する。もし移行先のJava側で
- 0x0C(正)を期待しているのに、PL/Iが 0x0F(符号なし)で渡すと、
- DB2のチェック制約や計算結果で「符号反転」のABENDを引き起こす。
/
この手法の鍵は、`ALLOCATE`によって制御されたメモリ領域に対し、物理レコードを直接コピーすることにある。`STREAM`のような変換層を介さないため、CPU負荷は最小限に抑えられる。
—
3. ABENDと戦うための「深層解析」
基幹システムの移行時、最も恐ろしいのは「開発環境では動くが、本番環境で特定レコードのみABENDする」ケースだ。これは大抵、データ構造の不一致か、ポインタの不正参照が原因である。
ダンプ解析のポイント
ABENDが発生した際、まずはCEEDUMPを確認し、以下の項目を叩き出すこと。
1. P_TBLの現在値: ポインタが指し示すメモリ番地が、割り当て領域から外れていないか。
2. パックデシマルの内部形式: `DUMP`コマンドで該当領域を16進数表示し、末尾のニブル（符号部）を確認する。ここが正しくない場合、PL/Iのコンパイラオプション `RULES(NOFIXEDDEC)` などが影響している可能性がある。
—
4. アーキテクトへの提言：Java/C#移行への橋渡し
もしあなたがレガシー資産をJavaやC#へ移行するプロジェクトの責任者なら、PL/Iの「レコード」を「固定長バイト配列」として捉え直すべきだ。
- レコード長 = 構造体サイズ: PL/Iの`1`で始まる構造体定義は、そのままバイナリのメモリレイアウトと一致する。
- 変換処理の分離: PL/Iの`STREAM`が行っていた「編集」は、移行先言語のDTO（Data Transfer Object）生成時に処理する。
- バリデーション: `ON CONDITION`や`ON AREA`などのPL/Iのイベント制御を、移行先では例外処理（Try-Catch）へ愚直にマッピングするのではなく、AOP（Aspect Oriented Programming）等を用いて横断的に監視する設計にすべきだ。
結論
STREAMモードは「人間が読みやすい出力」のための道具であり、RECORDモードは「システムが高速に生き残る」ための生存戦略だ。
基幹システムにおいて、処理速度と堅牢性はトレードオフではない。PL/IのRECORDモードを極めることは、メインフレームという過酷な環境で「いかに無駄な計算を省き、いかにメモリを賢く使うか」という、現代のクラウドネイティブな開発にも通じる極意を学ぶことと同義である。
コードが書けるだけのプログラマではなく、メモリの動きが見えるアーキテクトであれ。それが、我々レガシー移行スペシャリストの矜持だ。
