Computer Standards & Interfaces 15 (1993) 301-305 301 North-Holland

The object-oriented C O B O L model *

D a n C l a r k e a n d J e r o m e G a r f u n k e l a

Micro Focus Inc., 2465 E. Bayshore RD., Palo Alto, CA 94303, USA

Abstract

'The object-oriented C OB OL model ' will reassure the reader that COBOL is not dead nor is it dying. This paper explores characteristics of various models being considered for the new and extended object oriented version of the COBOL programming language. It contrasts the models behind the traditional COBOL language (relevant to 1959) and the new C O B O L language (relevant to the 1990s). It includes a discussion of some criteria the Object Oriented COBOL Task Group (X3J4.1) is considering while defining the new object-oriented COBOL. Lastly, this paper presents a proposed time schedule for the revision of the 34 year old C OB OL language.

Keywords. Models; object-oriented; COBOL; languages; programming; static; dynamic; application development; prototyp- ing; event-driven; interactive; OOCTG; X3J4.1; CODASYL; ANSI; type checking; legacy; ANS 85; ANS 85/89; intrinsic functions; Micro Focus

1. M o d e l 2. C O B O L m o d e l

The dictionary defines a model, in one context, as " . . . a representation (that) show(s) the con- struction of a system . . . . " For computer pro- grammers, the model of their programming lan- guage shows the design of the computing engine that ultimately executes h i s /he r code. This in- cludes the language's syntax, semantics and mem- ory management specifications as well as the un- derlying run-time support services required to execute programs written in that language. The significance of a reference model is great. Under- standing a particular language model means un- derstanding what can be done with that language - easily or with difficulty - and what cannot be done. The initial design of a programming lan- guage, the creation of its model, must take into consideration what this language will be called upon to do.

* Between the time the first draft of this paper was written and the time it was published, the C O D A S Y L Object Oriented C O B O L Task Group (OOCTG) officially changed to X3J4.1.

Correspondence to: J. Garfunkel, 105 Old Mill Road, Manhas- set NY 1'1030, USA.

In 1959, the year COBOL was conceived, in- formation technology was very different from what it is today. Transaction processing, personal com- puters, interactive systems, graphical-user-inter- faces (GUIs), client-server LANs, development workstations, etc., were not around then, or at least not in their present form. The original model upon which the COBOL language was built re- flects the environment in which it was conceived. COBOL was conceived to solve 'batch processing problems' in a sequentially ordered system. Over the years, under the guidance of CODASYL, ANSI and ISO, the COBOL model, and conse- quently the COBOL language, has changed to accommodate new application development tech- nologies - both hardware and software. The COBOL language, one of the most important tools used to develop modern applications has reflected and must continue to reflect today's technology. With this goal in mind, the CODA- SYL COBOL committee, in November of 1989, chartered the Object Oriented COBOL Task Group (later called X3J4.1) to develop a techni- cal report for incorporating object-oriented tech- nology into the COBOL language.

0920-5489/93/$06.00 © 1993 - Elsevier Science Publishers B.V. All rights reserved

302 D. Clarke, J. Garfunkel

Some argued that the COBOL language and object-oriented methods are incompatible. Those making this claim still think of COBOL as the batch processing language it was 30 + years ago and ignore the fact that COBOL is used to write some of the interactive, event-driven applications running on pc's and mainframes today.

The question of program language compatibil- ity, COBOL or otherwise, with a specific design paradigm is really whether the syntax and seman- tics of that language facilitate (well, poorly or not at all) the concepts of that methodology. There is no reason to believe that the COBOL language could not be extended to include constructs to facilitate the object-oriented paradigm like it had been extended, in the past, to include 'structured' features and other design methods, albeit with more extensibility this time.

functions. This often is a non-trivial process in- volving searches through the inheritance hierar- chy to bind message to method and through di- rectories of external files to load appropriate object instances. The run-time complexity needed to support such a dynamic environment, when implemented well, should be transparent to the application developer. In this 'dynamic' object oriented model, changes can be introduced incre- mentally, supporting rapid prototyping. The price for this flexibility, however can be performance, measured by the number of messages-per-second which can be supported by the executing environ- ment.

4. Object oriented COBOL model

3. 'Static' and 'dynamic' models

