Why Has COBOL Endured?
Given the rarity of anything in the IT industry surviving for over 40 years, it is appropriate to ask why has COBOL endured for so long. An underlying mission of COBOL language development during its entire lifespan has been to keep COBOL’s syntax and new features relevant to modern application development methodologies and to do so with utmost respect for the large number of COBOL applications still running on computers around the world. The ISO COBOL o2002 language is an evolutionary product. Today’s COBOL is the result of much determined work by the various COBOL committees that have contributed to its evolution, among them ISO, INCITS, ANSI, CODASYL, ECMA, SMTG and the national COBOL committees represented by individual countries such as The Netherlands, Canada, France, Japan, United Kingdom, Germany, United States, et al.

Change Is Natural
One thing is certain in the commercial IT world (and in life in general): Change is natural. Business computer systems are digital models of an enterprise and all of its operations. As an enterprise evolves so must its computer business systems (models) evolve. When designing any business application, we must anticipate changes, both corrective and perfective, in those applications. We must identify those parts of the system that will most likely need maintenance in the course of the system’s lifetime.

When speaking to new systems designers, I often use an analogy of design techniques employed by the systems engineers who build automobiles. It is absurd to think of a new line of cars being built without anticipating one of the basic maintenance chores required of all fuel-driven automobiles: refueling. Imagine for a moment that the car designers (system designers) placed the fuel cap underneath the car, hidden by the transmission. Would we tolerate dismantling our cars’ transmissions each time we needed to refuel our cars? Of course not. This refueling (maintenance) chore was made easier by isolating those parts of the car that we need to reach to do this maintenance.

This is very similar to the design criteria that computer system designers must use. Thankfully, the original COBOL language designers knew this. When the COBOL language was first created, the CODASYL committee envisioned that the IT industry was fast changing and that most business systems would likely need to be modified during their lifetime. New hardware and new software development techniques were likely to follow. COBOL applications needed a way to adapt to ever-changing environments without causing chaos inside the enterprise systems development community. The solution was to make COBOL as adaptable as possible and to incorporate, inside the source program itself, whatever environmental documentation was required. This of course resulted in the Environment Division, one of the four original Divisions still in the COBOL language. By isolating “all” the environmental dependencies of a COBOL application in one place, it was much easier to transport a COBOL application from one computer brand to another, from one operating system to another, from one database to another.

Today we take this concept for granted. Why should Microsoft Word behave differently on a Macintosh than on a Windows machine? In the o1950s, however, this was a new concept just gaining popularity. Admiral Grace Hopper’s contribution to the “birth” of COBOL is well documented. She was a member of the original CODASYL executive committee. A far greater contribution perhaps was her pioneering effort to develop and promote the concept of third-generation programming languages such as COBOL, Fortran, Algol, and so on. This allowed programmers to use a common, high-level set of instructions (higher than assembler languages). This common high-level code was then translated (compiled) into the machine language of the particular hardware on which it would eventually execute. Further, to the point of adaptability, COBOL incorporated the CALL statement early in its development, as well as a COPY library source code facility. Later, the INVOKE statement was added as part of the object-oriented COBOL module.

These and other features in COBOL acknowledged the changing nature of computer business systems and anticipated the need for adaptability in COBOL language syntax. Rather than incorporate new COBOL syntax and data formats (borrowed from other programming languages) to map into every known programming language and database, COBOL simply chose to create flexible methods to interact with applications written in other languages and to pass data between modules effectively. You might say that the COBOL integrated development environment (IDE) is one of the earliest “open source” environments.

Another reason for COBOL’s endurance lies in the large number of auxiliary tools available in a COBOL IDE: full-featured application development suites, code generators, software libraries, debuggers, conversion tools, compiler “add-ins,” and so on. The sheer momentum over 43 years from so many programmers producing so many COBOL applications resulted in cottage industries of supplemental software to aid in the task of COBOL application development. No other programming language has such a robust IDE.

The Y2K “Noncrisis”
I have saved for last the most important reason perhaps for COBOL’s continuing excellence: the superior management of COBOL systems.

Much of the criticism of the COBOL language within the application development community is aimed at its “wordiness.” It is true that COBOL is verbose. COBOL applications often require more lines of source code to be written than are necessary in applications written in other languages. This was by design. When the original members of the CODASYL COBOL committee set out to define the syntax for this COmmon Business Oriented Language (COBOL), they intentionally included many clauses, phrases, “noise words” and so on, not to make the job of the development programmer harder, but rather to make the job of the maintenance programmer easier and the results more accurate. COBOL instructions such as “ADD this-weeks-salary TO previous-year-to-date-salary GIVING new-year-to-date-salary” are indeed more verbose than, say, “LET z = x + y.” But no one can argue that the meaning/intent of the business logic coded in the former example is much clearer than in the latter example. This is by design. In application development, clarity, not cleverness, is a virtue.

