COMPUTE afterTax ROUNDED = beforeTax + (beforeTax * salesTaxRate)
DISPLAY "After tax amount is " afterTax.
Listing 1-2. Java Version (from http://caliberdt.com/tips/May03_Java_BigDecimal_Class.htm)
import java.math.BigDecimal;
public class SalesTaxWithBigDecimal
{
public static void main(java.lang.String[] args)
{
BigDecimal beforeTax = BigDecimal.valueOf(12345, 2);
BigDecimal salesTaxRate = BigDecimal.valueOf(65, 3);
BigDecimal ratePlusOne = salesTaxRate.add(BigDecimal.valueOf(1));
BigDecimal afterTax = beforeTax.multiply(ratePlusOne);
afterTax = afterTax.setScale(2, BigDecimal.ROUND_HALF_UP);
System.out.println( "After tax amount is " + afterTax);
}
}
The programs do the same job. The COBOL program uses native decimal data, and the Java program creates
data-items using the bolted-on BigDecimal class (itself an acknowledgement of the importance of decimal data for this application domain). The programs are presented without explanation (we’ll revisit them in Chapter 12; and, if you need it, you can find an explanation there). I hope that, in the course of trying to discover what the programs do, you can agree that the COBOL version is easier to understand—even though you do not, at present, know any COBOL
but are probably at least somewhat familiar with syntactic elements of the Java program.
History of COBOL
Detailed histories of COBOL are available elsewhere. The purpose of this section is to give you some understanding of the foundations of COBOL, to introduce some of the major players, and to briefly describe the development of the language through the various COBOL standards.
Beginnings
The history of COBOL starts in April 1959 with a meeting involving computer people, academics, users, and
manufacturers to discuss the creation of a common, problem-oriented, machine-independent language specifically designed to address the needs of business8. The US Department of Defense was persuaded to sponsor and organize the project. A number of existing languages influenced the design of COBOL. The most significant of these were AIMACO (US Air Force designed), FLOW-MATIC (developed under Rear Admiral Grace Hopper) and COMTRAN
(IBM’s COMmercial TRANslator).
3
Chapter 1 ■ IntroduCtIon to CoBoL
The first definition of COBOL was produced by the Conference on Data Systems Languages (CODASYL)
Committee in 1960. Two of the manufacturer members of the CODASYL Committee, RCA and Remington-Rand-Univac, raced to produce the first COBOL compiler. On December 6 and 7, 1960, the same COBOL program (with minor changes) ran on both the RCA and Remington-Rand-Univac computers.8
After the initial definition of the language by the CODASYL Committee, responsibility for developing new
COBOL standards was assumed by the American National Standards Institute (ANSI), which produced the next three standards: American National Standard (ANS) 68, ANS 74, and ANS 85. Responsibility for developing new COBOL
standards has now been assumed by the International Standards Organization (ISO). ISO 2002, the first COBOL
standard produced by this body, defines the object-oriented version of COBOL.
COBOL Standards
Four standards for COBOL have been produced, in 1968, 1974, 1985, and 2002. As just mentioned, the most recent standard (ISO 2002) introduced object orientation to COBOL. This book mainly adheres to the ANS 85 standard; but where this standard departs from previous standards, or where there is an improvement made in the ISO 2002
standard, a note is provided.
The final chapter of the book previews ISO 2002 COBOL. In that chapter, I discuss why object orientation is desirable and what new language elements make it possible to create object-oriented COBOL programs.
COBOL ANS 68
The 1968 standard resolved incompatibilities between the different COBOL versions that had been introduced by various producers of COBOL compilers since the language’s creation in 1960. This standard reemphasized the common part of the COBOL acronym. The idea, contained in the 1960 language definition, was that the language would be the same across a range of machines.
COBOL ANS 74 (External Subprograms)
The major development of the 1974 standard was the introduction of the CALL verb and external subprograms.
Before ANS 74 COBOL, there was no real way to partition a program into separate parts, and this resulted in the huge monolithic programs that have given COBOL such a bad reputation. In these programs, which could be many tens of thousands of lines long, there was no modularization, no functional partitioning, and totally unrestricted access to any variable in the Data Division (more on divisions in Chapter 2).
COBOL ANS 85 (Structured Programming Constructs)
The 1985 standard introduced structured programming to COBOL. The most notable features were the introduction of explicit scope delimiters such as END-IF and END-READ, and contained subprograms. In previous versions of COBOL, the period (full stop) was used to delimit scope. Periods had a visibility problem that, taken along with the fact that they delimited all open scopes, was the cause of many program bugs. Contained subprograms allowed something approaching procedures to be used in COBOL programs for the first time.
COBOL ANS 2002 (OO Constructs)
Object orientation was introduced to COBOL in the ISO 2002 standard. Whereas previous additions had significantly increased the huge COBOL reserved word list, object orientation was introduced with very few additions.
4
Chapter 1 ■ IntroduCtIon to CoBoL
The Argument for COBOL (Why COBOL?)
As you’ve seen, COBOL is a language with a 50-year history. Many people regard it as a language that has passed its sell-by date—an obsolete language with no relevance to the modern world. In the succeeding pages, I show why, despite its age, programmers should take the time to learn COBOL.
Dominance of COBOL in Enterprise Computing
One reason for learning COBOL is its importance in enterprise computing. Although the death of COBOL has been predicted time and time again, COBOL remains a dominant force at the heart of enterprise computing. In 1997, the Gartner group published a widely reported estimate that of the 300 billion lines of code in the world, 240 billion (80%) were written in COBOL.9 Around the same time, Capers Jones10 identified COBOL as the major programming language in the United States, with a software portfolio of 12 million applications and 605 million function points.
To put this in perspective, in the same study he estimated that the combined total for C and C++ was 4 million software applications and 261 million points. According to Jones, each function point requires about 107 lines of COBOL; so, in 1996, the software inventory for the United States contained about 64 billion lines of COBOL code.
Extrapolating for the world, the Gartner estimate does not seem outside the realms of possibility.
Of course, the 1990s were a long time ago, and in 1996/97, Java had just been created. You might have expected that as Java came to the fore, COBOL would be eclipsed. This did not happen to any significant extent. Much new development has been done in Java, but the existing inventory of COBOL applications has largely remained unaffected. In an OVUM report in 2005,11 Gary Barnett noted, “Cobol remains the most widely deployed programming language in big business, accounting for 75% of all computer transactions” and “90% of all financial transactions.”
In that report, Barnett estimated that there “are over 200 billion lines of COBOL in production today, and this number continues to grow by between three and five percent a year.”
Even today, COBOL’s position in the domain of business computing does not seem to be greatly eroded. In a
survey of 357 IT professionals undertaken by ComputerWorld in 2012,2, 12 54% of respondents said that more than half of all their internal business appli
cation code was written in COBOL. When asked to quantify the extent to which languages were used in their organization, 48% said COBOL was used frequently, while only 39% said the same of Java. And as the 2005 OVUM report11 predicted, new COBOL development is still occurring; 53% of responders said that COBOL was still being used for new development in their organization. Asked to quantify what proportion of new code was written in COBOL 27% said that it was used for more than half of their new development.
Although only tangentially relevant to the issue of COBOL’s importance in business computing, one other item of interest came out of the ComputerWorld survey.2, 12 Responders were asked to compare Visual Basic, C#, C++, and Java to COBOL for characteristics such as batch processing, transaction processing, handling of business-oriented features, runtime efficiency, security, reporting, development cost, maintenance cost, availability of programmers, and agility.
In every instance except the last two, COBOL scored higher than its more recent counterparts.
Finally, in a May 2013 press release, IBM noted that nearly 15% of all new enterprise application functionality is written in COBOL and that there are more than “200 billion lines of COBOL code being used.13”
Danger, Difficulty, and Expense of Replacing Legacy COBOL Applications
The custodians of legacy systems come under a lot of pressure to replace their legacy COBOL code with a more modern alternative. The high cost of maintenance, obsolete hardware, obsolete software, the scarcity of COBOL
programmers, the need to integrate with newer software and hardware technologies, the relentless hype surrounding more modern languages—these are all pressures that drive legacy system modernization in general and language replacement in particular. How is it then that the COBOL software inventory seems largely unchanged?
When a legacy system is considered for modernization, a number of alternatives might be considered:
• Replacement with a commercial off-the-shelf (COTS) package
• Complete rewrite
5
Chapter 1 ■ IntroduCtIon to CoBoL
• Automatic language conversion
• Wrapping the legacy system to present a more modern interface
• Code renovation
• Migration to commodity hardware and software
The problem is, experience shows that most modernization attempts that involve replacing the COBOL code fail.
Some organizations have spent millions of dollars in repeated attempts to replace their COBOL legacy systems, only to have each attempt fail spectacularly.
Replacement with a COTS Package
Replacement is much harder than it seems. Many legacy COBOL systems implement functionality such as payroll, stock control, and accounting that today would be done by a COTS system. Replacing such a legacy system with a standard COTS package might seem like an attractive option, and in some cases it might be successful; but in many legacy systems, so many proprietary extensions have been added to the standard functionality that replacement is no longer a viable option. Attempting to replace such a legacy system with a COTS package will fail—either completely, causing the replacement attempt to be abandoned; or partially, leading to cost and time overruns and failures in functionality fit.
I know of one instance where a university attempted to replace a COBOL-based Student Record System with a
bought-in package as a solution to the Y2K problem. Around September 1999, the school realized that, due to database migration difficulties, the package solution would not be ready in time for the millennium changeover.
A successful Y2K remediation of the existing COBOL legacy system was then done, and this bought sufficient time for the new package to be brought on line. Even then, the package only implemented about 80% of the functionality formerly provided by the legacy system.
Complete Rewrite
A complete rewrite in another language is often seen as a viable modernization option. Again, in a restricted set of circumstances, this might be the case. When the documentation created for original legacy system is still available, there is no reason the rewritten replacement should not be as successful as the original. Unfortunately, this happy circumstance is not the case with most legacy systems.
These systems often represent the first parts of the organization to be computerized. They embody the core functionality of the organization; its mission-critical operations; its beating heart. When these systems were created, they replaced the existing manual systems. In the intervening years, the requirements, system architecture, and other documentation have long since been lost. The people who operated the manual system and knew how it worked have either retired or moved on. The rewrite cannot be treated as a greenfield site would be treated, where the requirements could be elicited from stakeholders. For all sorts of legal, customer, and employee reasons, the functionality of the new system must match that of the old. The only source of information about how the system works is embedded in the COBOL code itself. Extracting the business rules from existing legacy code, in order to specify the requirements of the new system, is a very difficult task. The failure rates for most legacy system rewrites are very high.
Automatic Language Conversion
Automatic language conversion is often touted as a solution to the lack of architectural and functional documentation in legacy systems. You don’t have to know how the system works, goes the mantra; you can just automatically convert it into a more modern language. But converting legacy COBOL code is a much more difficult task than people realize.14 Even if the functionality can be reproduced (and this is highly problematic),3 the resulting code is likely to be an unmaintainable, unreadable mess. It is likely to consist of many more lines of code than the original15 and 6
Chapter 1 ■ IntroduCtIon to CoBoL
to retain the idiom or flavor of COBOL. Although such converted software may be written in the syntax of the target language, it will not look like any kind of a program that a programmer in that language would normally produce.
Such automatically produced programs14 will be so foreign to those who have to maintain them that they are likely to be received with some hostility.
Some organizations advertise their ability to convert legacy COBOL to another language. This is a given; the questions are: how faithful is the conversion and how maintainable is the converted code? Few if any case studies (where they exist at all) mentioned by these organizations address the maintainability problems that may be expected of code produced by automatic language conversion. Although such conversions may alleviate the shortage of COBOL
programmers, they probably cause an increase in maintenance costs. It is doubtful if any of these conversions can be deemed a success.
Approaches to legacy system modernization that involve replacing the COBOL code have not been very
successful. They either fail completely and have to be abandoned, fail in terms of cost and deadline overruns, or fail in terms of not delivering on maintainability promises.
Wrapping the Legacy System
Most successful modernization efforts retain the COBOL code. Wrapping the legacy code solves interfacing problems but does not address the cost of maintenance, or hardware or software obsolescence problems. On the other hand, it is cheap, it is safe, and it provides an obvious, and immediate, return on investment (ROI).
Code Renovation
Code renovation addresses the cost-of-maintenance problem but none of the others. It is safe and has very good tool support from both COBOL vendors and third parties, but it does not provide an obvious ROI.
Migration to Commodity Hardware and Software
Migration involves moving the legacy COBOL code to modern commodity hardware and software. This approach
has some risks, because the COBOL code may have to be changed to accommodate the new hardware and software.
However, there is significant tool support to assist migration, and this greatly mitigates the risk of failure. Many case studies point t
o the success of the migration approach, as borne out by a 2010 report from the Standish Group.16 This report found that migration and enhancement “stands out as having the highest chance of success and the lowest chance of failure” with the new software development project “six times more likely” and the package replacement project “twice as likely” to fail as migration and enhancement.
Migration solves many of the problems with legacy systems. Obsolescence is addressed by moving to more
modern hardware and software. General costs are addressed through the elimination of licensing fees and other costs (in one case study, replacing printed reports with online versions saved $22,000 per year).17-18 Maintenance costs are often also addressed because code renovation usually precedes a migration. However, interfacing with modern technologies might still be a problem, and there remains the problem of the scarcity of COBOL programmers.
Shortage of COBOL Programmers: Crisis and Opportunity
A major issue that prompts companies to attempt replacement of their legacy COBOL with some other alternative is the perceived scarcity of COBOL programmers. Harry Sneed states this baldly: “The reason for this conversion is that there are no COBOL programmers available. Otherwise the whole system could have been left in COBOL.3”
He comments that COBOL “is no longer taught in the technical high schools and universities. Therefore, it is very difficult to recruit COBOL programmers. In Austria it is almost impossible to find programmers with knowledge of COBOL. Those few that are left are all close to retirement.” Because of their seniority, they are also more expensive than cheap, young Java programmers.
7
Chapter 1 ■ IntroduCtIon to CoBoL
However, the problem is not that there are no COBOL programmers. Capers Jones estimated that there were
550,000 COBOL programmers in the United States to deal with the Y2K problem.10 Even now, Scott Searle of IBM
estimates that the current worldwide population of COBOL programmers is about two million programmers, with about 50,000 of these in India.19 The real problem is that most of the population of COBOL programmers are nearing retirement age. This is a crisis in the making. As already discussed, it is dangerous and expensive to attempt to replace COBOL legacy systems; but when these COBOL programmers retire, who will maintain the legacy systems?
Michael Coughlan Page 2