There are quite a few languages that claim to support the object-oriented paradigm. These lan- guages can be grouped into two major categories which we will label as 'static' and 'dynamic' mod- els.

In the 'static' object-oriented language model (such as C + + ) the major emphasis is on lan- guage extensibility at compile time. New classes are generated and compiled. To accomplish this, data-type checking for conformance to class in- terfaces is resolved at compile time. Executable code is generated in such a way as to maximize efficiency at run-time. What is sacrificed in this process is flexibility. In order to make changes later to the object-oriented application model, the entire application must be re-compiled. This is often a non-trivial process, involving header files, make files, include files, etc. This type of inflexibility stands in the way of rapid prototyping and incremental development. This 'static' model is more like the old COBOL model.

In the 'dynamic' object-oriented language model, such as Smalltalk, type checking is done at the time of execution. The implementations of object instances and classes are loaded dynami- cally as needed. In these languages the burden is placed on the run-time environment to perform all necessary type-checking, look-up and loading

The OOCTG had an advantage when it began its work in defining an object-oriented COBOL language. It could benefit from the experiences of other object-oriented languages - both by emu- lating the good implementations and avoiding the bad ones.

There are some considerations when deciding which COBOL language model the OOCTG ought to emphasize first - 'static' or 'dynamic'. One approach is to use the 'dynamic' model during early development of an object oriented COBOL model, and introduce the 'static' model when the client (COBOL community) thinks the model is right. This is exactly how object-oriented systems should be developed. They are 'loosely' bound during early prototyping and tightly bound when the application becomes stable. It is analo- gous to tightening the bolts on an engine after it is running properly. Incorporating dynamic type checking into the OO COBOL model might take the form of a COBOL clause such as OBJECT REFERENCE IS UNIVERSAL where UNI- VERSAL could represent any data type.

Alternately, the early emphasis could be to deal with the wealth of legacy COBOL code that exists today. This approach suggest a 'static' model during early development of an object oriented COBOL model to deal with the conver- sion of today's COBOL programs into usable (re-usable) objects.

For the official COBOL Standard language, the notion of a two tier object oriented COBOL

The object-oriented COBOL model 303

language could take the form of a Level I and Level II implementation of ANS object oriented COBOL (with level II to come some time after Level I perhaps - perhaps not.). If this happens, it will not be the first time new 'functionality' has been introduced into the COBOL language incre- mentally. R e l a t i v e / I n d e x e d file handling, S O R T / M E R G E , Communications, Inter-pro- gram communication, Segmentation have all been introduced into the COBOL language at multiple levels of ' functionali ty ' / complexity. This ap- proach has, in the past, promoted mostly high- level use of the new 'functionality' and has sped- up delivery of these productivity tools to COBOL programmers.

Those making the claim that COBOL and the object oriented paradigm are incompatible usu- ally are not familiar with the current state of the ANS and ISO Standard COBOL languages - in particular the extensive CALLing features (inter- program communication) in structured ANS COBOL 85, and the 42 new intrinsic functions added to ANS COBOL 85 in 1989; nor are they familiar with the work being done by the Object- Oriented C O B O L Task Group ( O O C T G / X3J4.1).

To be clear, the present COBOL language model ( I S O / A N S COBOL 85 with intrinsic func- tions) is not an object-oriented model. But there are some characteristics of object-oriented lan- guages that are not alien to COBOL program- mers (albeit in a different context.) The A N S / I S O COBOL Standard supports concepts which are inherent to object-oriented models such as: poly- morphism, class/subclass hierarchies, inheri- t ance / re f inement , messages, methods, data en- capsulation, garbage collection, persistence and other concepts 1. Furthermore, some proprietary versions of COBOL available today, such as Mi-

I polymorphism [READ (Sequential/Relative/Indexed)...] class/sub-class hierarchies [Nested programs with Global

(sub-global) data and procedures...] inheritance/refinemant [COPY/REPLACING] messages [CALL... USING] methods [PD Entry-Points] data encapsulation [WORKING-STORAGE...LOCAL-

STORAGE, "CALL... BY CONTENT"] garbage collection [CANCEL] persistence [EXIT PROGRAM defaults]

cro Focus's, extend the ANS standard to include additional object-oriented concepts such as recur- sion and instance data. Although these concepts take different forms in true object-oriented lan- guages than they do in COBOL, the underlying concepts are similar.

