Modern COBOL 

(It's time to take the gloves off)

by Jerome Garfunkel

A COBOL Tombstone lies in theComputer Museum in Boston Massachusetts. It is probably the earliest gesture of "COBOL bashing" that we know about. It certainly wasn't the last. "The teaching of COBOL should be made a criminal offense," so said Dutch Professor Edgar Djikstra in 1982. These comments predicting COBOL's death have continued for most of its three-and-a-half decades. Yet COBOL has remained the most successful and resourceful programming language ever invented. Certainly there is a reason.

It's time to take the gloves off. The modern version of COBOL is dramatically different than the COBOL language used in the 60's and 70's. Those who argue that COBOL is dead or dying often do not know the modern COBOL 2000 language with structured programming, intrinsic run-time functions and Object Orientation. Today's (and tomorrow's) COBOL language is not your father's COBOL. A professor friend of mine likes to tell his students "...you better wear your sunglasses, when you look at the future of the COBOL language."

Why has COBOL endured?

The COBOL language was conceived in 1959 by the CODASYL COBOL Committee. The first COBOL document was published in 1960. No other programming language has enjoyed the popularity that COBOL has for so long. One must ask why. COBOL was created as a COmmon Business Oriented Language; but the popularity of COBOL grew not so much because of its great "business" statements but because of the robust development and superior maintainability associated with COBOL source programs. Prior to COBOL, most computer programmers were engineers or computer scientists who approached application programming from a very different perspective than COBOL programmers do. COBOL introduced application experts (non-engineers and non-computer scientists) to computer programming. An entire new pool of programming talent was suddenly available. It is generally agreed that the explosion of computer applications which began in the 60's (and has never slowed down) began with the introduction of the COBOL language. COBOL applications are simply easier to maintain than those written in alternative application languages like Assembler, C, Algol, Lisp, APL, etc.

Today's COBOL: Change is natural

The modern COBOL language has changed with the times. One of the lessons we learned in the 60's and 70's is that all enterprise applications naturally change. There are a myriad of reasons for system changes - the least of which is programming errors. Most often systems need maintenance when governments change tax rules, corporate management changes policies; reporting methods and procedures are constantly being reviewed to improve intra-corporate communication. Systems naturally change within an organization over time thus most changes are "perfective" changes - expanding "functionality" rather than correcting errors. Of those application changes that are corrective, many of these occur because of mis-communication between the business analyst/expert and the computer Analyst/Designer.

Not only do enterprise applications constantly evolve but so does the technology supporting our computer applications. The programming language used to develop our applications must be adaptable not only to changes within the system - policies, procedures, etc. - but it must be adaptable to new technologies as well (hardware and software) - multi processors, client server architecture, object oriented methods, etc. In other words it must be a viable tool to use in solving today's problems given today's (and tomorrow's) technology.

Client Server

What is the environment affecting enterprise applications being built today. It is a world of distributive applications. No longer do mainframes stand alone as they did 25 years ago nor do pc's stand alone as they did a decade ago. PC's are often connected into LANs served by a common database of programs and data. In larger installations these LAN's clustered around an organization are linked into a larger network, often with mainframe computers serving as a common data resource bank and providing overall operations management (among other things). The pc's and terminals distributed around an organization are quite varied. It is not uncommon to find LAN's supporting many platforms including DOS, OS/2, Windows, UNIX, and Macintosh. This then is the reality of the current environment in which COBOL must work . It is fair to ask if COBOL fits into this picture.

The answer is that COBOL shines in this environment. The "CO" in COBOL stands for "COmmon." It was envisioned by the forefathers of COBOL that this language should be as independent of its operating environment as possible. This has never been more important than it is today. Today's COBOL is ideal for this. Not only does COBOL isolate all environment related application issues in one place, the ENVIRONMENT DIVISION, making it easier to port COBOL programs from one platform to another, today's COBOL compilers take this application independence to a much greater degree. The term "Open Systems" at one time was a euphemism for UNIX architecture. Today, "open systems" aptly describes the COBOL language along with other tools which allow a single program to run simultaneously on OS/2, DOS, UNIX, Windows (3.n, NT and 95) , Macintosh platforms, often without changing even a single line of source code. This is true flexibility. This is achieved by isolating the application logic (often very stable) from the environment-specific syntax, (often changeable). These environment-specific features include such things as databases, screen management (both screen painting and data manipulation), operating systems (APIs), etc.

Many of today's most impressive applications being built on pc's are interactive or event-driven systems. They exploit the "personal" characteristic of "personal computers." Object oriented techniques are ideal for these event-driven applications. Interactive applications are most useful when they are flexible and dynamic (rather than tightly bound and static). Object oriented methods provide this flexibility. The new object oriented COBOL language provides a good combination of flexibility for modeling and rapid application development.

COBOL and 4 GL's

It is not my intent to tear down COBOL alternatives. The use of 4 GL's to develop applications is often beneficial. Few can argue that 4GL-developed applications are created in less time than 3GL-developed applications. But it is important to note the price one pays for the benefits associated with 4GL rapid application development. Often, 4 GL's turn out to be inadequately "robust" for large applications. COBOL applications are simply more scaleable (upward and downward) than are 4GL-developed applications. In today's Client Server world, this is critical. That is they often cannot handle the throughput being asked of it or else the repertoire of solution statements is too limited. Due to the proprietary nature of 4 GLs, an enterprise may be reluctant to develop its critical applications using a language supported by only one firm or even a consortium of private firms. The talent pool available for 4-GL application development and maintenance is often limited. There simply are more COBOL programmers in the world than there are "RAPID-DEV" programmers or any other 4GL language. Furthermore, COBOL installations have available to them a myriad of workstation tools, performance analyzers, re-engineering packages etc. No other language, 4GL, 3GL or otherwise, has such a wealth of add on-tools available for support in development, debugging, testing, analysis performance , maintenance, etc. as does COBOL. The maintenance of some of the visual 4GL code generators is an important concern too. Will the business application be maintained in its visual (graphic) form or will it be maintained in its generated code form.? This must be considered ahead of time

COBOL and C

Building comprehensive enterprise applications in C, seems to ignore the many lessons we learned over the past 3 decades about application maintenance. C is perceived to be a more efficient language than COBOL. The truth is that today's compiler technologies are making these performance differences more negligible every day.

Many application developers, can remember the problems we had trying to maintain our enterprise applications in Assembler language. COBOL was introduced in 1960 to solve the problem of "program escoteria" - an application developed so cleverly that only a few can understand its organization. In application development cleverness is no virtue; clearness is. C is sometimes referred to as a "write-Only" language because of the clever programming constructs employed; COBOL on the other hand, brings clarity to applications; COBOL critics often confuse application clarity with language verbosity. COBOL programs were never intended to be terse; COBOL programs are meant to be clear above all else. What we discovered years ago when choosing between Assembler and COBOL for application development is that for complex applications, it was simply less costly and more effective over the life span of a system to maintain it in COBOL. Many of the applications that were developed on PCs using C over the past 5 to 8 years are about to hit the maintenance cycle of their life span. They are likely to need some "major overhauling." I expect that as these (C-developed) applications mature, they will generally be less maintainable and less durable than other (COBOL developed) systems.

Many of the lessons we learned on the mainframes over 25 years ago are still perfectly applicable today. COBOL, was the best solution then; COBOL in its modern form is the best solution today.

ANSI ISO CODASYL

It is not an accident that COBOL has remained the dominant language for application developers for over three decades. It is because COBOL has stayed technologically relevant all those years and continues today. The American and International Committee process in place assures the on-going development of COBOL. Meeting at least 7 times a year the (ANSI) X3J4 COBOL Technical Committee which develops the (American) ANS COBOL Standard language and (ISO) WG4 COBOL Working Group which develops the (International) ISO COBOL Standard language assure that the direction of the COBOL language stays relevant to modern software technologies - i.e. structured programming in the 70's and object oriented programming in the 1990's. Until December 1992, a third committee, the CODASYL COBOL Committee, participated as well in the development of COBOL. In fact it was the CODASYL COBOL Committee that originated COBOL in 1959 ; they met as a continuous body for 33 years. In 1992 a merger of its members into the X3J4 technical committee occurred and the CODAYSL COBOL committee voted itself "out-of-business." These COBOL technical committees stay linked to other international and American Standards bodies to assure the smooth integration of COBOL programs with other application components, i.e. standard SQL databases, graphics, forms interface, etc.. aa

Modern COBOL explored

In the mid seventies, when structured methods became popular, the CODASYL COBOL Committee held a symposium and invited suggestions from language "gurus" around the world. The aim was to incorporate structured programming techniques into COBOL. Much of the present COBOL language relating to structured theories have their roots in that symposium. Some of these structured programming features incorporated into today's COBOL include the following:

Scope Terminators such as END-READ and END-ADD (and 17 others) delimit the scope of all conditional COBOL statements. These Scope terminators permit the nesting of conditional logic in COBOL.

Nested Programs permit the subdivision of COBOL programs into independent subprograms. These nested subprograms may be completely 'localized' or they may share GLOBAL data and GLOBAL USE procedures with their 'parent' program.

The EVALUATE verb allows multi-join and multi-branch "case" statements. COBOL selection statements in the past were limited to the IF statement and the GO TO....DEPENDING ON statement. The EVALUATE statement provides a new and much more versatile "case" verb often resembling a "truth table" (or "decision table") set into programming syntax.

In-line PERFORM statements allows the coding of procedures in-line with other code rather than being artificially written out-of-line, often on another page, making cross referencing more difficult for the programmer.

"Do-While" and "Do-Until" constructs of the PERFORM verb are allowed with the addition of WITH TEST AFTER and WITH TEST BEFORE clauses. This allows programmers more control over when procedure controlling conditions will be checked.

Other important features incorporated into ANS COBOL 85 include:

The INITIALIZE verb provides a means of resetting (initializing) all of the subordinate data in a group data item. These subordinate date items can be INITIALIZEd to spaces or zeros (or any other value) depending on their type (i.e. numeric, non-numeric).

EXTERNAL files and records permits some data to be "owned" by the run unit of an application rather than any one particular program. It is a very efficient means of sharing files and records among various programs in a run unit.

INITIAL programs (when specified) assure that programs will be loaded in their initial state every time they are called. Otherwise, programs may execute in their last state (i.e. all data values in tact and ALTERed GO TOs (God forbid) still ALTERed.

BY REFERENCE and BY CONTENT clauses of the CALL statement allow programmer control over the passing of parameters from one program to another. That is the data can be passed with or without data protection for the original values.

In addition to the significant new features described above, COBOL 85 introduced a variety of other features while tightening up many ambiguous rules. This will ultimately result in more portable COBOL programs.

The COBOL Controversy

COBOL 85 emerged out of much controversy. Much of the debate centered around the competing importance of COBOL portability vs. program compatibility. One of the consequences of the controversy surrounding the "birth" of COBOL 85 was the extraordinary delay that resulted (an additional 5 years). Many felt that COBOL improvements could not survive another long delay and that the current procedures to produce subsequent revisions of COBOL were too slow and not responsive to the COBOL community's needs. COBOL needed to be then (and always needs to be) relevant to current application development and programming/design methodologies. In 1984, at the now famous meeting of the International COBOL Committee in Vienna, Austria, the International COBOL Committee adopted new rules (later endorsed by the American COBOL Committee) to speed up the process of adding new "functionality" to COBOL. They created an Addendum process (Amendments), by which new features could be added to the COBOL language every few years without causing incompatibilities with older COBOL programs. The first of these Addenda became an official ANSI/ISO Standard in September, 1989. It is the Intrinsic Functions Addendum, which adds forty-two new intrinsic (built in) functions to COBOL, and increases programming productivity significantly.

COBOL 89

Some of the new intrinsic functions now included in COBOL are:

- ANNUITY annuity paid for specific number of periods at specific interest rates or mortgage payments

- CHAR character in specific collating sequence position

- CURRENT-DATE current date and time

- DATE-OF-INTEGER converts integer date into a standard calendar date (yyyy mm dd)

- DAY-OF-INTEGER converts integer date into a standard Julian date (yyyy ddd)

- INTEGER-OF-DATE converts standard calendar date (yyyy mm dd) into Integer date

- INTEGER-OF-DAY converts standard Julian date (yyyy ddd) into Integer date

- LOWER (-UPPER) CASE converts string to all lower (upper) case

- MAX (MIN) the maximum (or minimum) value from a list of arguments

- NUMVAL(-C,-F) numeric value of a string (with commas and floating point notation)

- ORD-MAX (-MIN) the ordinal position of the maximum (minimum) argument in a list

- REM the fractional remainder portion of a quotient n1/n2

- REVERSE the reverse order of characters in a string

- SUM the total value of the arguments in a list

- WHEN-COMPILED date and time program was compiled

- all popular mathematical and trigonometric functions including:

SQRT, FACTORIAL, RANDOM, SIN, COS, TAN, ACOS, ATAN, ASIN

et al...

The intrinsic functions in COBOL allow the programmer to invoke a single run-time library routine for what may have been many lines of manually coded instructions. Among the many benefits that the new intrinsic functions provide will be assistance with the "year-2000" problem, the end-of-the-millennium date conflict that is expected to appear in many applications at "extreme midnight," one second after 11:59:59pm December 31, 1999.ß

ANS and ISO COBOL 98

COBOL does not stand still. The ANSI COBOL 85 language was officially released in September, 1985. The ink hardly had a chance to dry, when the X3J4 COBOL Technical Committee went to work identifying enhancements for the next Addendum beyond Intrinsic Functions. Work also began on identifying new features to be added to the next full COBOL revision (expected to be COBOL 98). Other very high priority addenda were identified for COBOL including MOCS - a standard for defining multi-octet character sets. This is of particular concern in those countries using COBOL where the native character set contains more than 256 characters - the number of possible combinations that can be represented by 1 byte with 8 bits. The features of this addendum are likely to be included in the next version of COBOL (COBOL 98?). oe

Object Oriented COBOL

In November, 1989, the CODASYL COBOL committee held a symposium in Scottsdale, Arizona to discuss adding object orientation to the COBOL language. Out of that symposium came a commitment and strategy to accomplish this goal. The Object Oriented COBOL Task Group (OOCTG, later known as X3J4.1) was established to oversee this task. Although much of object theory is based on sound structured methods, extensions to the ANS COBOL 85 Standard are necessary to accommodate all object oriented programming (OOP) concepts.

This new objected oriented COBOL syntax will be included in the next COBOL 98 language. Furthermore, the Object Oriented COBOL committee has liaisons linked to the Object Management Group, a consortium that is developing an industry standard Object Management Architecture (CORBA = Common Object Request Broker Architecture). One of the goals of this group is to define a common set of protocols so that objects written in any language can communicate (send/receive messages) with objects written in another language.

The impact of object oriented technology on COBOL application development is expected to be tremendous. The new hardware/software combinations of today's (and tomorrow's) systems suggest a giant step is about to be taken in interactive application development. Much of this excitement is due to the popularity of object oriented technology. But object oriented systems are not going to replace all of the "legacy" applications we use today or will write in the future. While object oriented techniques are quite suitable for interactive systems, 3GL (and 4GL) procedural languages are still quite adequate and indeed preferable at times for data processing applications. These data processing applications are much more stable (static) than the new interactive applications and thus they do not benefit so much from the advantages (run-time flexibility) of object oriented systems. Not all new systems will be interactive. There will still be many "data processing" applications written in years to come.

The application development community won't have to wait until 1998 to begin using COBOL to develop Object Oriented applications. We are seeing Object Oriented COBOL compilers "on the streets" well before it becomes an official American (and International) Standard. By participating in the ongoing discussions within the Object Oriented COBOL Committee, COBOL suppliers can stay "close" to the official Object Oriented COBOL Standard when it is finally released. In fact, candidates for added COBOL features in subsequent standards are often chosen from vendor specific COBOL compiler extensions. There is much precedents for this.

ANS COBOL 98

Besides the incorporation of intrinsic functions, MOCS and object orientation into the next ANS COBOL 98 language, many other new features will be added to COBOL 98. Some of the items listed here have been marked "4GL COBOL," to indicate the high level nature of that feature. Some of the major improvements that are likely to be included in the next ANS (ISO) COBOL 98 Standard are:

- Boolean/Bit functions
- New PICTURE 1 data description to be added
- Boolean algebraic operations AND, OR, XOR, NOT
- Object orientation
- Supports Data encapsulation, inheritance (single now, multiple soon), dynamic addressing, polymorphism, persistence
- INVOKE statement for sending messages
- OO Feature defined by the Object Oriented COBOL Task Group (later X3J4.1)
- EXIT PERFORM (PARAGRAPH, SECTION)
- Exit the current "cycle" in an in-line PERFORM statement - go directly to the start of the next "cycle"
- Exit the PERFORM statement entirely as if the "UNTIL" condition has been satisfied
- Exit the current paragraph
- Exit the current section
- MOCS - Multi Octet Character Sets
- Extends the current 1 byte limitation of 256 unique characters to 65536 characters. This will aide COBOL applications in countries whose native character set exceeds 256 characters.
- INITIALIZE
- Restores working storage data items to their initial values.
- Initializes FILLER areas with values as well
- Common Exception Handling
- Local, Global exception handling
- TURN directive
- Declaratives enhancement
- Intrinsic functions for exception information
- De-editing facility extended to arithmetic operations
- Allows arithmetic with numeric-edited items as well as pure numeric items. It would allow a statement like ADD pic-zz TO pic-zzz99. mm
- Enhanced Report Writer facility (4GL COBOL)
- The Report Writer module is returning to COBOL. (Actually, it never went away.) The new Report Writer of COBOL 97 will be greatly enhanced from earlier standard versions. §
- Table enhancements
- Internal tables can be manipulated, including the ability to SORT table elements.
- Dynamic tables may be extended at run-time
- New COBOL Arithmetic
- Standard Floating Point data item defines
- Portable arithmetic defined (after 37 years)
- Free form source programs
- Source program lines are unlimited (not restricted to 80 "columns")
- On-line comments are permitted with the >* separator
- Internationalization of COBOL
- alternate international spellings
- Currency variations
- User Defined functions (4GL COBOL)
- Allows creation of customized functions and run-time execution
- Year 2000 support
- ACCEPT ... FROM DATE/DAY (YYYY...)
- Year 2000 intrinsic functions including: DATE-TO-YYYMMDD, DAY-TO-YYYYDDD, YEAR-TO-YYYY
- New intrinsic functions
- Year 2000 intrinsic functions including:
> DATE-TO-YYYMMDD, DAY-TO-YYYYDDD, YEAR-TO-YYYY
- Standard intrinsic functions for
> ABS, E, EXP, EXP10, FRACTION-PART, PI, SIGN, HIGHEST-ALGEBRAIC, LOWEST-ALGEBRAIC, others
- VALIDATE (4GL COBOL)
- non-procedural data validation
- "Reverse Report Writer"
- Developed by "Report Writer Team"
- Record locking and file sharing
- Allows programmers to control file accesses by multiple clients
- This new feature was taken from a Micro Focus COBOL vendor extension
- and others...

Appendices 1

© 1996, Jerome Garfunkel & Associates