Reading COBOL Layouts

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.

Part 3: Redefined Fields

This section introduces the concept of Redefined Fields and explains their use.  There is a simpler introduction to redefined fields and records in the article Redefined Fields & Records

Contents of this section:
Problems with Redefined fields? Request a COBOL quote
We can help!

   The Concept of Redefined Fields
   Determining Which Definition to Use
   Other Reasons for Redefining Fields
   Ignoring Redefined Fields

The Concept of Redefined Fields

The area occupied by a field in a COBOL layout can be re-used for different data by redefining the original field. This does exactly what it says -- it redefines the space used by a field for another use.

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.
 

Determining Which Definition to Use

Our record layout can now accommodate either individual name or company name, but we have no way to know if a particular record has a company name or an individual name.  So we'll add a field called "TYPE-OF-NAME" to indicate which data the record contains -- i.e., which definition to use.
   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).

Other Reasons For Redefining Fields

The reason for the redefined fields above is that we may want to alternate using individual and company names, but sometimes fields get redefined for other reasons. Some possible reasons are:

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.

Ignoring Redefined Fields

If a redefined field is a different data type than the original definition, such as a binary numeric field redefining a character field, generally you cannot ignore the redefinition.  You will need to treat the records with binary numbers as numeric data and the records with letters as character data.  However, if both the original field and the redefined field are the same data type, such as character fields, you may be able to use the original definition and ignore the redefines.

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
 

Additional Information

For more articles on data conversion, see our TechTalk Index.

Our COBOL Conversion Services

Disc Interchange Service Company has been dealing with redefined fields for over twenty years.  We know how to convert them into a useful file for your application.
 
Mainframe & AS/400 Conversions
Mainframe & AS/400 Conversion to PC

With 32 years experience, we are the experts at transferring mainframe data to PCs.
Get more information on IBM Mainframe conversions
Request a COBOL quote

Disc Interchange Service Company, Inc.
Media Conversion Specialists
15 Stony Brook Road
Westford, MA 01886

Copyright © 1997 - 2015 by Disc Interchange
All rights reserved. See our copyright page.

Home