Microsoft KB Archive/47437

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Complete Details of COBOL 2.x Data Types; COMP & USAGE DISPLAY

PSS ID Number: Q47437 Article last modified on 04-20-1993

2.00 2.10 2.20 MS-DOS

The information in this article applies to:

- Microsoft COBOL for MS-DOS, versions 2.0, 2.1, and 2.2

Summary: This article details the data types for Microsoft COBOL Versions 2.0, 2.1, and 2.2. This article describes each of the data types, giving an sample PICTURE clause and description of how each appears in memory.

Detailed Description

PIC X and PIC A (Alphanumeric, Alphabetic) These values are stored in memory just as they appear in the PICTURE clause, 1 byte per character. For example, the following occupies exactly 10 bytes in memory, stored as ASCII characters only: PIC A(10) VALUE “ABCDEFGHIJ” or PIC X(10) VALUE “ABCDEFGHIJ”
PIC 9 and S9 nonCOMPUTATIONAL (Numeric and signed numeric) PIC 9(1) to PIC 9(18) A PIC 9 (or S9) is numeric (or signed numeric) if you don’t give any other usage clause after the PICTURE clause. PIC S9(1) to PIC S9(18) Same as the above except the right-most digit also holds the sign. The following chart describes how the sign is stored in the right-most digit of a PIC S9(n) FIELD the VALUE. The chart should be read as follows (in the chart you’ll see the entry): -0 } This means that if the last character in a negative number is 0 (zero), when the data item is DISPLAYed, the last character is }. For example, you would see 12} if you did a DISPLAY of the following: PIC S9(3) VALUE -120 Input Value Last Character Stored As ———– ————————- 0 { -0 } 1 A 2 B 3 C : : 9 I -1 J -2 K : : -9 R The above values are found only in the right-most position. All other values appear normal. The following are some examples of PICTURE clauses and how they appear in memory: PIC Clause Input Value Stored As (ASCII Characters) ———- ———– ——— PIC S9(4) 1112 111B PIC S9(5) -1112 0111K PIC 9(4) 1112 1112 PIC 9(5) 1112 01112
PIC 9 and S9 COMP-0 (two’s complement short integer) Data-items whose USAGE is COMP or COMP-0 occupy 2 bytes of memory and represent short integers in the range -32,768 to 32767. PIC 9 COMP-0 through PIC 9(5) COMP-0 are stored as 2 bytes total. PIC S9 COMP-0 through PIC S9(5) COMP-0 are stored as 2 bytes total. Note: If you go beyond PIC 9(5) COMP-0, the compiler flags this, issues a warning, and converts the COMP-0 into COMP-3 with USAGE DISPLAY. For example, PIC 9(6) COMP-0 through PIC 9(18) COMP-0 are not stored as COMP-0, but as COMP-3 USAGE DISPLAY. PIC S9(6) COMP-0 through PIC S9(18) COMP-0 are not stored as COMP-0, but as COMP-3 USAGE DISPLAY. PIC Clause Input Value Stored As ———- ———– ——— PIC 99 COMP-0 1 01 hex (1 byte, two’s complement) PIC S99 COMP-0 -1 FF hex (1 byte, two’s complement) PIC 9(6) COMP-0 1 000001 ASCII (COMP-3 USAGE DISPLAY) PIC S9(6) COMP-0 -1 00000J ASCII (COMP-3 USAGE DISPLAY) Note: Remember, in the above table, PIC 9(6) and S9(6) are converted to COMP-3 USAGE DISPLAY because the PICTURE clause is too large.
PIC 9 and S9 COMP-4 (two’s complement long integer) Data items whose USAGE is COMP-4 occupy 4 bytes of memory and represent long integers in the range -2,147,483,648 to 2,147,483,647. PIC 9 COMP-4 through PIC 9(10) COMP-4 are stored as 4 bytes total PIC S9 COMP-4 through PIC S9(10) COMP-4 are stored as 4 bytes total Note: If you go beyond PIC 9(10) COMP-4, the compiler flags this, issues a warning, and converts the COMP-4 to COMP-3 USAGE DISPLAY. For example, PIC 9(11) COMP-4 through PIC 9(18) COMP-4 are not stored as COMP-4, but as COMP-3 USAGE DISPLAY. PIC S9(11) COMP-0 through PIC S9(18) COMP-4 are not stored as COMP-4, but as COMP-3 USAGE DISPLAY. Input PIC Clause Value Stored As ———- —– ——— PIC 99 COMP-4 1 01 hex (1 byte, two’s complement) PIC S99 COMP-4 -1 FF hex (1 byte, two’s complement) PIC 9(11) COMP-4 1 00000000001 ASCII (COMP-3 USAGE DISPLAY) PIC S9(11) COMP-4 -1 0000000000J ASCII (COMP-3 USAGE DISPLAY) Note: Remember, in the above table, PIC 9(11) is converted to USAGE DISPLAY because the PICTURE clause is too large.
PIC 9 COMP-3 (Packed Decimal) The number of bytes that a COMP-3 item occupies is determined by the formula stated in the “Microsoft COBOL Reference Manual” for Versions 2.0, 2.1, and 2.2 for MS-DOS, which is as follows. An internal decimal item defined by PIC 9(n) COMP-3 in its PICTURE clause occupies (n+2)/2 bytes in memory (rounded down) or off. All bytes except the right-most contain a pair of digits, and each digit is represented by the binary equivalent of a valid digit value from 0 to 9. The item’s low-order digit and the operational sign are stored in the right-most byte of a packed item. For this reason, the compiler considers a packed item to have an arithmetic sign, even if the original PICTURE clause lacks an S-character. Example 1: A PIC 9(5) COMP-3 VALUE 12345 would occupy (5+2)/2 bytes, which is 3 bytes when rounded down. It would appear as follows: 1 2 3 4 5 sign 0001 0010 0011 0100 0101 xxxx |___________| |__________| |__________| 1st Byte 2nd Byte 3rd Byte The sign will be either 1100 (hex C) for positive or 1101 (hex D) for negative. Example 2: A pic 9(6) COMP-3 VALUE 123456 would occupy (6+2)/2 bytes, which is 4 bytes. It would appear as follows: |<– unused | V 1 2 3 4 5 6 0 sign 0001 0010 0011 0100 0011 0100 0000 xxxx |___________| |__________| |__________| |__________| 1st Byte 2nd Byte 3rd Byte 4th Byte Note: There is no way to determine where a decimal point lies in a data item in memory or a file. This is because there are no markers to designate a decimal point. All decimal points in COBOL are implied. This means that the program itself remembers where the implied decimal points are stored and makes the correct alignment. None of this information is stored in the data itself or in the file. For instance, if we had declared PIC 9(3)V9(2) VALUE 123.45 in the above example, it would appear exactly the same in memory or in the file as a PIC 9(5) VALUE 12345 (see the diagram above). The actual .EXE program remembers where the decimal was located. If the original code description is lost or the program destroyed, there is no way to determine where decimal points were located in a file.