(It's time to take the gloves off)
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,
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.
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
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.
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
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
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.
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: