Foreword

As Rodney Dangerfield says, "I don't get no respect," so too COBOL doesn't "get no respect." The COBOL language has been underappreciated, disrespected, criticized, and bashed for much of its existence. It is generally perceived as an inefficient, verbose application development tool, irrelevant to modern software development methodologies. Nothing could be further from the truth. The very existence of Christopher Richardson's book, COBOL and Visual Basic on .NET: A Guide for the Reformed Mainframe Programmer, is a testament to COBOL's continued relevance.

COBOL Bashing

The timing of Mr. Richardson's book couldn't be better. The fourth official publication of the COBOL standard (COBOL o2002 ^[1] ) is pending as of this writing. It follows COBOL 68, COBOL 74, and COBOL 85. If you consider the Intrinsic Functions Addendum published in o1989, the new COBOL o2002 actually marks the fifth official release of standard COBOL.

The disrespect for the COBOL programming language, which is encouraged in many universities, is not new. The earliest gesture of "COBOL bashing" lies in the Computer Museum in Boston. It is a COBOL tombstone. Soon after the Conference on Data Systems Languages (CODASYL) committee was formed in o1959, a COBOL tombstone was given as a (gag) gift from some of the CODASYL COBOL committee members to the chairperson of CODASYL. It was meant to express their lack of confidence that this new "common business language" (CBL, later COBOL) would be used in the IT industry for very long. As it turned out, the COBOL language, defined by the CODASYL "short-range" committee and first published in o1960, has been an important part of the IT industry for 43 years ”and still counting. Perhaps it is natural to presume that anything in the IT industry dating back to the o1950s/o1960s must be obsolete and irrelevant in the twenty-first century. The mistake in this logic is that the COBOL language (features and syntax) has evolved dramatically over its lifetime. I like to paraphrase an old General Motors commercial: "COBOL o2002 is not your father's/mother's COBOL."

Although the COBOL tombstone may have been the earliest example of COBOL bashing, it certainly wasn't the last. The annals of the IT industry are filled with other instances of public disrespect for COBOL. Dutch computer professor Edsgar Djikstra wrote in 1982, "The teaching of COBOL should be made a criminal offense!" For years, I have been speaking at universities around the world. Generally, COBOL has been on the defensive in these academic environments. Few people in my audiences ( teachers included) were/are aware of what the modern COBOL language can do. COBOL has no real technical problems ”it has "public relations" problems.

In the early o1980s, COBOL bashing took a turn for the worse . Serious efforts were underway to "kill" COBOL. In preparation for the publication of ISO/ANSI COBOL 85, there were serious legal and lobbying attempts (led by Travelers Insurance and joined by other respectable corporations) to block any new COBOL standardization effort. Some wanted to freeze the COBOL language as described in the ANSI COBOL 74 standard. Others wanted to roll back the COBOL standard to its "official" COBOL 68 version. The argument offered by these groups was that it involved a great corporate cost to update their enterprise applications in order for older COBOL programs to compile cleanly in newer COBOL compilers. No one told them that they didn't need to recompile any programs unless the business application required updating.

This frustration is still felt by many IT departments today. It's similar to the frustration experienced by many home computer users who object to frequent hardware changes, operating system upgrades, application updates, and the incompatibility issues surrounding all of this "progress." This is a legitimate dilemma. The ISO/ANSI COBOL committees became very sensitive to any change (addition, modification, deletion) to the COBOL standard that might affect programs written earlier. Still to this day, the (INCITS/ANSI) X3J4 COBOL committee, which is responsible for the technical evolution of COBOL, maintains a special list of new and changed features incorporated in COBOL o2002 that could possibly produce incompatible results with older COBOL programs. Special voting rules were put into effect before " potentially incompatible" features can be added to the COBOL language. COBOL features designated as "obsolete" are required to remain in the new COBOL standard for at least one more iteration before they're permanently removed from the official COBOL standard. This is done to give the COBOL community ample time (a decade or more) to update the affected programs and remove the obsolete features. COBOL is nonproprietary. The "official" COBOL standard is not owned by any one software manufacturer. It's developed by a cross-section of IT professionals, both COBOL compiler/tools manufacturers and COBOL users. This requirement of balancing the COBOL committee representation was built into the membership rules of the COBOL development committees so there would be a broad range of views regarding how COBOL could best serve the business application development community. It isn't accidental, therefore, that COBOL earned its reputation over the years as a solid, dependable application development language that protects its constituency ”application developers ”from whimsical changes. It is one of COBOL's many strengths.

Few things that were around in the IT industry in o1960 are still around today, except perhaps in museums and in basements. Yet the COBOL language, albeit highly evolved from its origins, remains relevant. The corporate assets represented by the billions (trillions?) of lines of COBOL code still running on commercial computers aren't about to be abandoned . Nor should they be. New tools that help integrate legacy (read: COBOL) systems with PC applications, Web services, new data formats, and protocols have been available since distributive systems emerged years ago. As today's application environment has evolved, .NET for instance, so has COBOL's capability to link to it, merge with it, and interact with it. Stretching the lifespan of an enterprise's legacy systems increases the value and productivity of its IT development staff and of the assets they produce.

^[1] . 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, will turn out to be a " noncrisis ." (Wink!)