Reading COBOL Layouts

Contents of this section:

Problems with Redefined Records? We know how to handle them!

   Examples of redefined records
   Converting to a PC database

Examples of 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. (Let's call them A, B, and C records).  When all these record types are stored in one file, that file has "multiple record types", or "redefined records". 

When a file contains multiple record types (redefined records), it often associates these records in groups.  Using the medical file example above, one patient's data might consist of a patient ID (A) record followed by one treatment (B) record followed by a payment (C) record.  Another patient's data might consist of a patient ID (A) record followed by 5 treatment (B) records, followed by 3 payment (C) records.  These patient records are often associated via a key field, but some times the order in the file is the only thing that ties them together.

Another common file structure containing multiple record types is a file that starts with a header (H) record, say to identify the vendor and run date, followed by the data records, and ending with a trailer (T) record which contains a record count and totals of the individual records. These totals are often used as a check of the data after importing; the sum of the individual records should equal the total in the trailer record.

A typical COBOL medical file might contain both these concepts. It may start with a header (H) record, followed by groups of A, B, C records (one group for each patient), and end with a trailer (T) record. That gives you a file with 5 record types.

Converting to a PC database

Most PC databases can make use of relational tables (or files), but usually can't deal with all these record types in one file.  There are several ways to deal with this, and the best choice will be dictated by both the COBOL file structure and the PC application requirements. Some of the solutions are:

1. Remove record types you don't need.
Sometimes only one of the record types is needed. For example, a file may contain a header record that identifies the vendor or receiver, then detail records (the data you actually need), followed by a trailer summary record. You can discard the header record, keep the data records, and discard the trailer record (you might want to check the header and trailer records first!). Now you have only one record type.

2. Simply write each record type to a separate file.
Occasionally you can separate each record type into a separate file without relating them. This is seldom the case, but when it is an option, it's usually the easiest way to go.  Using the medical example above, if you wanted to analyze the geographic distribution of patients who checked into the hospital, you would only need record type A. And if you wanted to separately analyze the treatments they received, you would only need the B records. You would not need an association between the A and B records for either analysis.

3. Append multiple record types into one new type.
This works best if there is a one-for-one correspondence of a small number of record types. For example, a single A record followed by a single B record. You can append record B to record A, creating a new record, A+B.  If you have one A record followed by several B records, it can get messy. It's generally best to relate these, but you might be able to prepend the A record to each B record, depending on the data and the application. You need to be careful, as that will multiply the number of A records. If you later forget you've done this and, say, sum the values in all the A records, you will get an inflated value.

4. Combine all the needed data into one new record.
When there are too many records for method 3 to be effective, you might write a COBOL program to read all the related records into memory, then write a completely new output record. The new record could be whatever you wish, mixing data from the multiple records read, perhaps even summing the detail records. This is particularly useful if you are analyzing complex data, and all you need are the totals, not all the detail. For example, you might sum all the weekly sales records for a product and generate one record with the annual total. That would compress 53 records (1 A record + 52 B records) into one new record.

5. Split the data into multiple files, one for each record type.
Then you can import them into separate tables in a PC database and relate them. This is the method usually used, and the "proper" way to convert a multiple record COBOL file to a relational PC database. The original records often have a key that is common to all record types, which can be used to relate the PC tables. If there is no key, DISC can generate one when we do the conversion. Generating a key, however, requires understanding the data sufficiently well to properly group the related records. So it may not be a trivial task.

There are variations on these themes. For example, in a file with 6 record types, you might start by discarding the header and trailer, then combine two records into one, then add a key and write the three resulting record types to three files, for import into three tables in the PC database.