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

Easy Solution

[minginqunt]

Modernize? Pah.

Why not just rewrite it in PHP. Another 30 years of guaranteed fat support contracts. Always think of your potential pay-packet.

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:Easy Solution

[plopez]

You forgot:

"While the FOSS zealots are flaming each other a MS partner shows up and sells them a set of cut rate licenses and thells them how easy it is to develop in VB .Net. When the programming staff here of this they quit. "No problem" says the partner, who then introduces them to an Indian offshoring company who sells them a bushel of VB programmers. THe VB programmers muck up the job, requiring bringing in another consulting firm. The consulting firm says "No wonder you can't get it to work, you need to upgrade to the latest MS software!" and sell mgt a firkin of rather more expensive licenses.

The offshoring company still doesn't get it so mgt decides to reel the project back in. They hire a hogshead of onshore VB programmers who kind of sort of get it to work, though it still relies on the legacy system to do the heavy lifting. The project is deemed a success, and goes into a (very expensive) maintnenence mode. The managers spruce up thier resumes and bail.

Meanwhile, in the basement grandpa/ma is sitting in a rocker whittling a new toothpick and keeping the legacy system running. Day by day grandpa/ma marks off the days to retirement after which all hell will break loose. Unless you hire gramps back as a consultant at 3x previous salary".

There, hope this helps.

Re:Easy Solution

[try_anything]

Java is popular because strong typing prevents bad programmers from being stupid.

Not really. Compile-time type checking catches a certain amount of absent-mindedness and serves as a bit of extra documentation, no more. What Java really does is force people to do things the long, simple, stupid way instead of the clever way. Brian Kernighan wrote, "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." The same goes double for your coworkers, who did not write the code in the first place. Many people do not have enough discipline to refrain from cleverness in Perl or Haskell, especially Perl, where one person's everyday tool is another person's obscure little corner of the language.

Re:Easy Solution

[ejp]

Heck, I can do it in 2 lines of perl! :-)

But it is modern!

[(H)elix1]

One of my friends who ends up porting and bridging Cobol systems was quick to inform me, "COBOL is OO, look, see, print line is extending space".

Re:But it is modern!

[srmalloy]

I understand there is already an object-oriented version of COBOL extant, which, according to the existing naming convention for the OO version of an existing language, was called ADD_ONE_TO_COBOL_GIVING_COBOL.

The Tao of Programming

[symbolset]

The Tao of Programming, 1:2 :

The Tao gave birth to machine language. Machine language gave birth to the assembler.

The assembler gave birth to the compiler. Now there are ten thousand languages.

Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.

But do not program in COBOL if you can avoid it.

Observe the wisdom of the Tao

Re:'legacy modernization'

[Anonymous Coward]

No.. it had it's time, please let it die.

Yeah, when I saw "Modernize" and "Cobol" in the same sentence I wanted to gouge my eyes out with a Kentucky Fried Chicken spork.

Cobol makes baby Jebus cry!

A Modest Solution

[BigGar']

Just merge C, Ruby, & COBOL syntax into one compiler.
Now coders can start migrating away from Cobol without the hassle of rewriting entire programs. They can do it one line at a time, as they get to it.

Now if we could just merge Java, & Perl in there you'd really have something.

Lords of COBOL...

[Lemming Mark]

...hear my prayer!

Frank Lloyd Wright

[dildo]

When asked about how to improve Pittsburgh, the famous architect had an immediate reply:

"Abandon it."

Cross out 'Pittsburgh', replace with 'COBOL', you get the idea.

Re:'legacy modernization'

[Tackhead]

> Yeah, when I saw "Modernize" and "Cobol" in the same sentence I wanted to gouge my eyes out with a Kentucky Fried Chicken spork.

Add MODERNIZATION to COBOL giving (MESS given by ADDITION of (SPORK given by ADDITION of FORK to SPOON) to EYES)

That's the modern version. It woulda taken me three lines to do it the old way.

The lords of Kobol

[goombah99]

Blasphemy. Rewriting the sacred text of the colonies. Where's Cmdr Adama?

Re:From my experience

[morgan_greywolf]

(the sole purpose why the language was built, thus why they named it COMMON BUSINESS ORIENTED LANGUAGE)

Yeah, I guess you must be a COBOL programmer, since you seem to like TYPING IN ALL CAPS.

Anyway, the appropriate acronymical expansion of COBOL is 'Confused Oriental Bean-cOunting Langauge.'

Oh, BTW, how's the fingers? Stubs yet? ;)

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.