Discussion of COBOL 9X Standard
The question remains as to the future viability of this language. There are numerous reasons for COBOL's being viewed with disdain by its detractors. It is an unwieldy language unsuitable for solving large classes of problems. In its current implementation, it contains many features that exhibit syntactic ambiguities; it lacks elementary string processing capabilities; it is deficient in higher mathematical functions; it lacks the capacity to assign a simple function call to a variable; it does not support explicit pointers; it cannot allocate memory dynamically; it cannot execute code recursively; it is overly verbose; it is used to solve some rather uninteresting problems.
The COBOL 9X Standard does more than address these deficiencies; it extends the language's capabilities to a new playing field - Object Oriented. While the underlying motivation is one of obtaining a piece of the newer and growing market of client/server applications, the principle strategic issue facing the committee is that of adding object oriented extensions, while at the same time, maintaining downward compatibility with the existing corpus of code.
In its current implementation, COBOL is the most widely used language for handling large scale business applications. It handles File I-O in a clear and efficient manner; its capacity to define a data structure is superior to that of most other languages. There are an estimated 100 billion lines of COBOL Code in production today. Payrolls are maintained, utility bills are generated, ledger accounts are posted to, receivables are aged as COBOL chugs along as the workhorse of the industry, performing the grunt work of corporate business.
Applications written in COBOL are often called disparagingly "legacy systems", an appellation which usually designates large scale batch processing on mainframes with character based user interfaces consisting of reports and screens displayed on dumb terminals. Scenarios for improvements to such systems typically consists of porting generated data files off to some RDBMS server, summerizing the data, recasting the data structures, and adding a GUI interface with client access over a corporate network. The underlying mainframe based data infrastructure which remains, is mission critical - generally consisting of data collection and detail processing components. It is in this infrastructure where the overwhelming majority of corporate lines of COBOL code reside; it is here where the downward compatibility component that the new standard must be maintained if it is to succeed. The client-server software represents the new extensions to the standard.
In order for these new extensions to succeed, they must compete toe to toe with Visual Basic, C++, and, if corporate computing moves from the client server to the intranet model, Java. When previous COBOL Standards were published, implementation came several years after the standard. With the noted exception of IBM's quiet release of COBOL II in 1983, no vendor was in any great hurry to implement new COBOL standards; the market consisted of a relatively stable mainframe base with few incentives for change. What is noteworthy in this release is that the implementation precedes the publication of the standard. Client/Server OO COBOL exists today as a commercial product with at least one webserver running under it.
New players have entered the standards process - companies whose livelihood is dependant upon the future viablilty of the language. While the mainframe base is critical for the functioning of the corporate economy, the OO extensions are perceived to hold the future. The degree to which an ANSI imprimatur will help these companies' products on the marketplace is unknown.
COBOL is already an enormously verbose and feature laden language. How these new
extensions will affect future standards will depend upon the degree to which the old downward
compatibility must be maintained. One possibility would be to split the language into two
"dialects" with differing levels of functionality. One dialect could consist of a mainframe standard
equipped with the changes of Category A while the other would consist of a client/server/intranet
variant carrying the needed code to make the language "COBOL", OO extensions, and whatever
else an implementor chose to load on. Such a split in the programming language makes sense in
today's data processing market. As long as the corporate data infrastructure remains mainframe
based, traditional legacy applications will need to be enhanced and maintained via traditional
standard compilers. The idea that this need should not preclude or inhibit OO COBOL
development on the client/server side is what this Standard is all about.