This tutorial on how to read
a COBOL layout was written specifically for our customers who have had a conversion
performed at Disc Interchange and have received a COBOL layout with the data.
It is intended to give you enough information to read most
simple layouts. It does not cover all topics or everything you would
find in a complex layout, and it is intended to explain COBOL layouts only
so you can use your converted data, not so you can write COBOL programs.
This article begins here: Reading COBOL Layouts where you will also find a topic index.
Contents of this section:
That's our business!
COBOL has several types of numeric fields. These data types include a "DISPLAY" field, which is composed of characters (the EBCDIC or ASCII characters for 0 - 9), binary fields, packed fields, and floating-point fields. There are also options for a separate + or - sign or a sign overpunch, and for real or implied decimal. The data type is specified by the "USAGE IS" clause.
05 ACCOUNT-BALANCE PIC S9(6)V99 USAGE IS COMPUTATIONAL-3.This says to store the field in the computational-3 format. The "usage is" part is optional and generally left off, and "computational" can be abbreviated "COMP", so you will more commonly see this written
05 ACCOUNT-BALANCE PIC S9(6)V99 COMP-3.The types of numeric fields you will commonly see in COBOL layouts are:
Because of the overpunch, the digit that holds the sign will not appear as a number when the field is viewed in EBCDIC character mode. If you have the field
05 ACCOUNT-BALANCE PIC S9(6)V99.and view a value of 1.23 with an EBCDIC editor, it will read "0000012C".
ASCII COBOL compilers also use a Signed data type with an overpunch, but the sign bits are different and not standardized between compilers. See our Tech-Talk brief Signed Fields for further details on both EBCDIC and ASCII Signed fields.
SIGN IS SEPARATE (or SIGN SEPARATE)This may be combined with the leading or trailing clause:
SIGN IS LEADING SEPARATE (or SIGN LEADING SEPARATE)
or SIGN IS TRAILING SEPARATEThis statement can be applied to an elementary item (field) or to the entire record.
COBOL defines several binary data types. We will list a brief summary here, and you can find more detail in COBOL Computational Fields and in COBOL Comp-3 Packed Fields. Before we start, there is one important point to understand: The COBOL standard leaves the actual implementation of most data types up to the vendor who wrote the COBOL compiler. The reason for this is because different computers -- CPUs -- use different binary representations internally, and function best with their own type of binary numbers. This approach results in better and faster compilers, but also causes confusion, because a "comp" data type on one machine is not necessarily the same as "comp" on another machine. The table below lists the common uses; not all compilers will follow these types. For more details on word order and signs see the link above.
Which data type a field uses
for storage is determined by the "usage is" clause in the field definition,
and in most cases the number of bytes of storage is determined by the number
of digits in the PIC. Floating point numbers follow standard binary formats
and as such their sizes are not determined by a PIC, and no PIC is used
in the field definition.
|Data Type||Description of how this data type is stored|
|Binary||This is a pure binary number, usually in 2's-complement, and usually either 2, 4, or 8 bytes.|
|Comp||The COBOL standard intends that the comp data type be implemented using the most efficient data type for a particular machine. The compiler vendor will chose the best type for the CPU, probably binary.|
|Comp-1||This is generally a single precision floating point data type.|
|Comp-2||This is generally a double precision floating point data type.|
|Comp-3||Comp-3 is very common and its format is nearly universal across platforms. It "packs" two digits into each byte. See COBOL Comp-3 Packed Fields for a full description of this data type.|
|Packed Decimal||Packed decimal is usually implemented as comp-3. See comp-3.|
05 INVOICE-TOTAL PIC 999.99.OR:
05 INVOICE-TOTAL PIC 9(3).9(2).The presence of the "." in the PIC causes a real decimal in the file. Implied decimal, however, is much more common in COBOL.
05 ACCOUNT-BALANCE PIC 9(6)V99.is an implied decimal field. There are 6 digits, then an implied decimal - the V - and 2 more digits, for a total of 8 digits. The field is 8 bytes in size; there is no "." in the file -- the location of the decimal point is implied to be between the 9(6) and the 99. If the field contains "00000123" then the account balance is $1.23, because there is a decimal implied between the dollars and cents.
If you specify a comp field in the middle of a record, and it doesn't happen to begin on a 32 bit (4 byte) boundary, the compiler will "align" it to a 32 bit boundary to "synchronize" it. What's actually stored in the file may not be the same as the PICs on the layout indicate. This is not a very common problem, partly because binary and comp fields are not very common in files, but you should be aware of it.
Next: Part 5 Tables
For more articles on data conversion, see our TechTalk Index.
Our COBOL Conversion Services
Disc Interchange Service
Media Conversion Specialists
15 Stony Brook Road
Westford, MA 01886