Is COBOL Dying ... or Thriving?
The usual title for an article like this is, "Is COBOL dead?" But that was a silly question 15 years ago. And today, after the Y2K repair of billions of lines of COBOL code, that question is even sillier. As this report shows, COBOL is here to stay...and it may even play a key role in the applications of the future as the language that's used for business logic and business objects.
On the other hand, it's perfectly reasonable to ask, "Should COBOL still be taught?" Or, "What can we do about declining COBOL enrollments when Java and Visual Basic are getting all the hype?" So after this report tries to describe the future of COBOL, it will try to answer those questions.
The current status of COBOL on the mainframe
The typical enterprise application today consists of hundreds of COBOL programs running on an IBM mainframe computer. To drive the workstations or PCs that use those applications, the programs run under a control system known as CICS. In the early 90s, 495 of the Fortune 500 companies used CICS systems to drive their major applications, and I suspect those numbers are pretty much the same today. Currently, those systems process approximately 30 billion (yes, billion) transactions each day.
In the late 90s, Fortune 500 and second 500 companies spent many billions of dollars fixing the Y2K problems in their COBOL (and CICS) programs. As they fixed the date problems, they also upgraded the code so these programs could continue to run indefinitely. As we see it, that speaks volumes. These programs are not going to be replaced by other types of systems in the foreseeable future because there's not enough money, time, or programming talent to do that. Besides that, these programs work the way they're supposed to.
This has two important implications. The first one is that these programs will have to be maintained and enhanced. That in turn means that there will be a continuing demand for COBOL programmers with about 70% of the work in the form of maintenance and the other 30% in the form of enhancements. Because so much maintenance was done as a part of the Y2K efforts, I think there's a temporary lull in this demand right now, but it should pick up again during the next two years.
The second implication is that all new applications are going to have to co-exist with this base of applications. So if you want to develop a new application that's going to replace an existing application, you're going to have to integrate the new application with the existing system. To do that effectively, you need to understand how the programs, files, and databases of the existing system work. It also helps if you can read the code in the old system to make sure you get the calculations, lookups, and other business logic and rules right. That, of course, means you need to understand COBOL.
The future of COBOL on the mainframe
To help deal with the problems of system integration, IBM has developed a master strategy for making COBOL, CICS, and DB2 the foundation for web and intranet applications. In this scenario, CICS is the transaction processor for web applications, DB2 is the database, and COBOL provides the business logic that drives these applications. That takes care of all the programming except for the user interfaces on the clients or terminals, and these can be developed with Java, Visual Basic, or other programming languages. But that means that all Java and Visual Basic will do is provide the graphical user interfaces that send data to and receive data from CICS. In other words, the role of these languages will be extremely limited.
How likely is it that this scenario or one like it will prevail? I think it's quite likely for three reasons. First, it's a lot simpler to develop a large application with a single database server than it is to replicate that data over several (or dozens) of smaller servers. Second, a heavy-duty transaction processor like CICS currently provides processing efficiencies that are superior to those that are possible with client/server technologies. Third, IBM is in the best position to provide workable solutions for system integration because they control the mainframe. So even if this master plan changes somewhat during the next few years, DB2 and CICS on a mainframe with COBOL as the self-documenting business language is going to be a tough combination to beat.
The future of COBOL on smaller systems
Up to this point, we've been talking about enterprise systems. But what about mid-range systems, PC networks, and web applications for smaller systems? What's the future of COBOL on those systems?
To start, I would guess that mainframe applications account for at least 90% of the COBOL code that is currently in operation (can anybody help me with data on this?). In the 1980s, some substantial COBOL applications were developed for DEC and Wang systems, but these systems were in trouble once the power of a network of PCs became apparent. Raul Menendez, one of the authors of our COBOL book, worked on a few applications written in Accu-COBOL and Micro Focus COBOL for Unix systems in the mid-90s. And I've corresponded with a few developers who have converted COBOL applications from mid-range systems to PC networks (described as "nightmare" projects). But overall, COBOL activity on these platforms seems to be extremely limited, even though a compiler like Micro Focus Net Express provides for web, GUI, database, and object-oriented programming.
On the other hand, the new .Net framework from Microsoft provides an opportunity for COBOL to become a player in the development of object-oriented client/server systems, and Fujitsu is developing a COBOL compiler that will work in that environment. That means that you'll be able to develop COBOL classes (objects) that will work with classes developed in other languages. That also means that developers of the future may be able to use the best language for developing each type of class...like Visual Basic for developing the GUI classes and COBOL for developing the business classes (the ones that provide the business rules and logic). That's an interesting scenario, and one that could give COBOL a significant role in future applications.
Should COBOL still be taught in the college curriculum?
If you agree with my analysis thus far, I hope the role of COBOL in the college curriculum is clear. If there's any chance that your students are going to work for companies with enterprise systems, I think you still need to offer COBOL courses. COBOL is especially useful for Information Science or MIS majors who will someday need to analyze existing enterprise systems. And COBOL maintenance programming is an entry-level job that provides excellent background for working with all types of systems.
From a purely academic point of view, I think there's another reason for offering COBOL courses. That is, that COBOL provides a striking contrast to Visual Basic and Java. Structured programming vs. object-oriented programming. Compile-and-test vs. an integrated development environment. Self-documenting code vs. cryptic code. One Read statement to read a record in a file vs. no easy way to read a record in a file. Each language has its strengths and its weaknesses, and no language provides the perfect solution. By experiencing these differences, your students develop the perspective they need for the real world.
I realize, though, that the problem is finding the time to teach all of the subjects, so you have to make choices. If I had to choose, my minimum requirements would be one or two semesters of either Visual Basic or Access because they illustrate the visual approach to system development; one semester of C++ or Java because they illustrate the object-oriented approach to system development; and one or two semesters of COBOL because it illustrates the traditional, structured approach to system development. If your students understand all three approaches, they will have the background they need for coping with the many changes that the future is going to bring.
What can be done about declining COBOL enrollments?
A number of instructors asked this question, and my short answer is: Make one or two semesters of COBOL a requirement for students enrolled in the major. I know COBOL doesn't have the glamour of Java or Visual Basic or web programming, but who says that the students are in any position to know what's good for them? If you believe, as I do, that COBOL is an important piece of the development puzzle, make them learn it. And if that's politically incorrect, at least make COBOL a strongly-recommended elective.
Beyond that, we've tried to develop a new COBOL book that will help COBOL courses become more interesting and relevant...and less "boring" (a word we hear all too often from COBOL students). As we started the development of our book, we tried to look at the traditional textbooks through the eyes of 19-year olds. After we did that, we decided that we had to start our book with simple interactive programs that lead to the "Aha!" experience in the very first chapter and build on that experience in all subsequent chapters. We also know from experience with our Visual Basic book that students love our paired-pages format so we used that in our COBOL book. Now, we think we have a book that just might reverse those declining enrollments.
About the author
Mike Murach is the president of Mike Murach & Associates, Inc., a leading publisher of COBOL and mainframe books. He wrote this article in response to questions from college chairpersons and instructors who have to decide where COBOL fits in the modern computing curriculum. Mike can be reached at email@example.com, and the company web site address is www.murach.com
© 2001, Mike Murach & Associates, Inc.
|HOME | COMPILERS | TOOLS | EXAMPLES | SPONSORS | NEWSWIRE|
|Copyright© 1996-2012, First Place Software, Inc.|