はじめに
メインフレームのオープン化やモダナイゼーションに伴い、アセンブラ資産を COBOL に変換する現場が増えてきました。
ところが、アセンブラから COBOL への変換では、「アセンブラでは当然だった前提が、COBOLでは成り立たない」という問題に直面します。
その代表例が「1バイトの扱い」です。本記事では、アセンブラにおける 1バイト（16進 00～FF）を COBOL ではどう扱うべきか、実体験ベースでまとめます。
アセンブラにおける「1バイト」の世界
アセンブラにおいて 1バイトは、
16進：00 ～ FF
10進：0 ～ 255
という完全な数値範囲として自然に扱えます。
IC / STC：ロード・ストア
A / AH / S：数値加減算
CLI：直接比較
ビット単位のマスクも容易
つまり、1バイト＝符号なし整数という前提でロジックが組まれているケースは珍しくありません。
COBOLで1バイト定義が難しい理由
まず直感的に定義しようとすると、次の罠にハマります。
01 WS-BYTE PIC 9.
→ これは「1桁の数字」であり、0～9 しか表現できません。
01 WS-BYTE PIC X.
→ これは 1バイトですが文字型であり、数値演算はできません。
つまり DISPLAY（ゾーン）形式では、アセンブラの 1バイト数値（00～FF）を再現できません。
COMP-5 を使えば 1バイトになる？
次に思いつくのが COMP 系の利用です。
01 WS-BYTE PIC S9(3) COMP-5.
見た目は 0～255 を扱えそうですが、実際には 2バイト確保されます。これは正しい挙動です。
999 (10進) = 03E7 (16進) は 9ビット以上であり、1バイト（8ビット）には収まりません。
COBOL では PIC（表現可能範囲）と USAGE（内部表現）が厳密に分かれており、PIC S9(3) とした時点で最低 2バイトが必要になります。
結論：COBOLには「符号なし1バイト整数（0～255）」に完全一致する型は存在しません。
実務での落としどころ：PIC S9(3) COMP-5（2バイト）
現場で最も現実的な解がこれです。
01 WS-BYTE PIC S9(3) COMP-5.
表現範囲：-999 ～ +999
実用範囲：0～255 として使用
内部表現：バイナリ
サイズ：2バイト
計算しやすく、処理系依存も少ない
アセンブラ：1バイト、COBOL：2バイトという差は生じますが、モダナイゼーション案件ではレコードレイアウトの完全一致よりも、ロジックの正確な再現性・保守性が優先されます。
まとめ
アセンブラから COBOL への変換で、1バイトの扱いは最初の大きな分岐点になります。
ポイントを整理すると：
アセンブラの 1バイト（0～255）は DISPLAY 型では再現不可
COBOL には符号なし1バイト整数が存在しない
PIC S9(3) COMP-5 は 2バイトになるが、実務では最適解
「完全一致」を狙うと行き止まりになりますが、「意味を合わせる」ことで前に進める。
これが、アセンブラ ☞ COBOL 変換の第一歩だと感じています。
