Zoned Decimal Format  Description and Discussion http://www.simotime.com  Copyright © 1987-2010  SimoTime Enterprises  All Rights Reserved

Introduction
(Next) (Previous) (Table-of-Contents)

This document will focus on a discussion of a numeric field (or data string) format referred to as zoned decimal and is commonly used on an IBM Mainframe System. This is the default numeric format for COBOL and may be explicitly defined with the "USAGE IS DISPLAY" clause

Note: The items in this document are appropriate for applications that are written in COBOL, Mainframe Assembler (HLASM) or PL/I. The IBM Mainframe architecture drove many of the numeric formats that existed in the early ANSI specifications for COBOL.and have been carried forward to the current COBOL ANSI specifications.

The "SIGNED, ZONED-DECIMAL" format has caused problems for years for mainframe programmers because the signed position of the field will display as a character value of "A-I" for positive numbers and "J-R" for negative numbers. It also allows for a positive and negative zero value that will display as a "{" and "}", this is the curly brace symbol or x'C0' and x'D0'.

When converting this type of field from EBCDIC to ASCII the programmer is presented with a number of confusing options and challenges. This document will try to explain the options and help the programmer avoid the common mistakes that are made during a conversion process.

Special Considerations for Zone-Decimal
(Next) (Previous) (Table-of-Contents)

Numeric fields that are zoned-decimal format (unsigned or signed, positive or negative) require additional consideration when displaying, printing or converting between EBCDIC and ASCII. Lets quickly answer the question, "Why is the term zoned-decimal used to describe this numeric format?"

The terms "Zone" and "Decimal" have been carried forward from when computers used punched cards for input and output. The punched card had eighty vertical columns and twelve horizontal rows. The columns were simply numbered 1-80. The top two rows were numbered "12" and "11". The remaining rows were referred to as rows 0 through 9. The top three rows were referred to as the Zones (the 12, 11 and 0 rows). Rows 1 through 9 were referred to as the Decimal rows (with the 0 (zero) row doing double duty as the decimal 0). When a column contained a single hole (a punch) in a decimal row it was equivalent to a positive digit or number. To create a negative value required a second punch in the column that represented the units position of a numeric field (or data string). For negative numbers this was the eleven row. This solved the problem of storing positive and negative numbers in the limited space available on a punched card but was the beginning of an annoying little problem that still exist today. This little problem can be understood when we take a look at how the alphabet was stored on a punched card. The upper-case, alphabetic characters required two punches in each column that contained a letter. For the letters A-I the twelve-punch was used along with a 1-9 punch. For the letters J-R the eleven-punch was used along with a 1-9 punch. For the letters S-Z the zero-punch was used along with a 2-9 punch. Here is the problem, the punched hole pattern for the letters "J" through "R" are the same as the punched hole pattern for the signed, negative numbers of 1 through 9.

The following table shows the structure of a five digit numeric field using the Zoned-Decimal format (i.e. the COBOL syntax would be USAGE IS DISPLAY). The field contains a value of one-hundred-twenty-three (or 00123).

Note-1: A field that is defined as "Unsigned" (i.e. PIC 99999) is an implied positive value.
Note-2: The "Hex" is an abbreviation for Hexadecimal notation.
Note-3: A field that is defined as "Signed" (i.e. PIC S99999) will have the sign in the "Zone" nibble of the units positions (or Byte-4 in the preceding example, Byte-0 through Byte-3 will be the same for Unsigned and Signed fields). For the EBCDIC-encoded environment a X'Cn' is used as an explicit positive sign and a X'Dn' is used as an explicit negative sign. For the ASCII-encoded environment a X'3n' is used as an explicit positive sign and a X'7n' is used as an explicit negative sign.

The two options for maintaining the numeric format as zoned-decimal are covered in the following sections.

Overview, Zone-Decimal, Strict Definition
(Next) (Previous) (Table-of-Contents)

This section discusses how to maintain zoned-decimal fields or data strings in ASCII or EBCDIC and abide by the strict definition of the zoned-decimal format. The terms "signed" or "unsigned" are used when referring to numeric fields and this includes numeric, zoned-decimal fields. I prefer the terms "explicitly signed" or "implied positive". We also need to be aware that it is possible to have a "signed" field that contains zero and we could have a plus or minus zero value.

For unsigned (or implied positive) fields each digit is represented by a zoned bit value in the left-most four bits (nibble or half-word) and the binary (or decimal) value for the digit in the right-most four bits (nibble or half-word).
This would be x'F0' through x'F9' or b'11110000' through b'11111001' for EBCDIC encoding.
This would be x'30' through x'39' or b'00110000' through b'00111001' for ASCII encoding.
Note: For unsigned, zoned-decimal fields negative numbers are not allowed, all numbers are considered positive.

For signed fields the sign position (usually the low-order byte or units position) will have the ZONE, high-order four bits (left-most nibble or half-word) represent the sign and the DECIMAL, low order four bits (right-most nibble or half-word) is the binary value for the digit.

