Find below an article from Steve Gomori about the future of COBOL
During my time with the CIS department at Ohio State I have come in Contact with several C/C++/Java/Perl students who will ask why an
institution Would continue to teach COBOL. Isn't it being replaced? Isn't it out-dated? Haven't most places already converted to something else?
No. No. No.
Of course, they look at me like I just fell off of a turnip wagon and Had it back over me before I had a chance to stand back up. They're convinced, for some reason, that this is a dead language. They can offer no justification for this opinion, it just is. Pretty strong conviction for someone who's had no exposure to the industry. Maybe it's just hopeful thinking.
There is a simple reason why it isn't being replaced and new development Is not being done in another language. The same reason why existing COBOL systems aren't being rewritten in another language. The reason? There is no alternative to turn to.
What about C/C++? What about Java? Not likely. COBOL can do too many Things that other languages cannot do, or cannot do easily.
Like,
1. accessing indexed-sequential files,
2. producing formatted numeric output,
3. access hierarchical and network databases,
4. run in a pseudo-conversational interactive environment,
5. process huge files.
6. Plus, those other languages have no concept of "records" (at least as being the natural components of a file).
For business applications these are not trivial matters. They are vital.
Remember, C++ and Java weren't developed to compete with, or replace COBOL. COBOL is a business language (that's what the "B" stands for), C/C++ is not. There is no "B" in C or Java. If you knew all these languages and were given an assignment, you wouldn't have to sit and think about which language would be best for a task. It would clearly be one and not the others. A program that should be written in C/C++ would never be written in COBOL, and vice versa. It applies for Java.
I'm not slamming any of these languages. I like C++ and I like Java. They're great for what they were intended for, just like COBOL, SQL and Visual Basic. Take any language out of its element and it quickly becomes inadequate.
You need to develop a web app, go with Java.
You need a Windows-based GUI app or GUI front end for a client-server app, then use Visual Basic.
Middle-tier for that client-server application? C++ or C#.
Need to process large files for a business app? COBOL.
Formatted reports for that business app? COBOL.
How about an on-line interface to that system that could have several, even hundreds of concurrent users (in-house)? COBOL.
OK. Let's pretend that Java was a suitable alternative. So we're saying it either can handle all the things a business needs in its processing or that the company is willing to live without a lot of its current functionality. A big stretch wither way. Let's look at the business case.
How long would it take a small company, with something like 15,000 programs, to convert to Java?
Let's say a person can get two programs done in a week (20 hours each). This includes coding, testing and implementation. Realistic? Probably not. But it's a nice round number.
If you figure a person works about 1,920 hours a year (the standard 2,080 hours in a year, minus 2 weeks vacation and minus another 10 days for holidays and sick time) then he/she can convert 96 programs a year.
This assumes that any non-productive time (in meetings, on the phone, etc.) is made up for. At that pace this conversion would take over 150 man-years. If that coder can get one program done a day it would still take .5 man-years. So at that pace an army of 63 consultants could be brought in for a year and get it all done.
How much would it cost? 63 consultants for a year? Ones that ow COBOL and Java well enough to pull this off? At $75 an hour (a little low, I think, but a round number) it would be over $9 million. What's the end result? If a program is rewritten correctly then will do exactly what it did before. The same results, the same output. The end user will see no difference. Except now you have a program that's harder to read, harder to document and harder to maintain.Hardly worth the effort and definitely not worth the cost.
Can you imagine trying to get approval on a budget item of nine million dollars to reproduce what you're already getting? Maybe the report will come off the printer faster but it still won't get delivered until the guy in the mail room makes his rounds.
Now consider a large company with COBOL programs numbering several more thousands.
There's more new COBOL development going on now than there ever was. Y2K tied up resources so there was a lot of work placed on the back burner that now needs to be done. Those new Y2K-compliant systems will need maintained. Y2K fixes will need corrected.
It's been estimated that over 150 billion lines of COBOL code is currently in use (not just exists, but is in use) with another 5 billion added annually. It's also been estimated that over 98% of the world's economy is processed by COBOL code. More new development in
COBOL than ever. And the language is still being revised. Exisitng COBOL code works as expected. No one has developed a language to challenge it. The future of COBOL is safe.