Just as COBOL has, for over 30 years, brought readability and maintainability to application de- velopment in legacy programming systems, it brings readability and maintainability to today's object-oriented systems. The 'reusability' savings promised by object-oriented methods, due to its ability to leverage previous work, will be realized when COBOL class libraries are developed and extended and COBOL programmers get experi- enced with these class libraries (both their breadth and their depth). It is in these class libraries that the bulk of the extensions can be found.

Class libraries define new data types as well as the methods that operate on these types. When one examines a pure object-oriented develop- ment environment like Smalltalk with its terse syntax and few 'reserved words', and compares it to the class libraries with which it works, it is clear that most of the learning that is required in object-oriented development environments is with the class libraries. A substantial return-on-invest- ment is realized from reusable objects when de- velopers gain an understanding of the classes they work with and how they can be used (and re-used).

Tools, like the Class Browser, are part of (central to) the object-oriented development envi- ronment and will be critical to the success of object-oriented methods. This reusability benefit, and how quickly the return-on-investment is real- ized are independent really of the language used to create the objects. The graduated start-up curve associated with the introduction of a new tech- nology is a natural consequence of any substantial paradigm shift.

More to the point of maintainability. Lan- guages like C place an emphasis on ease of com- position. Many C programmers foster the notion that elegant programming must be terse. For them, cleL,erness is a higher virtue in application development than clearness. This philosophy however often results in unmaintainable applica- tions or at best more costly application mainte- nance. C doesn't have to be a 'write-only' lan- guage but all too often it becomes one. And C++ is certainly no better. Nearly everyone has

304 D. Clarke, J. Garfunkel

heard stories over the years of early systems, written in Assembler, that had to be replaced by new systems, written in COBOL often, because the old code was just too difficult to understand and too costly to maintain. These stories are being repeated today only the old programs often are written in C rather than Assembler, the old programs are often 5 or 6 years old, rather than 15 or 20 years old, and these old systems are often running on PCs rather than running on mainframes. The lessons to be learned, however are exactly the same. COBOL programmers use their cleverness to maintain the clarity of source programs.

There is one more compelling reason to intro- duce object-oriented concepts to COBOL. It is the very large investment in COBOL legacy sys- tems in the commercial MIS world today and all the personnel involved in its functioning. Object orientation offers the technology to re-vitalize this code in a way that will make it easier to maintain and for it to participate in the dis- tributed application environments of the future. Until this community of computer users is con- vinced of the real added value of object-oriented COBOL, it will not happen on any large scale in the MIS community. "We don't know what the most popular application development language will look like in 15 years from now, but we know it will be called COBOL." 2 The current invest- ment in COBOL applications as well as in COBOL application developers is best leveraged when the migration of legacy systems into object oriented systems uses COBOL as both the source and target languages of that migration. (One might think of this leveraging of COBOL talent as an example of re-use at its highest degree.)

5. Object oriented COBOL strategies

How can COBOL be made object-oriented? This answer lies in two areas: (a) COBOL language extensions, both syntax and

semantics, and; (b) operating system extensions to support highly

interactive run-time services. Looking first at COBOL language extensions,

there are two approaches to extending the

COBOL language to embrace object-oriented concepts. The first is for it to be 'consistent' with the current COBOL language. This approach ex- tends the existing syntax by adding special clauses and phrases to some familiar COBOL statements and adds new semantics when used in new object-oriented contexts. Examples of this can be found in the MOVE and SET statements in the present COBOL language and their extensions in the proposed object-oriented COBOL language. It also allows user defined data types to be used where only intrinsic types are used today. The second approach is for the COBOL language extensions to include new syntax, perhaps more 'alien' to traditional COBOL programmers but more clearly expressive of object-oriented con- cepts. Good arguments have been made for both approaches.

Some of each approach is needed in making the COBOL language extensions appear seamless and natural. "Language design is as much (if not more) of an art as it is a science 3

For the COBOL community, there is a natural tendency to favor the former of these two ap- proaches (consistency) since it introduces the new technology to COBOL programmers in terms that they can relate to. In speaking to many COBOL audiences, we have found over the years, that COBOL people best understand the 'mystical sounding' object-oriented concepts like data en- capsulation, polymorphism, garbage collection, etc., when explained using COBOL examples like Working-Storage, Read, Cancel, etc.

