Cobol programmers, face it: Your favorite code is outdated and losing support

IN THE NEARLY five years I have been writing for InfoWorld, never has an article of mine generated such incredible response as "Application transformation." The article presented an overview of two tools, PERCobol Enterprise 2.5 from LegacyJ and Net Express 3.1 from Merant, that assist in migrating Cobol directly to the Web using Java encapsulation, allowing for fast deployment without recoding.

The mail is still pouring in almost five months later.

Most of you ardent Cobolites were quick to take issue with several points raised in the article pertaining to Cobol's capabilities. Unfortunately, most were taken without appreciation for the focus or context in which they were made. Several of you have even been rewriting passages to fit the context of your case. Please stop this.

Cobol (COmmon Business Oriented Language) was one of the first high-level programming languages, introduced in 1959 by the Conference on Data Systems Languages. Cobol helped to automate the business world with its proficiency at defining and manipulating complex data structures. Today, Cobol remains a stable and vital part of most large enterprise infrastructures.

In the course of the decade following its release, different flavors of Cobol sprouted up, and to smooth issues of incompatibility, the American National Standards Institute (ANSI) published a standard specification for the language (ca. 1968).

Since its introduction 41 years ago, Cobol has undergone three major revisions. Although the updates in 1974 and 1985 were essentially published for the introduction of new features, it was not until the final revision, Cobol 97, that object-oriented constructs were appended to the ANSI standard.

So for the throngs of you who wrote to chide me for suggesting Cobol code was not object-oriented, the 41 years of legacy Cobol code in the field did not magically "become" object-oriented three years ago just because the specification was updated.

Many of you took exception when I suggested Cobol is no longer taught in the majority of our nation's institutes of higher learning. You have let me know that you've heard of and taken courses, you have offered lists of universities with courses, and have even let me know that you have read books about Cobol.

U.S. News and World Report recently published a list of the top colleges and universities in the United States. Among them were the likes of MIT and Cal Tech. We polled the top 10 institutions on the list and found that in the classroom Cobol is mentioned only anecdotally in context of the history of programming, but not a single school currently offers coursework in Cobol. Not one.

I won't deny that Cobol courses exist, but the fact is that most schools are no longer placing an emphasis on Cobol. Given the vast amounts of data and systems currently running Cobol, I willingly admit that this is likely to pose difficulties for code maintenance and other issues further down the road.

To the many who have cited the open-source movement as the catalyst thrusting Cobol into a "full-throttled resurgence," to quote one reader, you will be disappointed to learn that none has produced a Cobol-compliant compiler. Two relatively active projects, Tiny Cobol compiler for Linux and Cobol for GCC, embarked in 1999 to produce Cobol 85 compilers (not Cobol 97). Both are stalled in prealpha stage..

There are now no open-source compilers for Cobol available under the GNU General Public License. In fact, there are currently no free, fully functional, commonly known Cobol development environments that could be recommended for enterprise use.

If you're looking for a free compiler for Windows, Fujitsu offers its Version 3 starter set, but for database connectivity you will need to upgrade to Version 4.0. A shareware DOS compiler (Cobol 650) is available from www.flexus.com; however, it is outdated, there is no known source code, and the author died several years ago, according to Flexus.

A boon to open-source development will likely come by way of the public release of a Cobol test suite from the National Institute of Standards and Technology. The package should enable faster testing of Cobol 85 standards development and help move these projects through to completion in a more timely manner.

The comparisons I drew in the article do not pit Cobol against Java or any other language. There is no "one size fits all" method for selecting a programming language. Each has been developed to fill a particular niche or service, and as in anything, you must choose the right tool for the right job.

Finally, if anyone is hiring Cobol programmers, I have résumés from people blaming me for their layoffs. Let me know at james_borck@infoworld.com.