|
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:
 We can help! |
In the example below, the field PO-BOX redefines the field STREET-ADDRESS.
05 STREET-ADDRESS PIC X(20). 05 PO-BOX REDEFINES STREET-ADDRESS PIC X(20).Notice these are both 20 bytes, and they both occupy the same 20 bytes in the record, because the second definition redefines the first one. When you add the field sizes to determine the starting column of each field, be sure you don't count the size of the redefining fields. To do so would count those fields twice.
Fields and groups can both be redefined by other fields or groups. That is, a field can redefine another field or group, and a group can redefine a field or another group.
In the example below, the field PO-BOX redefines the group STREET-ADDRESS.
05 STREET-ADDRESS. 10 ADDRESS-LINE-1 PIC X(20). 10 ADDRESS-LINE-2 PIC X(20). 05 PO-BOX REDEFINES STREET-ADDRESS PIC X(40).Again, notice they are both the same size -- 40 bytes.
In the example below, the group RURAL-ADDRESS redefines the group STREET-ADDRESS.
05 STREET-ADDRESS. 10 ADDRESS-LINE-1 PIC X(20). 10 ADDRESS-LINE-2 PIC X(20). 05 RURAL-ADDRESS REDEFINES STREET-ADDRESS. 10 RURAL-ROUTE PIC 9(3). 10 RR-BOX-NUMBER PIC X(10). 10 FILLER PIC X(27).The total size of the fields in both the original group and the redefining group is 40 bytes. Notice the use of the FILLER to make up the difference. Notice, too, that RURAL-ROUTE is a numeric field redefining an alpha-numeric field.
Also notice that the field sizes in the two groups are not the same. RURAL-ROUTE is three bytes, while ADDRESS-LINE-1 is 20 bytes. This, and the filler at the end, precludes you from using just the first definition and ignoring the second definition. (Recall that FILLER fields can contain any value, so you can't count on them containing spaces).
Now let's add a redefined field to the layout of the previous section:
01 CUSTOMER-RECORD. 05 CUSTOMER-NAME. 10 LAST-NAME PIC X(15). 10 FIRST-NAME PIC X(8). 05 COMPANY-NAME REDEFINES CUSTOMER-NAME PIC X(23). 05 STREET-ADDRESS PIC X(20). 05 CITY PIC X(17). 05 STATE PIC XX. 05 ZIP-CODE PIC 9(5). 05 FILLER PIC X(10).COMPANY-NAME is a field that redefines the group CUSTOMER-NAME. COMPANY-NAME is at the same level, 05, as the field it redefines, and it names the field it redefines, CUSTOMER-NAME. Notice the field specification can span lines; it's the period that ends it, not the CR-LF. A field or group can be redefined multiple times; there could be a third definition for that area of the record.
In versions of COBOL prior to COBOL 85 the size of a redefining field (COMPANY-NAME) or group had to be the same size or smaller than the field or group it redefined. If it is smaller it's good practice to add a FILLER field to make up the difference, although this is not mandatory. It is no longer required that the first definition be the largest, although it's still common practice.
Starting with the 1985 COBOL standard; compilers will adjust the size of all redefines to make them all the same size. But the layout really should specify these sizes to minimize confusion. Just be aware that a redefines could change the size of another field or group at compile time.
To recap what we have in
our record above, bytes 1-23 contain either a person's name (last name
then first name), or a company name. Bytes 24-43 contain a street address,
bytes 44-60 the city, bytes 61-62 the state code, bytes 63-67 the ZIP-CODE,
which must be numeric, and bytes 68-77 are FILLER.
01 CUSTOMER-RECORD. 05 TYPE-OF-NAME PIC X. 88 PERSON VALUE 0. 88 CORPORATION VALUE 1. 05 CUSTOMER-NAME. 10 LAST-NAME PIC X(15). 10 FIRST-NAME PIC X(8). 05 COMPANY-NAME REDEFINES CUSTOMER-NAME PIC X(23). 05 STREET-ADDRESS PIC X(20). 05 CITY PIC X(17). 05 STATE PIC XX. 05 ZIP-CODE PIC 9(5). 05 FILLER PIC X(10).If TYPE-OF-NAME is set to 0 we know this record contains a person's name, and if it's set to 1 we know it contains a company name. These values are the binary values 00 hex and 01 hex, so when using this file you will have to deal with the binary data (or have us convert it).
1. Sometimes a redefined field is just to have two different views of the same data. The date in the example below is always the same data (i.e., it's not changed by the redefine), but you can refer to the entire date by referencing the field EXPIRATION-DATE, or you can perform calculations on just the year, month, or day by using the redefined fields (note the redefined is numeric).
05 EXPIRATION-DATE PIC X(8). 05 EXPIRATION-DATE-NUMERIC REDEFINES EXPIRATION-DATE. 10 EXPIRATION-YEAR PIC 9(4). 10 EXPIRATION-MONTH PIC 99. 10 EXPIRATION-DAY PIC 99.2. A program may no longer use a field, and the programmer will re-use that space for completely new data with a redefine. This is safer than just changing the name of the field, since any old programs that might be left around would crash if the old field was simply gone. In this case there may be no information like the "TYPE-OF-NAME" field above; the newly modified program will simply use the new definition. That may be okay for the originator of the data, because he knows what he did, but it leaves a new user of the file wondering which definition to use. The data dictionary may help explain this change.
3. Sometimes the same type of data will be stored two different ways. For example, an account number may be in alpha-numeric format in some records and comp-3 format in others. Although that may sound absurd, there may be valid historical reasons for it, and we see it more often than you'd expect. One company may acquire another and merge the two databases. The original company may use a 5 character alpha-numeric with a letter prefix, and the new company may use a 9 digit packed field. To convert either could mean major reprogramming, but they will both fit in the original 5 byte field with a redefine.
For instance, in the address example at the beginning of this section, perhaps it doesn't matter to you that the address may be a street address or a Post Office Box -- you will treat both the same way. In this case you can ignore the redefines.
However, even if the data types are the same, the content may force you to deal with both definitions. For example, consider two records, one for the individual "Smith John " and the other for the company "Disc Interchange ". If you ignore the redefined issue, and treat the field as the company definition, then "Disc Interchange" will be correct, but the mail to John Smith will be addressed to "Smith John" (including the spaces). If you treat the fields as an individual's name and put the first name before the last name, then the individual's name will be correct, like "John Smith", but any company name will get scrambled, like "ange Disc Interch". If your application can't deal with this, Disc Interchange can convert the data to a record with both individual name fields and company name fields.
Next: Part 4 Numeric Fields
For more articles on data conversion, see our TechTalk Index.
Our COBOL Conversion Services |
|||||
|
Disc Interchange Service
Company, Inc.
Media Conversion Specialists
15 Stony Brook Road
Westford, MA 01886