There is always the danger however that by using this approach, one will reinforce the links to the old legacy methods and make the required "paradigm shift" to object-oriented methods even more difficult than it might have been. This issue is of particular importance right now as COBOL is about to introduce a dramatic new model to co-exist with its present model. It may mark, in COBOL's history, the beginning of a migration from the old model to the new one. This migra- tion must include an extended period of co-ex- istence so that legacy COBOL systems can inter- act with object-oriented systems.

Looking next at the object-oriented COBOL run-time extensions, these will likely prove to be

2 This comment was overheard in an informal business con- 3 See J. Sammet and J. Garfunkel, Annals of the History of versation. Computing 7 (4) (Oct. 1985) 342.

The object-oriented COBOL model 305

more difficult to do than the COBOL language extensions. Here are some of the functions that must be supported by the OO COBOL run-time environment: - Recursion - Memory management - Message-to-method biding - lnstantiation - Persistence - Garbage collection (automatic and manual) - Interactive (non-disruptive) error handling - Type checking - Dynamic binding - Support of SELF and SUPER.

These functions must be implemented so that they are both robust and efficient, since they are at the heart of all object-oriented activity. By robust we mean that they must not fail except in extreme and unusual cases, and then only in a "soft" and self-evident way. By efficient we mean e.g. that the path length for sending a message must be minimal.

In summary, to extend the current COBOL language to include a substantive working set of object-oriented features requires: (1) COBOL language extensions - including the

ability to define and catalog sets of classes into libraries, and inherit from these classes when creating new subclasses and objects, and;

(2) COBOL 'an-time extensions to provide the underlying support implied by a highly inter- active, event-driven object oriented system.

6 . O b j e c t o r i e n t e d C O B O L s t a n d a r d s

The development of standard object-oriented COBOL extensions is still in progress as this paper is being written. As described earlier, this work is being done by the CODASYL Object- Oriented COBOL Task Group (OOCTG). This group had its first meeting in January 1990. In December 1992, it convened under the name of X3J4.1. The procedures for developing object-ori- ented COBOL are now carried out as a subgroup of the ANSI X3J4 COBOL Committee. The tar- get date for the completion of the first draft of

the technical report from the Object-Oriented COBOL Task Group is March 1993. This date is significant because OOCTG is working closely with its parent committee, ANSI X3J4, to syn- chronize the development of object-oriented COBOL with the next full revision of the ANS and ISO COBOL Standard. Any significant delay in finalizing the "object-oriented" proposal for COBOL will mean possibly missing the deadlines necessary to include object-oriented COBOL in the next COBOL standard (COBOL 97 perhaps?).

7 . I n c o n c l u s i o n

As stated at the outset of this paper, the significance of a language reference model is great. The model serves as a guiding light under- lying all syntax and semantics issues related to the newly emerging language. This object-ori- ented COBOL model will be continuously scruti- nized by the 1SO and ANSI COBOL committees (and others). To assure the relevance of this model to the application development commu- nity, the Standards community must act quickly enough to produce the needed COBOL language extensions before it becomes obsolete.

Dan Clarke has a Master of Science degree in Computer Science and a Bachelor of Arts degree in Mathe- matics from San Jose State Univer- sity, San Jose, California. He ac- cepted the assignment to be the evan- gelist for object-oriented COBOL at Micro Focus after concluding a 31- year career at IBM. During the last year at IBM, Mr. Clarke was ap- pointed as the first chairman of the CODASYL Object Oriented COBOL Task Group, a task group charged

with producing a specification for object-oriented COBOL.

Jerome Garfunkel, a Senior Staff Consultant at Micro Focus, Inc., and president of JGA Inc., views his ma- jor role as an evangelist for COBOL. He has written many articles and sev- eral books including, The COBOL 85 Example Book, COBOL 80 Guide, and the COBOl, Workshop Book. Mr. Garfunkel is extremely active in the s tandards community and has partici- pated on the American COBOL Commit tee (X3J4), the international C O B O L Committee, ISO T C 9 7 /

S C 2 2 / W G 4 , the Object Oriented COBOL Commit tee (X3J4.1), the CODASYL COBOL Committee, and others.