ASCII-EBCDIC-HEX

1. ASCII - EBCDIC – HEX
ASCII --American Standard Code for Information Interchange
--mostly used for personal computers + Unix systems
EBCDIC --Extended Binary Coded Decimal Interchange Code
--used for large Mainframes (MVS, VSE, VM, BS2000---) and AS400
Below – good example – conversion table
https://shop.alterlinks.com/ascii-table/ascii-ebcdic-us.php
Character Decimal ASCIIHex ASCII Hex EBCDIC
Space 32 20 40
0 48 30 F0
1 49 31 F1
2 50 32 F2
3 51 33 F3
4 52 34 F4
5 53 35 F5
6 54 36 F6
7 55 37 F7
8 56 38 F8
9 57 39 F9
A 65 41 C1
B 66 42 C2
C 67 43 C3
I 73 49 C9
J 74 4A D1
K 75 4B D2
R 82 52 D9
S 83 53 E2
T 84 54 F3
Z 90 5A E9
---------------------------------------------------------------------------------------
http://www.3480-3590-data-conversion.com/article-signed-fields.html
EBCDIC to ASCII Conversion of Signed Fields
There is a numeric data type commonly used in COBOL files on IBM mainframes which is
called "Signed" (also called "IBM Signed", or "Zoned"). This data type originated in the days of
punch-cards. COBOL represents this type of field by an "S" in the picture clause of a DISPLAY
field (i.e. a field with no "comp" or "comp-3" modifier). An example is "PIC S9(6).". The
value stored in this field is a mix of character and binary codes, and cannot be properly converted
from EBCDIC to ASCII with a simple translation table. This page is a brief description of the
signed data type, and what happens if someone improperly converts it from EBCDIC to ASCII
as character data. (See note 1 about other representations of signed fields.)

2. Description of the Signed Data Type
A Signed field is composed of regular EBCDIC numeric characters, one character per byte, for
all the digits of the field except the one that holds the sign, either the most-significant (sign
leading) or the least-significant (sign trailing) digit -- usually the least-significant digit. The digit
that holds the sign combines, or "over punches" the sign of the number onto that digit. (See note
2). This saves one byte that the sign would otherwise occupy. The value of that digit is stored as
a binary value, and is OR'd with the sign code, which is D0 hex for negative numbers, C0 hex for
positive values, and F0 hex for "unsigned" values. (See note 3 below for an alternative
viewpoint.)
Let's look at two examples. This is how the value +123 would be stored in an EBCDIC Signed
field with the sign in the LSD (least significant digit):
1.The 1 is stored as the EBCDIC character "1", which is F1 Hex.
2.The 2 is stored as the EBCDIC character "2", which is F2 Hex.
3.The 3, however, is converted to a binary value of 3, which is 03 hex, then OR'd with the
positive sign code of C0 hex, resulting in the byte C3 hex.
The resulting field in hex is: F1, F2, C3. The proper way to interpret the C3 is as two entities:
the sign of C0 and the value of 03. However, it also happens to be the code for the EBCDIC
letter "C", so if you view the field in EBCDIC character mode, you will see "12C".
http://www.asciitable.com/
Dec HX
15 F
16 10