1. 導入：なぜSIGNED/UNSIGNEDの理解が不可欠なのか
メインフレームのCOBOLやPL/Iでデータ定義を行う際、何気なく記述している「FIXED BINARY」。実は、符号の有無（SIGNED/UNSIGNED）を意識せずに設計すると、外部システムとのデータ連携や、Java等へのマイグレーション時に致命的な数値の誤読を招きます。本稿では、ハードウェアレベルの特性と、安全なデータ変換のための技術的なTipsを解説します。
2. 基礎知識：なぜSIGNEDがデフォルトなのか
メインフレームの演算回路（ALU）は、2の補数表現を用いた「符号付き整数」の演算に最適化されています。PL/Iで特に属性を指定しない場合、FIXED BINARYはデフォルトでSIGNEDとして扱われます。
一方、UNSIGNEDは符号ビットを「値の一部」として利用するため、同じビット長でも表現できる正の数の範囲が2倍に広がります。これは主に、通信プロトコルのビットパターン解析や、ハードウェア制御、あるいはC言語等の他言語から持ち込まれたバイナリデータを扱う際に利用されます。
3. 実装と解決策：適正な型の選定
UNSIGNEDを使用する場合、最大値に注意が必要です。例えばFIXED BIN(16)の場合、SIGNEDなら-32,768～32,767ですが、UNSIGNEDなら0～65,535となります。
システム設計において「マイナス値をとらない項目」であっても、Java等の外部環境へデータを渡す際は、その言語の仕様を確認しなければなりません。
4. サンプルプログラム：PL/Iによる定義と判定
以下は、SIGNEDとUNSIGNEDの挙動を確認するためのサンプルです。
/ UNSIGNEDとSIGNEDの比較サンプル /
DCL SIGNED_VAL FIXED BIN(15) INIT(32768); / 範囲外のためオーバーフロー /
DCL UNSIGNED_VAL FIXED BIN(16) UNSIGNED;
/ UNSIGNED変数への代入 /
UNSIGNED_VAL = 32768;
/ 内部表現を確認する際の手順 /
/ 実際の現場では、以下の値が正しく格納されているか /
/ HEXダンプ等で確認を行うことが推奨されます /
PUT SKIP LIST('UNSIGNED値: ', UNSIGNED_VAL);
5. 応用・注意点：Java移行時の「型」の罠
現場で最も多いトラブルが、メインフレームからJavaへのデータ移行時です。Javaには標準で「16bit UNSIGNED」という型が存在しません。
そのため、以下の対策が必須です。
・上位の型へマッピングする
16bit UNSIGNEDを扱う場合、Javaでは「int (32bit)」を選択してください。short（16bit SIGNED）に格納すると、上位ビットが符号ビットとして解釈され、数値が負に反転してしまいます。
・ビット演算による補正
もしどうしても16bit範囲に収めたい場合は、Java 8以降の「Integer.toUnsignedInt()」や、ビットマスク（& 0xFFFF）を使用して、符号付きとして扱われないように変換する処理を必ず挟んでください。
メインフレーム技術者にとって、ハードウェアに近い型定義を理解することは、システム間連携の堅牢性を高める第一歩です。UNSIGNEDを扱う際は、常に「上位言語での受け皿」をセットで検討するようにしましょう。
コメント