Button for 1977 Button for 1984 Button for 1990 Button for 1995 Button for MDC Button for notes Button for examples
☜

EBCDIC

M[UMPS] by Example

☞

EBCDICTM

  0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
0 null SOH STX ETX PF HT LC DEL GE RLF SMM VT FF CR SO SI
16 DLE DC1 DC2 TM RES NL BS IL CAN EM CC CUI IFS IGS IRS IUS
32 DS SOS FS   BYP LF ETB ESC     SM CU2   ENQ ACK BELL
48     SYN   PN RS UC EOT       CU3 DC4 NAK   SUB
64                     [ . < ( + !
80 &                   ] $ * ) ; ^
96 - /                 ¦ , % _ > ?
112                   ` : # @ ' = "
128   a b c d e f g h i            
144   j k l m n o p q r            
160   ~ s t u v w x y z            
176                                
192 { A B C D E F G H I     EBCDIC code 204   EBCDIC code 206  
208 } J K L M N O P Q R            
224 \   S T U V W X Y Z     EBCDIC code 236      
240 0 1 2 3 4 5 6 7 8 9 Ilvm          

Notes for conversion:

In most EBCDIC environments are fields called "packed decimal". The hints below may help in reading and "unpacking" these codes.

In IBM "packed decimal" representation, each digit occupies four bits, i.e. IBM fits two digits in one byte. This is true for all bytes, except for the rightmost byte. In the rightmost byte, a code for the sign is placed in the low order four bits (details about this code are below).

The digits 0 through 9 are encoded in their natural hex form:
0 = "0000"
1 = "0001"
2 = "0010"
3 = "0011"
4 = "0100"
5 = "0101"
6 = "0110"
7 = "0111"
8 = "1000"
9 = "1001"

When an IBM system does arithmetic on such values, the codes 1010 through 1111 are invalid as digits, but are interpreted as sign codes with 1010, 1100, 1110 and 1111 recognized as plus, and 1011, 1101 recognized as minus.
The codes 0000-1001 are invalid as signs.

When an IBM system converts an "ordinary" number into this packed decimal form, the sign code generated depends on bit 12 of the Program Status Word. When bit 12 of the Program Status Word is 0, the preferred EBCDIC sign code is generated: 1100 for plus, 1101 for minus. When bit 12 of the Program Status Word is 1, the preferred ASCII-8 code is generated: 1010 for plus, 1011 for minus.

When dealing with packed decimal numeric data as a M[UMPS] programmer, handling all of the bytes, except the last is straight-forward: use the "natural" interpretation for 0000-1001, dealing with four bits at a time (using $ASCII(char)\16 for the high-order four bits and $ASCII(char)#16 for the low-order four bits. In the last byte, the high-order four bits contain the last digit, and the low-order four bits contain the sign, as indicated above.

When packed decimal data is printed out as eight-bit EBCDIC characters which are then converted to eight-bit ASCII characters, one has to work "backwards". For all but the last byte, look at the ASCII character in each byte, convert it back to EBCDIC and then use $ASCII(char)\16 for the high-order four bits and $ASCII(char)#16 for the low-order four bits to figure out what the original digits were. For the last byte, you treat the high-order four bits ($ASCII(char)\16) as a digit, and the low order four bits ($ASCII(char)#16) half as a sign according to the rules given above.

Make sure the format is indeed IBM’s "packed decimal" format.
There is also something called "zoned decimal" format. It has some similarities to "packed decimal", but also some differences, especially in the meaning of the last byte.

Packed Decimal data can be decoded with:

CvtPacked(x) ; Packed Decimal
NEW I,Hi,Lo,Result,V
SET Result=0
FOR I=1:1:$LENGTH(x) DO
. SET V=$ASCII(x,I)
. SET Hi=V\16
. SET Lo=V#16
. SET Result=Result*10+Hi*10+Lo
. QUIT
IF Lo=15!(Lo=12) SET Result=Result-Lo/10
ELSE IF Lo=13 SET Result=Lo-Result/10
ELSE SET $ECODE=",U99," ; invalid sign nibble
QUIT Result

CvtBinary(x) ; Binary
NEW I,Result
SET Result=0
FOR I=1:1:$LENGTH(x) SET Result=Result*256+$ASCII(x,I)
QUIT Result

Note: These examples assume that the underlying platform is "big-endian", but that’s what IBM mainframes are.

Button for 1977 Button for 1984 Button for 1990 Button for 1995 Button for MDC Button for notes Button for examples

Copyright © Standard Documents; 1977-2024 MUMPS Development Committee;
Copyright © Examples: 1995-2024 Ed de Moel;
Copyright © Annotations: 2003-2008 Jacquard Systems Research
Copyright © Annotations: 2008-2024 Ed de Moel.

The information in this page is NOT authoritative and subject to be modified at any moment.
Please consult the appropriate (draft) language standard for an authoritative definition.

Some specifications are "approved for inclusion in a future standard". Note that the MUMPS Development Committee cannot guarantee that such future standards will indeed be published.

This page most recently updated on 15-Nov-2023, 13:19:54.

For comments, contact Ed de Moel (demoel@jacquardsystems.com)