Should COBOL come back .....?

Recently , I was going through and found encouraging ---

so I thought to present it as it is and read on ---------

Cobol, that much-maligned zombie of a programming language, simply refuses to die and has been back in the news of late--particularly in California where it made headlines for thwarting the governor's budget-cutting plans. Michael Swaine will have a little something to say on the subject in the next issue of DDJ--but until then, you can take a walk down Cobol's memory lane with this status report, written by IBM's Henry Saade and Ann Wallace for a 1995 issue of Dr. Dobb's Journal.

Cobol '97: A Status Report

Cobol gets object oriented

by Henry Saade and Ann Wallace



If you think that Cobol is a language for days past, consider that, according to the Datapro Information Services Group, an estimated 150 billion lines of Cobol source code are at work in mission-critical business applications worldwide, and programmers add about five billion lines each year. Likewise, International Data Corp. reports that revenues for Cobol desktop development are expected to increase to $176.4 million by 1998, up from $86.3 million in 1993. These figures indicate a solid average growth rate of about 15.4 percent a year. In medium-size and large U.S. companies, 42.7 percent of all applications-development staffs use Cobol. Thirty-five percent of such companies report that the language is used for more than two-thirds of their applications.

While languages such as C++ and Smalltalk garner the lion's share of attention from the object-oriented community, Cobol has also been making object-oriented strides. In particular, a proposed revision of the Cobol standard includes object-oriented extensions. The draft standard is being developed jointly by the International Organization for Standardization (ISO) and Accredited Standards Committee X3 (ASC X3), the latter operating under the procedures of the American National Standards Institute (ANSI). The target date for completion of the proposed standard is 1997.
While we will focus in this article on the object-oriented extensions to Cobol, we will also highlight other features proposed in the draft.

Historically Speaking
Cobol's early acceptance can be traced to the fact that it was the first stable, portable business language. Since the language was conceived in 1959 by the Conference on Data Systems Languages (CODASYL), committees have continually refined and improved it, incorporating innovative programming methods. CODASYL, ANSI, and ISO have regularly published the agreed-upon standards emerging from these committees.

With the incorporation of structured programming, the 1985 standard (ANSI X3.23-1985) introduced major enhancements to Cobol. Structured-programming concepts were part of a movement in programming methodology toward replacing unwieldy, multibranching "spaghetti" code with a more tightly controlled flow of logic. As part of Cobol, it gave users more readable and maintainable programs.
Standardization has given Cobol a high degree of reliability and portability. From the beginning, programmers wanted Cobol to be a robust language that they could use on any platform or computer. This need expanded as multiplatform installations became more common in the 1980s. Vendors met the challenge by making standard-compliant implementations of Cobol available on many platforms and systems, including mainframe and midrange computers, DOS, UNIX, Windows, and OS/2. (IBM, for example, uses the same Cobol compiler technology on MVS, VM, VSE, AIX, and OS/2.)

Today, the 1985 Cobol standard is widely accepted, and most industry and government organizations rely on adherence to it. In order to bid on government jobs, for instance, Cobol implementations must conform to the Federal Information Processing Standard for Cobol (FIPS 21-4), which is based on Cobol standards.

A New Standard
The draft 1997 proposal for Cobol incorporates the basic object-oriented programming capabilities found in C++ and Smalltalk (see Table 1): inheritance, which allows objects to inherit data and behaviors from other objects; polymorphism, which simplifies coding by letting programmers use a single interface to access objects of different classes; and encapsulation, which hides the implementation of data and methods from clients (user code), thereby protecting clients from the effects of implementation change.