The EBCDIC format for signed, positive numbers in all positions except the sign position will be x'Fn' or b'1111nnnn . The sign position will be x'Cn' or b'1100nnnn'. The ASCII format for signed, positive numbers in all positions including the sign position will be x'3n' or b'0011nnnn'.

The EBCDIC format for signed, negative numbers in all positions except the sign position will be x'Fn' or b'1111nnnn . The sign position will be x'Dn' or b'1101nnnn'. The ASCII format for signed, negative numbers in all positions except the sign position will be x'3n' or b'0011nnnn'. The sign position will be x'7n' or b'0111nnnn'.

Overview, Zone-Decimal, Modified
(Next) (Previous) (Table-of-Contents)

A modified-zoned-decimal format occurs when the sign position (trailing or leading) is translated based on the character display value. The sign position (trailing or leading) will have the high-order four bits (left-most nibble or half-word) represent the sign and low order four bits (right-most nibble or half-word) represent the digit.

The EBCDIC format for positive numbers (i.e unsigned or implied positive) in all positions except the sign position will be x'Fn' or b'1111nnnn. For the sign position will be 'Cn' or b'1100nnnn'.

The ASCII format for positive numbers in all positions including the sign position will be x'3n' or b'0011nnnn' and the 'n' or 'nnnn' is the binary representation of the digit. The ASCII encoding format does not have two different representations for positive, zoned-decimal numbers.

When zoned-decimal fields are converted based on their character value (not their numeric value) the sign position will no longer abide by the definition of zoned-decimal. The signed, positive digits of 1-9 in EBCDIC are represented by x'C1' through x'C9' which is also the representation for the letters "A" through "I". When these are converted to the ASCII letters "A" through "I" or x'41' through x'49' the result is not in accordance with the ASCII definition for a positive value. This would maintain the rightmost nibble as a binary digit value and this is in accordance with the definition of zoned-decimal.

The next departure from the definition of zoned-decimal happens with the positive zero and negative zero through nine. A zero with a positive or negative sign in EBCDIC is x'C0' and x'D0' which is also the representation for special characters "{" and "}". Using the modified-zoned-decimal these translate to the ASCII values for "{" and "}" which is x'7B' and x'7D' and the rightmost nibble is no longer the binary value of the digit. The same is true for the negative digits 1 through 9. The EBCDIC is x'D1' through x'D9' which are the same as the letters "J" through "R". These are translated to the ASCII values of "J" through "R" which are x'4A' through x''52'. The leftmost nibble is inconsistent for a sign value and the rightmost nibble is no longer the binary value of the digit. This is a departure from the definition of zoned-decimal.

Micro Focus supports both the zoned-decimal and the modified-zoned-decimal. Refer to the SIGN(EBCDIC) directive for supporting the modified-zoned-decimal format. The directive SIGN(EBCDIC) should only be used in an EBCDIC encoded environment. For the ASCII encoded environment it should only be used with caution for exception processing.

Note: when using FTP in ASCII mode to transfer a file that contains zoned-decimal fields (or data strings) the sign position of the field will be translated based on its character value not its numeric value. This is performing a non-arithmetic function on a numeric field and results in a non-numeric format or modified-zoned-decimal format .

Table for Sign Byte, Zone-Decimal, Strict Definition
(Next) (Previous) (Table-of-Contents)

The following is a table of values for the sign position of a Zone-Decimal (strict definition) field using EBCDIC or ASCII encoding.

Table for Sign Byte, Zone-Decimal, Modified
(Next) (Previous) (Table-of-Contents)

The following is a table of values for the sign position of a Modified-Zone-Decimal field using EBCDIC or ASCII encoding.

Additional Possibilities and Considerations
(Next) (Previous) (Table-of-Contents)

This section describes possible situations that need special consideration and may take extra time to properly address.

Leading Spaces Treated as Zeroes (S0C7 or 163 Error)
(Next) (Previous) (Table-of-Contents)

