Modernizing the Common Language - COBOL

Frumious Wombat writes "Over at the Register Developers section, they are quoting the head of research for Ovum Consulting on the continuing dominance of COBOL in certain business applications. The antique language accounted for 75% of all business transactions last year, and some 90% of financial transactions. For all the time spent arguing the merits of Ruby vs. C#, should the community spend more time building tools to make COBOL livable? The article goes into what it terms 'legacy modernization', and lays out some details on how to go about it. From the article: 'The first stage in the legacy modernization process is to understand the business value embodied within legacy systems. This means that developers must give business domain experts (business analysts) access to the legacy, using tools that help them find their way around it at the business level. Some awareness of, say, COBOL and of the legacy architectures will be helpful but we aren't talking about programmers rooting around in code - modern tools can automate much of this analysis for staff working at a higher level.'"

Comments

Re:Easy Solution

[eln]

Don't even suggest writing it in PHP, because then we'll spend the next 5 years arguing over how it should be done. You'll end up with an endless argument about whether it should be done in PHP or Python. Then a group of crackpots will pipe up from the corner that it should all be done in Ruby on Rails. Then a single scruffy looking dude will say the whole thing could be done in 5 minutes with 3 lines of Perl, and in fact he just wrote it. The others will unite for 5 seconds, long enough to say Perl is an ugly language, and resume their argument.

This will go on for years until the executives give up and hire an outside consultant who will do the whole thing in Java. It will be bloated and inefficient, and the UI will be ugly. People will begin dreaming about rewriting it. Eventually, someone will suggest re-writing the whole thing in PHP...

Re:From my experience

[gillbates]

can't replace the existing 200 billion lines of code.

Sure you can. A 20 line Perl script would probably work just as well.

And you can't maintain 200 billion lines of COBOL, either.

But seriously, COBOL is so verbose that the 200 billion lines of COBOL could probably be replaced by 100 million lines of C++ or Java. And it would be more maintainable. COBOL exists to keep programmers employed; consider what it provides for the programmer:

• Job Security: Everything is global - the programmer must keep the whole program, and all the programs called by it, and the programs that call it, in his head. Naturally, learning a complicated system takes time, meaning that the SYSTEM PROGRAMMER can't be replaced at the drop of a hat. If you fire him, you'll have to bring in EXPENSIVE CONSULTANTS until you can find the other programmer in your state who knows COBOL.
• Ease of use: No pithy naming standards to follow (unless enforced by the organization). No need to limit the scope of procedures (Hey! - everything's global, so why not put it all in one subroutine! Yay!). No complaints about inadvertently modifying variables you shouldn't, no type checking (real programmers don't need it...) etc...
• Big Money: You are one of the two available programmers in your state who know COBOL. The other one wants a second house in the Caymans, though you prefer the lakeside cottage in Wisconsin. Unless the company wants to hire EVEN MORE EXPENSIVE CONSULTANTS, they'll pay the salary to provide whichever house you choose.
• Ability to use the CAPSLOCK without offending anyone. Just like you used to post on usenet!
• Literacy skills: You'd never have to consider something complicated like "salary = (bonus + (hours * hourly_wage));" Instead, you have, in plain English:
  MULTIPLY HOURL-WAGE-IN-CENTS TIMES HOURS-LOGGED-FOR-THIS-EMPLOYEE-ONLY-NOT-INCLUDING- OVERTIME GIVING TEMPORARY-SALARY-FOR-THIS-WEEK.
  ADD TEMPORARY-SALARY-FOR-THIS-WEEK TO ONE-TIME-BONUS-FOR-SALARIED-EMPLOYEES-NOT-RECEIVIN G-PROFIT-SHARING.
  MOVE BY NAME TMP-EMPLOYEE-SALARY-CALCULATION-WORKSHEET-STRUCTUR E TO FINAL-EMPLOYEE-SALARY-WORKSHEET.

But I jest, of course. The truth is, most businesses are so afraid of moving away from COBOL that they'd rather continue to shell out premium salaries than take the risk of a failed migration. Kind of like a lot of Windows users - they'd like to try Linux, but are afraid of change. Well, I suppose you get what you deserve.