ZONED DECIMAL DATA

Zoned decimal is a carry-over from the old 80-column, punch-card era. Essentially, each digit of a decimal number occupies 1 byte of a zoned decimal field. The top four bits (the zone) are set on in a normal zoned decimal number. The default hexadecimal value for the zone is X'F'. The bottom four bits (the digit) of the byte represent the numeric value. For example, a value of 3 would be X'F3', a value of 4 would be X'F4', and so on.

The sign (sometimes referred to as the status) of a zoned decimal field is stored in the top four bits of the right-most byte of a zoned decimal field. The sign can be X'C' or X'D' for negative values (X'D' is the default), and X'A', X'B', X'E', or X'F' for positive values (X'F' is the default). The dual negative signs are a result of the way the COBOL language sets the bits for negative values. COBOL uses X'C' for its negative sign; RPG and other AS/400 languages use X'D'. Both are supported by all AS/400 languages and system functions. The multiple positive signs result from treating any non-negative number as positive.

Figure B.1 shows the storage for a typical five-position zoned decimal field. The value of the field below is set to 3741.

Byte Position	1	2	3	4	5
Zone	F	F	F	F	F
Digit	0	3	7	4	1

Figure B.1: Storage for a five-position zoned decimal field (value 3741).

The digit portion of a zoned decimal field identifies the numeric value. The zone portion of each byte (except the sign byte) can contain any value. During an RPG operation, the zone of each byte (except the sign byte) is set on (i.e., set to B'1111' or X'F'). This includes mathematical, move, copy, and output operations.

The zone of a zoned decimal field is ignored (except for the sign). Consequently, operations on zoned decimal fields are forgiving when some invalid data appears. For example, a five-position zoned decimal field with a value of 3741 could appear as shown in Figure B.2 without any errors occurring.

Byte Position	1	2	3	4	5
Zone	A	8	8	D	E
Digit	0	3	7	4	1

Figure B.2: Another representation of a zoned decimal field with a value of 3741.

This value is tolerated because the zone portion of a zoned decimal field is ignored. The sign is also tolerated because it is between X'A' and X'F' (i.e., X'E'). When this zoned decimal field is used, the operating system translates the zone of each byte (except for the sign) to X'F'. Consequently, the value is treated as though it were coded as X'F0F3F7F4F1'.

The sign of a zoned decimal field is handled a little more strictly. The zone portion of the right-most byte (i.e., the sign of the zoned value) must be one of the entries in Table B.1.

Table B.1: Valid Sign Values of a Zoned Decimal Field

Zone Value (in Hex)	Zone Value (in Binary)	Sign (Status)	Description
X'F'	B'1111'	+	All bits are on, the sign is positive (DEFAULT).
X'D'	B'1101'	-	Bit 2 is off, the sign is negative (DEFAULT).
X'A'	B'1010'	+	Bits 1 and 3 are off, the sign is considered positive.
X'B'	B'1011'	+	Bit 1 is off, the sign is considered positive.
X'C'	B'1100'	-	Bits 2 and 3 are off, the sign is negative.
X'E'	B'1110'	+	Bit 3 is off, the sign is considered positive

If the right-most byte's zone is not one of the values listed in Table B.1, and FIXNBR(*ZONED) is specified, the sign is translated to a positive sign (i.e., X'F').

Zoned Decimal Data Errors

There are two situations that cause decimal data errors for a zoned decimal field. Decimal data errors occur when FIXNBR(*NONE) is specified when the source file is compiled.

• When a sign value other than X'A' to X'F' is used. Any other value, that is X'0' to X'9', in the sign location generates a decimal data error.

• When any digit in the zoned decimal field contains a value other than X'0' to X'9', a decimal data error is issued. Any other value, that is X'A' to X'F', in the digit location generates a decimal data error.

This creates a problem with the use of zoned decimal fields in data structures. A data structure subfield of type zone decimal is, by default, initialized to blanks—which is X'40'. This is, by its very nature, invalid decimal data. There are several methods to prevent this type of decimal data error, including:

• Specify the INZ keyword on the numeric data structure subfield. This initializes the subfield based on its data type. Hence, numeric fields are initialized to zero instead of blanks.

• Move zeros or some other valid numeric value into the subfield prior to using the subfield in another operation.

• Clear the subfield with the CLEAR operation. The CLEAR operation is a "smart" op code (in that it is context sensitive). When it is used on a decimal field, it is smart enough to move zeros into the field.

• Clear the data structure containing the subfield with CLEAR operation code. The CLEAR operation moves either blanks or zeros to each data structure subfield based on the data type of the subfield. However, because data-structure subfields can, and often do, overlap one another, the CLEAR operation can cause a decimal data error to occur in a later operation. The CLEAR operation clears subfields in the order they appear in the RPG program (not by their physical location within the data structure). Therefore, should both a zoned decimal subfield and a character subfield occupy the same physical location, the subfield that appears last in the definition specifications dictates the value moved into the positions within the data structure.

• Specify that the data structure containing the subfield is initialized at program start time. This can be accomplished by specifying the INZ keyword on the data structure name definition specification. Again, subfields are initialized based on their occurrence in the RPG definition specifications. Therefore, the same criteria as the CLEAR operation applies to the INZ keyword.