On the mainframe leading spaces are allowed in a zoned-decimal, numeric field. In the Micro Focus environment the HOSTARITHMETIC and HOSTCOMPARE directives must be used. If these directives are not used and a field with leading spaces is encountered then a 163 message (non-numeric character in a numeric field) will cause the program to ABEND (ABnormally END.

Program Logic with "{}" or "A-R" Comparison
(Next) (Previous) (Table-of-Contents)

When using the strict definition of zoned-decimal in an ASCII encoded environment the comparing of the sign position for the characters of "{" and "}" will fail (on the mainframe and in the EBCDIC environment the values for a zero in the sign position of a signed-zoned-decimal field just happens to be the same as the left or right curly brace). The sign position for a positive and negative zero will be "0" (for ASCII a positive number will be printable) and "p" (this is lower case). For the EBCDIC environment the sign position for a "negative 1" through a "negative 9" are the values "J" through "R" (upper case). For ASCII this will be changed to "q" through "y" (lower case).

CHARSET(ASCII) and SIGN(EBCDIC)
(Next) (Previous) (Table-of-Contents)

The Micro Focus environment may be configured to run in CHARSET(EBCDIC) or CHARSET(ASCII) mode. In the CHARSET(EBCDIC) environment the directive for the sign is automatically set to SIGN(EBCDIC). In the CHARSET(ASCII) environment the directive for the sign is automatically set to SIGN(ASCII). Programmers should avoid using a different encoding scheme for the CHARSET and the SIGN because this will cause problems with the signed, zoned-decimal numeric fields. For example, using SIGN(EBCDIC) with a CHARSET(ASCII) environment will cause numeric check failures and 163 error messages that will cause the program execution to ABEND (ABnormally END).

If a data file conversion from EBCDIC to ASCII is done using the Data File Converter (DFCONV) with Micro Focus Mainframe Express (MFE is an EBCDIC environment) then you will have a problem if the file has records with numbers that are signed, zone-decimal because the SIGN(EBCDIC) will be used. Therefore, the data file conversion should be done using Net Express with the .STR and .PRO files being created in a project that is CHARSET(ASCII)

Now comes the CATCH-22, if a file has multiple record types and the record layout is determined by a specific character in a specific position in the record then the .STR and .PRO file must be created in a CHARSET(EBCDIC) project. This is required in order for the conditional arguments to be created as EBCDIC-encoded values in order to properly compare with the EBCDIC-encoded values in the file being converted. In this situation it will be necessary to use the SimoTime conversion technology instead of the Micro Focus Data File Converter (DFCONV).

Summary
(Next) (Previous) (Table-of-Contents)

The purpose of this document is to provide an overview of numeric data strings or fields that are signed, zone decimal format.

Software Agreement and Disclaimer
(Next) (Previous) (Table-of-Contents)

Permission to use, copy, modify and distribute this software, documentation or training material for any purpose requires a fee to be paid to SimoTime Enterprises. Once the fee is received by SimoTime the latest version of the software, documentation or training material will be delivered and a license will be granted for use within an enterprise, provided the SimoTime copyright notice appear on all copies of the software. The SimoTime name or Logo may not be used in any advertising or publicity pertaining to the use of the software without the written permission of SimoTime Enterprises.

SimoTime Enterprises makes no warranty or representations about the suitability of the software, documentation or learning material for any purpose. It is provided "AS IS" without any express or implied warranty, including the implied warranties of merchantability, fitness for a particular purpose and non-infringement. SimoTime Enterprises shall not be liable for any direct, indirect, special or consequential damages resulting from the loss of use, data or projects, whether in an action of contract or tort, arising out of or in connection with the use or performance of this software, documentation or training material.

Downloads and Links to Similar Pages
(Next) (Previous) (Table-of-Contents)

Refer to  The Numbers Connection  for additional information about the structure and processing of number data items (or numeric fields).

The  hexadecimal dump  of the parameter-buffer uses the same technique as describe in another SimoTime example that describes the dumping of a data string using COBOL. The name of the member that does the actual hexadecimal dump is called SimoDUMP. A copy file (PASSDUMP.CPY) is provided for defining the pass area.

The  SimoZAPS Utility Program  has the capability of generating a COBOL program that will do the conversion of sequential and VSAM (KSDS) files between EBCDIC and ASCII while maintaining mainframe (or COBOL) numeric formats and integrity. SimoZAPS can also read a sequential file in EBCDIC format and create an ASCII/CRLF file or VSAM KSDS file in ASCII format. The conversion tables may be viewed or modified to meet unique requirements. The Hexcess/2 function provides the capability of viewing, finding or patching the contents of a file in hexadecimal.

This item is a link to an  ASCII or EBCDIC translation  table. A column for decimal, hexadecimal and binary is also included.

The following table provides a list of white papers describing the numeric formats used on an IBM Mainframe system. A couple of sample COBOL programs are also included.

This document provides a quick summary of the  File Status Key  for VSAM data sets and QSAM files.

To review all the information available on this site start at  The SimoTime Home Page .

Glossary of Terms
(Next) (Previous) (Table-of-Contents)

Check out  The SimoTime Glossary  for a list of terms and definitions used in the documents provided by SimoTime.

Comments or Suggestions
(Next) (Previous) (Table-of-Contents)

If you have any questions, suggestions or comments please call or send an e-mail to: helpdesk@simotime.com

We appreciate your comments and feedback.

About SimoTime Enterprises
(Next) (Previous) (Table-of-Contents)

Founded in 1987, SimoTime Enterprises is a privately owned company. We specialize in the creation and deployment of business applications using new or existing technologies and services. We have a team of individuals that understand the broad range of technologies being used in today's environments. This includes the smallest thin client using the Internet and the very large mainframe systems. There is more to making the Internet work for your company's business than just having a nice looking WEB site. It is about combining the latest technologies and existing technologies with practical business experience. It's about the business of doing business and looking good in the process. Quite often, to reach larger markets or provide a higher level of service to existing customers it requires the newer Internet technologies to work in a complementary manner with existing corporate mainframe systems. Whether you want to use the Internet to expand into new market segments or as a delivery vehicle for existing business functions simply give us a call or check the web site at http://www.simotime.com