COBOL contains syntax for coding its own shortcuts and clever programming techniques if a programmer is so inclined. The COBOL statement COMPUTE z = x + y is perfectly valid, but it is antithetical to good COBOL programming practices and is discouraged for all the reasons mentioned previously. Is this really important? You need only reflect on the Y2K “noncrisis” at the turn of the new millennium to determine how important this is. Many people blamed COBOL for the Y2K crisis, pointing to the huge number of legacy (read again: COBOL) programs still running on computers in o1999 as we prepared for potential disasters when switching over to o2000. This argument is fallacious. As any good application developer knows, the problems created by storing dates using the last two digits of the year (e.g., 85) instead of four digits (e.g., 1985) resulted from shortsighted system design, not from a poor choice of the programming language used. All applications (business applications and others), whether written in COBOL, Fortran, C/C++, Visual Basic, etc., had to be checked and modified to deal with the change from o1999 to o2000.

It’s my firm belief that the Y2K crisis, anticipated by so many, turned out to be a Y2K “noncrisis” specifically because most of those legacy systems were in fact developed with COBOL. Because the COBOL source code is written with so much more clarity than source code written in other languages, the huge task of reviewing all of that legacy source code and making changes when/where necessary was made much easier because of COBOL than nearly everyone had expected. True, the Y2K crisis was a tremendous problem for the IT industry. But the efforts involved to fix the problem were made much easier, not harder, because of COBOL, not in spite of COBOL. In a way, COBOL turned out to be “too good.” The clarity associated with COBOL source code made those earlier COBOL applications much more maintainable than anyone had predicted. After all, why discard an application that’s performing most of its business functions properly simply because that application needs updating, when modifying the original source code is easier, less expensive, and adds years of productive life to business systems? As a result, the lifespan of legacy systems was stretched much further than people (systems designers) had expected. Is this bad? No, I think not; it’s shortsighted perhaps, but it’s not bad.

What we learned from the Y2K crisis was that COBOL provides “health insurance” to corporate assets. That is, it’s the best way for an enterprise to protect its investment in its IT assets. The same can’t be said for applications written in other languages. In many cases, applications written in lower level languages (assembler) or other third-generation languages (C, Pascal, and so on) were simply not worth deciphering to fix Y2K (and other) problems. Instead, many were discarded and replaced by newly written programs (hopefully in COBOL, but probably not).

COBOL and Visual Basic on .NET: A Guide for the Reformed Mainframe Programmer
In his book, Mr. Richardson tells the reader, “The world has changed. The .NET Framework and VS .NET is part of that change . . . and so are you.” We in the application development community must deal with ever-changing technologies. We’re constantly faced with new challenges to keep our programming skills current. These challenges confront us whether we’re integrating legacy systems with modern (integrated Web) technologies or whether we’re developing brand-new applications on PCs and/or mainframes incorporating Web services. Can we continue to keep our legacy systems running our enterprises in the midst of these emerging technologies? Or must we abandon those systems and start from scratch to take advantage of these new technologies? Can we “have our cake and eat it too”?

Yes, we can develop modern applications using COBOL, taking advantage of its superior maintainability while incorporating Web-based services into these systems as described in Mr. Richardson’s book. COBOL is alive and well in the twenty-first century and its future is bright. A professor friend of mine from Purdue University, when discussing COBOL’s future, likes to tell his students, “You better wear your sunglasses.” There’s much life still left in our legacy systems due to the myriad of integration tools available to us. And thanks to COBOL and Visual Basic on .NET: A Guide for the Reformed Mainframe Programmer, we can understand this new technology from the mainframe programmer’s perspective and learn to apply it in our real lives.

Jerome Garfunkel
Woodstock, New York
February, o2003
www.JeromeGarfunkel.com

About the Author
Jerome Benjamin Garfunkel is an international consultant and specialist in learning systems design. He spent much of his professional career in the development of programming languages and international computer standards. He served as a senior technical advisor to the U.S. Department of Commerce. In addition, he sat on several American and international IT industry committees;. Among the committees on which Jerome Garfunkel sat are the ANSI Standards Planning and Requirements Committee, the ANSI Programming Language Study Group, the International Committee on Programming Language Guidelines, the American COBOL Committee, the International COBOL Committee, the CODASYL COBOL Committee and the Object-Oriented COBOL Committee.

Jerome Garfunkel is a lecturer, an author, a consultant, an educator, an actor, a calligrapher, and a passionate motorcycle rider. As an educator and technologist, he lectures about leading-edge technologies such as the integration of legacy systems with web-based services. Dr. Garfunkel was awarded the degree of Doctorate, Honoris Causa in Technology from De Montfort University in Leicester, England, for his lifetime contributions to the software engineering community. His collection of technical papers, memoranda, and notes is housed in the Charles Babbage Institute in Minnesota for historical research. Included is the large body of his writings appearing in books, IT journals, magazines, and newspapers around the world.

1 “COBOL: Still Relevant After All These Years, is adapted from the Foreword, written by this author, of Christopher Richardson’s book, COBOL and Visual Basic on .NET: A Guide for the Reformed Mainframe Programmer, published by Apress Press.

2 The use of five digits years (e.g., o2002) throughout this foreword is done so as not to be shortsighted in the year 9999 prior to the turn of the eleventh millennium. Sure, you might say, “Isn’t it a bit early to be worrying about the Y10K problem?” But as we now know in retrospect, this is the same kind of thinking over the past three to four decades that led us to the Y2K crisis. Well, maybe I’m being a bit too cautious. If most enterprise applications are developed in COBOL for the next 8,000 years, I suppose the Y10K crisis, as the Y2K crisis and both the Y1K and Y0K crises before it, will turn out to be a “noncrisis.” (Wink!)