メインフレームの「深淵」を覗く：FIXED BINARY(15)と(31)の使い分けがバッチ性能を左右する理由
若手の諸君、ご苦労。今日もメインフレームの黒い画面（エミュレータ）と向き合っていることだろう。
保守やマイグレーションの現場で、ふと見かける`FIXED BINARY`の宣言。何気なく`(15)`や`(31)`を使い分けていないか？「とりあえずメモリを食わないように(15)にしておこう」とか、「大きい値が入るかもしれないから(31)で」といった安易な選択は、大規模な基幹システムにおいては、時として「性能劣化」や「不可解な計算結果」という牙を剥くことがある。
今回は、IBMメインフレームにおける整数型の実態と、アーキテクチャの視点から見た最適解について語ろう。
—
なぜ(15)と(31)なのか？内部表現の物理的本質
PL/Iにおいて`FIXED BINARY`は、CPUの命令セットと密接に関係している。
- FIXED BINARY(15): 内部的には「2バイト（ハーフワード）」として扱われる。
- FIXED BINARY(31): 内部的には「4バイト（フルワード）」として扱われる。
ここで重要なのは、IBMのSystem zアーキテクチャにおいて、算術演算の基本単位がフルワード（4バイト）であるという事実だ。
1. レジスタ効率の罠
(15)を多用すると、コンパイラは値をロードした後に、符号拡張や演算後の桁あふれチェックのために余計な命令を生成する。現代のz/Architectureであれば、フルワード（31ビット）演算は極めて効率的だ。メモリ節約のために(15)を選んだ結果、かえってCPU命令数が増え、バッチの実行時間が数秒単位で伸びる……というのは、大規模集計処理ではよくある「あるある」だ。
2. VSAMアクセスとの相性
レコード定義（COPY句的な仕組み）で構造体を組む際、VSAMのレコードレイアウトとメモリ上の配置を一致させる必要がある。ここで「なんとなく」の型選択をすると、境界調整（アライメント）のために意図しないパディング（埋め草）が挿入され、データ構造が崩壊する。
—
実践的コード：最適化されたデータ制御
以下のソースコードを見てほしい。大規模バッチで頻出する、VSAM読み込みから計算処理への流れを想定している。
/i
PROG01: PROC OPTIONS(MAIN);
/ 宣言のベストプラクティス /
/ 31ビット（フルワード）は演算効率が最も高い /
DCL W_COUNT FIXED BIN(31) INIT(0);
/ 2バイトはあくまでメモリ制約が厳格なレコード定義内でのみ使用 /
DCL 1 VSAM_REC,
5 REC_ID CHAR(4),
5 REC_QTY FIXED BIN(15); / VSAMレイアウトがハーフワードの場合 /
DCL VSAM_FILE FILE RECORD INPUT ENV(VSAM);
ON ENDFILE(VSAM_FILE) BEGIN;
PUT SKIP LIST(‘処理終了: 累計件数 = ‘ || W_COUNT);
STOP;
END;
OPEN FILE(VSAM_FILE);
DO FOREVER;
READ FILE(VSAM_FILE) INTO(VSAM_REC);
/ 演算処理 /
/ 内部計算用には必ず(31)を使用し、レジスタ効率を最大化する /
/ 暗黙の型変換(FIXED BIN(15) -> (31))はコンパイラが自動で行うが、
明示的に型を合わせる方がデバッグ時の意図が明確になる /
W_COUNT = W_COUNT + REC_QTY;
END;
CLOSE FILE(VSAM_FILE);
END PROG01;
—
ベテランからのアドバイス：保守の現場で意識すべきこと
1. 演算用変数は迷わず(31)を使え:
メモリ容量が数ギガバイトある現代のLPARにおいて、数十個の変数を(15)にしてメモリをケチる意味は皆無だ。計算の正確性とレジスタの有効活用を優先せよ。
2. ONユニットの過信は禁物:
`ON ENDFILE`や`ON CONVERSION`は便利だが、制御フローが複雑になるとデバッグが困難になる。例外処理は可能な限り局所化し、メインロジックの可読性を損なわないように設計する。
3. BUILTIN関数の活用:
`BINARYVALUE`や`FIXED`などの組み込み関数を活用し、型変換を明示的に制御する癖をつけよう。特に異なる精度同士の算術演算では、意図しないオーバーフローや切り捨てが発生する。
最後に
PL/Iは、C言語のようにハードウェアに寄り添いながらも、COBOLのような強力なレコード処理能力を持つ、極めて「大人な言語」だ。その仕様一つひとつには、メインフレームの歴史と哲学が詰まっている。
「なぜこの型なのか？」を常に問い、機械語レベルでの挙動を想像する。この姿勢こそが、バッチ改修における「未知のバグ」を未然に防ぐ、君たちの武器になるはずだ。
次は、`AREA`属性や`BASED`変数を用いた動的メモリ制御について話そうか。また現場で会おう。
