October 1998                 Issue: 5

Journal of Conceptual Modeling
www.inconcept.com/jcm

Issues in dealing with COBOL Data Structures
by Patrick Hallock

Introduction

As with most of my articles, which are motivated from issues I face in the field, this one occurs frequently. This article arises from difficulties faced when attempting to convert legacy data systems, maintained via COBOL code, to a new system. While COBOL was my initial programming language, I managed to avoid several of the problems addressed in this article because even in those days I used NIAM, a precursor to ORM, to design my data structures. I will present only a handful of issues, however, they illustrate why converting data structures can be complicated. While many mapping tools exist, I believe it would be difficult for a COBOL-to-relational-database tool to resolve all of these issues. I suppose they could get the basic structure correct, but the constraints at the conceptual level would be very difficult. Sometimes, I have trouble doing this as well.

Examples

Our first example, shown below, is a straightforward data structure, but it gives us a quick refresher on COBOL.

01 RECORD_1
    02 AT_1  (Key)
    02 AT_2
    02 AT_3

The most likely solution is to use AT_1 as the reference mode for RECORD_1. This avoids a lot of extra graphics; as shown below in Figure 1.

Figure 1: A Simple COBOL Data Structure

Our second example, below, uses a more complex key. The AT_1 field is actually defined by AT_1_1 and AT_1_2. This only slightly more involved, but is very typical.

01 RECORD_1
    02 AT_1 (Key)
        04 AT_1_1
        04 AT_1_2
    02 AT_2
        04 AT_2_1
        04 AT_2_2

The conceptual structure, shown in Figure 2, has increased in complexity. AT_1 is the key to the structure, but in turn AT_1_1 and AT_1_2 identify AT_1.

Figure 2: A More Complex Key

One other option is to eliminate AT_1 altogether under the assumption that it is unnecessary. This only works if AT_1 is not a common object or if the AT_1 (name) is not important. I would err the side of caution as illustrated since such structures often appear several times in other segments of COBOL code; especially if we are talking about the key and its potential use as a foreign key.

The third example, shown below, is more interesting. As a reminder of how a redefine works, remember it takes the same physical space in the record. Therefore, only AT_2 or AT_3 can exist within each record. This supports the exclusionary constraint between AT_2 and AT_3. The "marker" field indicates which of the two options applies to this record instance. AT_2 is identified only by AT_2_1. This is one of the difficult issues to address in reading COBOL. When we find a level with sub-levels, we need to determine what is involved in the identifier, in this case AT_2_1. AT_3 using AT_3_1 is an alternative notation.

01 RECORD_1
    02 AT_1 (Key)
    02 MARKER (used to determine which is used AT_2 or AT_3)
    02 AT_2
        04 AT_2_1 (is the reference mode of AT_2)
        04 AT_2_2
    02 AT_3 REDEFINES AT_2
        04 AT_3_1 (is the reference mode of AT_3)
        04 AT_3_2
        04 AT_3_3

Figure 3: Field Redefinition

While sometimes a "marker" field is not available, the COBOL program above is assumed to check something within AT_2 or the AT_3 structure and then proceeds. The implied data value would be moved into the "marker" field.

A more complicated redefine involves the key to the record, as below. One way to represent this, as shown in Figure 4, is to insert a system-generated key and merely treat AT_2 and AT_3 as before.

01 RECORD_1
    02 AT_2 (Key)
        04 AT_2_1
        04 AT_2_2
    02 AT_3 REDEFINES AT_2 (could be the Key)
        04 AT_3_1
        04 AT_3_2
        04 AT_3_3

Figure 4: Key Redefinition Handled by a Surrogate Key

It is possible that the "key redefine" solution above may actually be a subtype. This stems form a fundamental question: if the key is changing, are we really talking about the same thing? If not, we get a model such as the one shown in Figure 5:

Figure 5: Key Redefinition Handled by Subtypes

Our final example is an "occurs" clause, shown below. Note that while the occurs clause could have a different solution in the object-relational model, here we are limiting ourselves to a standard solution.

01 RECORD_1
    02 AT_1 (Key)
    02 AT_X OCCURS 10 TIMES
        04 AT_3
        04 AT_4

The AT_X fields is used to create the RECORD_2 to hold the OCCURS clause data. Our first option, shown in Figure 6, is to assume the relationship is 'one RECORD_1 has many RECORD_2, but the RECORD_2 data can only exist with one RECORD_1'. Our second option, shown in Figure 7, assumes that RECORD_2 can be related to many RECORD_1's. The frequency constraint enforces the original occurs of ten times regardless of the option required.

Figure 6: The Explicit Way to Handle an Occurs Clause

Figure 7: Another (Potential) Meaning of the Occurs Clause

Final Issues

I did not address the fact that common objects can be created. For example, the most likely would be DATE. Finding the common objects and creating one conceptual object requires additional effort by the modeler(s). The foreign key issue can be complex if the current database is IDMS, which often is not designed with foreign key information. Sometimes, it can be very difficult to determine the business data keys for MEMBERS within OWNERS in IDMS. The business data key probably involves data from the OWNER in addition to the MEMBER. The parsing of COBOL structures can be complicated by embedded codes. For example AT_1 has the value '0211' where 02 has one meaning, 021 has a meaning and 0211 has a meaning. This practice was common to COBOL designs are takes a lot more effort to solve than the issues addressed.

Conclusion

Combining actual data and the Object-Role Modeling methodology and mindset, one can create a sound conceptual model from a complicated mess. Just one more example of ORM's benefit to the "real world".

Patrick Hallock is a Senior Partner and Principal Consultant for InConcept. He has over 20 years of ORM/NIAM experience and is  a certified ORM consultant, trainer/train the trainer and a certified Visio trainer.

Contact Information:

Patrick Hallock
President and Co-Founder
InConcept
8171 Hidden Bay Trail N
Lake Elmo, MN 55042
path@inconcept.com
(651) 777-8484
fax: (651) 777-9634
http://www.inconcept.com

© Copyright, 1998-2004 InConcept (Information Conceptual Modeling, Inc.) All Rights Reserved. Privacy Statement.
ISSN: 1533-3825