Redefined Fields & Records

This is a discussion of redefined fields and redefined records: what they are, why they are used, and how to deal with them on a PC.

Redefined Fields

Mainframe languages, especially COBOL, often reuse, or "redefine" an area in a record to save space. A common example is a mailing list where the addressee may be either a person or a company, but never both.  To include both an individual name field and a company name field would waste space, since only one of them would ever be filled, so the name field can be reused (redefined) as company name.

Furthermore, while a company name requires just one field, the individual name is usually composed of two fields, last name and first name. For example, bytes 1-12 might be last name, and bytes 13-20 the first name.  But when redefined, bytes 1-20 would be the company name.  Now you have two fields redefined by one field. COBOL can handle this just fine, but most PC applications don't use redefined fields and do not deal with this well.

Need to convert COBOL files? That's our business!

Consider the highlighted fields in the following layout for a mailing list. Last name and first name are put into a group called INDIVIDUAL-NAME, then that group is redefined by COMPANY-NAME. (See Reading COBOL Layouts for more information about groups and reading COBOL layouts.)

       01  SUBSCRIBERS.
           05  INDIVIDUAL-NAME.
               10  LAST-NAME                           PIC X(12).
               10  FIRST-NAME                          PIC X(8).
           05  COMPANY-NAME REDEFINES INDIVIDUAL-NAME  PIC X(20).
           05  ADDRESS                                 PIC X(20)
           05  CITY                                    PIC X(15)
           05  STATE                                   PIC X(2)
           05  ZIP                                     PIC X(5)

When a field is redefined, there should be a way to identify which definition was used in a given record. Unfortunately this is not always the case, and sometimes you have to try to figure it out by inspecting the data. The most common way to identify the use is to add a field to indicate it. For example, there might be a field called TYPE-OF-NAME, where "I" means the name is an individual and "C" means it's a company. This is how the layout might appear:

       01  SUBSCRIBERS.
           05  TYPE-OF-NAME                            PIC X.
           05  INDIVIDUAL-NAME.
               10  LAST-NAME                           PIC X(12).
               10  FIRST-NAME                          PIC X(8).
           05  COMPANY-NAME REDEFINES INDIVIDUAL-NAME  PIC X(20).
           05  ADDRESS                                 PIC X(20)
           05  CITY                                    PIC X(15)
           05  STATE                                   PIC X(2)
           05  ZIP                                     PIC X(5)

Let's look at these fields in two records, one addressed to "John Smith" and the other to "Disc Interchange". The fields in those records would look like this:

ISmith       John    123 Main Street     Boston         MA01234
CDisc Interchange    124 Main Street     Boston         MA01234   

If you ignore the redefined fields and print the name (on an envelope for example), one of the names will come out wrong. If you use the COMPANY-NAME definition, then "Disc Interchange" will be correct, but the mail to John Smith will be addressed to "Smith       John".  If you use the LAST-NAME, FIRST-NAME fields, and print the first name followed by 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".  

Since PC applications generally don't use redefined fields, there is usually no good mechanism for dealing with this situation. If your application can't deal with this, we can convert the data to a record with both individual name fields and company name fields.

Since redefined fields share the same space, by definition they have the same size. Although recent compilers (COBOL85 and later) will permit redefined fields to be larger or smaller than the initial definition, and automatically adjust both definitions to the largest field, it's convention (and good programming practice) to define them to be the same size, by adding a FILLER field if necessary. There is further discussion of this in our Reading COBOL Layouts series.

Often the redefined fields are of a different type altogether.  For example, redefining a character field as a binary field.  This is a much more serious situation than the above example, and the original field and the redefined field require different conversions (character and binary). Using the wrong data type could seriously corrupt the data.

Binary fields increase in size when converted to numeric display fields. This will cause the output field, and hence the output record, to be larger than the original input data.  If that binary field shares space with a character field via a redefines, this may force you to change the character field that shares that space.  If, for example, the original file has a 4 byte character field redefined by a 4 byte binary numeric field, after conversion to numeric ASCII, the numeric field will be larger, and the character field will still be 4 bytes. You will have to reserve space in the output file for the larger numeric field, and you will have to either increase the character field to that larger size, or add a filler field. If you add a filler field, you need to put both fields in a group, and redefine the group, not the character field.

There is a more detailed discussion of redefined fields, including other uses for redefined fields, and the rules for redefined fields, in Part 3 of Reading COBOL Layouts.

Redefined Records

Complex data sets usually cannot store all their data in just one record type, so they have multiple record types.  For example, medical records may have a record type to identify a patient (name, address, etc.), another record type for treatment data, and a third for payment information.  These could be stored in three files, or in one.  If they are stored in one file, then that file has "multiple record types", or "redefined records".  PC databases can make use of relational tables (or files), but usually can't deal with all three record types in one file.  Disc Interchange can split the data into three files and add a key so you can build a relational database on your PC.

For more detail on redefined records, and solutions for converting them to PC files, see Part 6 of Reading COBOL Layouts

Additional Information

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

Our COBOL Conversion Services Disc Interchange Service Company has years of experience dealing with COBOL files containing redefined fields and records. We employ many methods to convert the data to a PC database.  With over 32 years of experience with thousands of files, we have the knowledge to suggest the best options for handling redefined fields and multiple record types.   We are especially good at automating repeat conversions of files with multiple record types.  If you need to convert the same data on a regular basis, we can write a custom program to convert and Q.C your data to your specifications.  Our experience in automating the conversion process results in significantly lower cost, and excellent quality-control.

Mainframe & AS/400 Conversion to PC With 32 years experience, we are the experts at transferring mainframe data to PCs.