Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Modernizing the Common Language - COBOL

Zonk posted more than 7 years ago | from the its-everywhere-its-everywhere dept.


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.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


It has been said... (1)

zeromorph (1009305) | more than 7 years ago | (#17474942)

It has been said of languages like C, C++, and Java that the only way to modify legacy code is to rewrite it - write once and write once again; or write once and throw away. On the other hand, it has been said of COBOL that there actually is one original COBOL program, and it only has been copied and modified millions of times.
from the wikipedia article COBOL [wikipedia.org]

Re:It has been said... (1)

tritonman (998572) | more than 7 years ago | (#17475612)

Last year I had a contract to convert a ton of PL/I and COBOL code into ANSI C. They were converting from mainframes with DB2 to Unix and Oracle. I assumed that many people were doing this. I know, converting from a dinosaur language to a medival language, I tried to get them to let me use c++, but it was a nogo.

Re:It has been said... (2, Insightful)

lowen (10529) | more than 7 years ago | (#17475702)

According to that Wikipedia article, the most recent ANSI COBOL standard is from 2002. Doesn't sound like a dead language. Hm, the 2002 standard includes OOP and other modern features.

Re:It has been said... (4, Insightful)

StarvingSE (875139) | more than 7 years ago | (#17475980)

The company I work for (large fortune 500 company) still uses a lot of cobol on the mainframe for financial transactions. Why use an "ancient" language? Because there is 20-30 years of business knowledge encoded in the cobol code. Not only that, but it is tested, tried, and it just works perfectly. Rewriting in a modern language would make no sense other than using the "latest technology." Rewriting would most certainly introduce bugs which could potentially cost the company millions since it is running financial processes. Cobol was meant for the business and financial world and is well suited for it.

Re:It has been said... (1, Interesting)

Anonymous Coward | more than 7 years ago | (#17475814)

That is not a good thing. COBOL is hands down the worst language in common usage today. Its dominance is not continued by good programmers but by managers who consider it a 'safe' choice. Of course it hasn't been rewritten, the very ground that it is built on is considered antediluvian in concept.

Re:It has been said... (1)

LizardKing (5245) | more than 7 years ago | (#17475892)

Whatever happened to NPOV (Neutral Point Of View) in Wikipedia articles? Or can you say anything as long as you prefix it with "It has been said ..."? If so I'm going to create an article about me with the line "It has been said that Chris has the good looks of Antonio Banderas and is hung like John Holmes".

Easy Solution (3, Funny)

minginqunt (225413) | more than 7 years ago | (#17474952)

Modernize? Pah.

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

It has worked well for MS and anti-virals (1, Insightful)

Anonymous Coward | more than 7 years ago | (#17475056)

Seriously, MS has had no real reason to do a secure OS. In fact, the opposite is true. It is the add-ons that make money for everybody. Of course, with apple having been secured and linux up and coming, MS is finally under pressure to do the right thing.

Re:Easy Solution (5, Funny)

eln (21727) | more than 7 years ago | (#17475104)

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 (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#17475240)

What up, muhfuckas? Fuck this cobol shit, we ain't talking 'bout that shit no more. It's my show now. Anyway, what the fuck's up in this bitch. Yeah, so anyways, bill clinton, george bush and saddam walk into a bar... Bartender's like, what's this some kind of joke?


Later on that night, Celine Dion walks into the same bar... Bartender's like, why the long face?

No, seriously, a baby seal walks into a club..

So, why is it that women have 2 complete sets of lips? So they can piss and moan at the same time.

Shut up before I hang you from a tree and stick a pitchfork up your azzzzzzzzzzzzzzzzz. Beeyatches.

Re:Easy Solution (3, Funny)

plopez (54068) | more than 7 years ago | (#17475582)

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 (3, Insightful)

NewWorldDan (899800) | more than 7 years ago | (#17475206)

Modernize - the bottomless pit to throw consulting dollars into. Most attempts to rewrite a legacy app into a modern language have met with failure by way of the modern language becomming obsolete before the project is finished. One such project I witnessed ended up with 7 years of VB development being scrapped after a merger - in favor of the other company's unfinished conversion of their legacy app. Either way, there was a scheduled conversion from VB6 to .NET that hadn't even begun (and the app still was still heavily dependent on the legacy app to finish most tasks.) Ugh.

Re:Easy Solution (2, Insightful)

rbanffy (584143) | more than 7 years ago | (#17475972)

I think that rewriting it on VB is somehow related to the repeated failures.

VB is nice for the small things or even for the unambitious GUI layer of something larger, but it is just not suited for long-life projects - it introduces too much ugliness too early into the product life and maintenance usually makes it even uglier.

Re:Easy Solution (0, Redundant)

IdleTime (561841) | more than 7 years ago | (#17475610)

I'm sure you are an expert on COBOL since you so easy can determine it is possible to rewrite all the business applications in PHP. Do you know why COBOL is still used?

I haven't written COBOL in close to 20 years, but I do know that you will have a problem doing the same tasks in a different language as easy as it is done on COBOL. PHP got to be the worst alternative, I would rather rewrite it in APL than PHP.

Re:Easy Solution (0)

Anonymous Coward | more than 7 years ago | (#17475770)

The above mentioned system was rewritten from a COBOL ERP originally written in the mid-70's over the last four years.

'legacy modernization' (1, Informative)

Fr05t (69968) | more than 7 years ago | (#17475050)

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

Re:'legacy modernization' (1, Funny)

Anonymous Coward | more than 7 years ago | (#17475200)

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!

Re:'legacy modernization' (4, Funny)

Tackhead (54550) | more than 7 years ago | (#17475464)

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


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

Re:'legacy modernization' (0)

Anonymous Coward | more than 7 years ago | (#17475414)

Incorrect use of the apostrophe has had ITS (note the clever use of the possessive ITS) time as well, why won't you let it die?

But it is modern! (2, Funny)

(H)elix1 (231155) | more than 7 years ago | (#17475066)

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! (2, Funny)

srmalloy (263556) | more than 7 years ago | (#17475186)

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.

Re:But it is modern! (2, Informative)

jaavaaguru (261551) | more than 7 years ago | (#17475320)

There are a few implementations of object oriented COBOL for .Net out there...

Fujitsu COBOL and NetCOBOL for .NET [fujitsu.com]
Micro Focus Net Express [microfocus.com]

Both of those are rather expensive, and I've not seen any open-source ones yet. I thought it would be fun to write a COBOL compiler for .Net as a pet project. I've started it [blogspot.com], but haven't had much time to spend on it recently. My plan was to get it to a point where it can do some useful things then put it on sourceforge.

Re:But it is modern! (1)

tchuladdiass (174342) | more than 7 years ago | (#17475600)

It's nice to see another language designer on here. I've recently released my pet project on sourceforge, called 2e [sourceforge.net] (as in two e's, or ee, which stands for expression evaluator). Feel free to grab any ideas / code from it -- currently it is mostly just an expression evaluator, but it supports function calls (built-in and user-defined), and it supports an inline conditional like C, plus an iterative inline conditional -- so it can get by without an if/else or while/do statements.
But the code is designed to be embeddable, and if you want to you can rip apart the expression evaluator and integrate it into other interpreters.

yes COBOL and ADA (1)

josepha48 (13953) | more than 7 years ago | (#17475128)

ADA is still used by some goverment defense agencies also. It would be nice if there was a nice open source COBOL IDE. Funny thing is that all these new languages, fix issues that are not huge issues to most to begin with. I'm sure if someone made it easy to call web services from COBOL and made it possible to do OOP in COBOL it would be more accepted, but because it is a very primitive language people hate it.

Re:yes COBOL and ADA (1)

140Mandak262Jamuna (970587) | more than 7 years ago | (#17475208)

Way back in 1990, I had a friend who was a Grad Teaching Assistant in a business school. He was joking about how easy it is to get papers published by putting together buzzwords. He said, "If I say Object Oriented Cobol in the title, I can get it published". The next day he said, "too late, some one has already published a paper on OO COBOL". The idea is that old. For what it is worth, google finds: http://www.google.com/search?hl=en&q=%22object+ori ented+cobol%22&btnG=Google+Search [google.com]

OO Cobol since 1989! (1)

140Mandak262Jamuna (970587) | more than 7 years ago | (#17475358)

Went through scholar.google.com and found a 1997 abstract that claims that OO Cobol has been in developement since 1989. So it has been tried for a long time. But Cobol coders dont exactly take to OO like fish to water.

Re:yes COBOL and ADA (0)

Anonymous Coward | more than 7 years ago | (#17475336)

COBOL has been OOP for quite some time, and is fully capable of both calling WebServices and defining WebServices. COBOL is still under active development itself. The last COBOL standard, IIRC, was set in 2003.

And if you are now compiling open-cobol to play .. (1)

lysdexia (897) | more than 7 years ago | (#17475132)

Remember: columns 1-6 are sequence number, column 7 is indicator.

Go forth an set thy tabstop to 8 and you should be able to make your hello.cob compile! :-)

COBOL lives because it's clear (4, Insightful)

Gorm the DBA (581373) | more than 7 years ago | (#17475138)

COBOL lives, some 20 years after it's death had been predicted, and thrives. Why?

Because, it makes sense.

You don't have to develop corporate variable naming standards, coding standards, and all that, because the language makes it happen automatically.

You can take a fresh wet behind the ears kid, give him the code, and he can figure out what's going on without any significant trouble, because it happens in order, there is none of this fancy renaming variables on the fly and obfuscating code with magic numbers stuff that is all the rage in C++, Java, and other "modern" languages.

You want to add 2 and 2? Great, you get 4, which is what the accountants want. You can't program 2+2 to equal 27 like you can in C++. One operation does one thing, does it well and accurately, and moves on.

Business only has one real question: "How much money did I make last year?" COBOL provides all the tools to answer it.

That is why COBOL lives, and always will.

Re:COBOL lives because it's clear (3, Interesting)

ackthpt (218170) | more than 7 years ago | (#17475426)

Honestly. You have some points, but one of the greatest in COBOL's favour is it's pervasivness.

A few years ago I was working at a job where we were doing everything in a 4th Generation Language. We got outsourced (thanks to a CIO who just popped in for a couple years to pad his resumee) to a company which had an integrated product written entirely in COBOL. (Of course they ran their code on an HP platform, which by now has been retired and HP support will soon, also end. COBOL survives because people still develop and keep old business apps written in it. Some work, by code, never changes.

The other major advantage of COBOL is it's library for handling business computation and I/O. That stuff exists in other languanges, but as an example with Microsoft's Visual Studio, it's all done differently (and somewhat stupidly re-defining formatting for the nth time.)

Re:COBOL lives because it's clear (1, Insightful)

kfg (145172) | more than 7 years ago | (#17475444)

COBOL lives, some 20 years after it's death had been predicted, and thrives. Why?

Because people don't make sense.

You want to add 2 and 2? Great, you get 4, which is what the accountants want.

2+2=4 is APL, not COBOL.

Business only has one real question: "How much money did I make last year?" COBOL provides all the tools to answer it.

Well sheeeeeeeeeeeeeeeeeit! It understands the tax code? Why didn't you say so? I'm sold. Hire it as my accountant.


Not done much debugging in COBOL, have you? (1)

randolph (2352) | more than 7 years ago | (#17475690)

Chased a missing period, or dealt with an ALTER statement?

Now, the ALTER statement, at least, is probably history. I'm not so sure about the periods.

it's not "clear" (1)

oohshiny (998054) | more than 7 years ago | (#17475744)

Business only has one real question: "How much money did I make last year?" COBOL provides all the tools to answer it.

Well, if you use COBOL to code your web frontends, graphics, analytics, etc., the answer to that question will be near zero.

In order to make money these days, you need to do more than can humanly be done in COBOL.

there is none of this fancy renaming variables on the fly and obfuscating code with magic numbers stuff that is all the rage in C++, Java, and other "modern" languages.

C++ and Java are not "modern" languages; their designs are barely more modern than COBOL, actually.

Re:COBOL lives because it's clear (4, Interesting)

plopez (54068) | more than 7 years ago | (#17475806)

You can take a fresh wet behind the ears kid, give him the code, and he can figure out what's going on without any significant trouble

I disagree. I once was that kid. It is much harder than you imagine. Why?

1) Sphaghetti code. Lots and lots of sphaghetti code. COBOL, despite improvements, is still not much more structured than assembly. It was doing maint. programming in COBOL that I vowed in all future development to try to be kind to the maint. programmer.

2) The kid still has to learn the problem domain. I do not understand the mind set where a person says "I don't need to know the busness, just let me code it". With out the background knowledge you never know if what you are doing is right, reasonable, solves a domain problem or if it over laps another part of the problem domain so that code can be shared. In fact, learning the problem you are solving is the hardest part.

Re:COBOL lives because it's clear (2, Interesting)

COMON$ (806135) | more than 7 years ago | (#17476012)

It lives because people are unwilling to move on. There are plenty of languages you can teach any bum off the street in a matter of minutes, VB for instance. It is just like Gov't work, it stays the same not because it is efficinet and easy, but because people fight change at every corner. COBOL will stay around for another 15 years until all the COBOL bigots die off. No CS program teaches the crap anymore, at least not that I know of. In the meantime COBOL devs are the managers out there, it is the only thing they really understand and therefore as long as it is their fight, they will stay with COBOL. In 50 years we will be having the same argument about C++, probably worse because at least the old devs out there today knew how to think on their feet, whereas all these get rich quick programmers today attend a 2 year undergrad, or pick up a C++ for dummies and will climb the ladder pawning off the one skill they have.

Ya I am cynical but this is just the way the tech market works.

Ooh, I'm quivering in my rocker (1)

Ranger (1783) | more than 7 years ago | (#17475144)

and I can't wait for them to update FORTRAN. Oh, for the days of punch cards!

Re:Ooh, I'm quivering in my rocker (1)

lowen (10529) | more than 7 years ago | (#17475496)

They have. It's called Fortran95, and the GNU Compiler Collection supports it:
$ gfortran --version
GNU Fortran 95 (GCC) 4.1.1 20061011 (Red Hat 4.1.1-30)
Copyright (C) 2006 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

This is from a Fedora 6 installation.

I have a bunch (37MB) of highly specialized FORTRAN code out here; there are a number of scientific packages that still use FORTRAN code, because is works and the syntax for FORmula TRANslation is very simple and clean.

You can even do CGI with FORTRAN. (Yes, you can: go to the fcc.gov website and search for FORTRAN).

Code should not be modernized just for the sake of modernization, particularly when the language is not dead (and FORTRAN is not by any stretch dead). The heir apparent for FORTRAN would be Matlab (OSS equivalent is Octave).

Key Insight (2, Insightful)

TheWoozle (984500) | more than 7 years ago | (#17475146)

From TFA: "So, perhaps the real bottom line is that legacy reclamation isnt a second-class project for tired developers. It is an important part of your IT process and needs access to your best, brightest and most flexible brains."

If only such decisions could be realized in today's business setting. Unfortunately, updating/migrating legacy systems (even mission-critical ones!) seems to be the assigned task for interns, new hires fresh out of university, and contract programmers in India.

Re:Key Insight (2)

rk (6314) | more than 7 years ago | (#17475386)

On the other hand, let's be honest. Most mid and senior level people prefer to work on new systems versus mucking with a crufty legacy COBOL system. I know that if my job suddenly became COBOL legacy maintenance 100% I would be pounding the pavement looking for a new job, unless they also rented a Terex dumptruck, filled the bucket with $100 bills and dumped it out on my front lawn.

I don't mind taking a gander at a COBOL program once in a while, but I don't want to make a career of it.

Re:Key Insight (1)

kfg (145172) | more than 7 years ago | (#17475750)

Unfortunately, updating/migrating legacy systems (even mission-critical ones!) seems to be the assigned task for interns, new hires fresh out of university, and contract programmers in India.

Code written by someone who understood the problem, but didn't understand how to code; being migrated by someone who doesn't understand how to code, or the problem.

But at least the project is being managed by someone who actually has a degree in cluelessness, so it's got that going for it.

Head? Wall. Wall? Head.


Rewrite != Inefficient (3, Insightful)

mandelbr0t (1015855) | more than 7 years ago | (#17475174)

Every person I've met with writing talent throws lots of stuff away. They do it without a second thought, and the next attempt is almost always better. Why should writing software be any different? If the legacy is so bad as to be entirely undocumented and filled with back doors, work-arounds and pitfalls, what do you lose by rewriting? It's not like editing the crap code is going to be any faster or less error-prone.

In fact, there's many benefits to rewriting. It allows for proper documentation to be created (design diagrams, use cases, requirements documents) if it was missing. It allows for new technologies to be considered, and to plan for another 30 years of operation. If the software was created using a robust process, the design diagrams, use cases and requirements documents are already written. That's the hard part; any coder worth his salt should be able to exactly duplicate the application from those artifacts.

I don't think the risk is as bad as business types claim it to be. Is it really any more of a risk to "Rip and Replace" when it's at least as likely that either the ancient hardware that the application runs on fails without replacements being available, or that the one person in the entire company who actually knows all the stuff that should be written down in the non-existent documentation retires, and there's no replacement available? The article mentions in 2 of the 3 legacy reclamation techniques that a domain expert would be required. The fact that many of the domain experts are going to be or have already retired should be additional incentive to do the "Rip and Replace" while they're still available.


Re:Rewrite != Inefficient (2)

Lord_Slepnir (585350) | more than 7 years ago | (#17475284)

If you have a large code base already, rather than rewriting the whole thing, you should carefully refactor it to become whatever you need it to become. Joel Spolsky wrote a great article on it. When Netscape decided to spend 2-3 years rewriting Navigator from scratch, they lost 2-3 years, during which Microsoft Internet Explorer was able to assert itself as the dominant browser. By the time the new Navigator was released, it was too late. Now all that remains of the re-write effort is the Gecko engine that lives on in Mozilla.

Re:Rewrite != Inefficient (1)

bbockholt (543469) | more than 7 years ago | (#17475442)

I LOVE rewriting code! I have a garage FULL of wheel prototypes!

Seriously, rewriting is an essential part of maintaining software. It brings the code up to date, flushes out old bugs (and adds new ones, of course), and provides an opportunity to look at the entire project in a new light.

I would argue against a ground-up rewrite (ala Netscape) in most cases. But certainly revisiting and rewriting parts and pieces will be beneficial in the long run.

Re:Rewrite != Inefficient (1)

Prof.Phreak (584152) | more than 7 years ago | (#17475706)

Depends on time/benefit. Many ``old'' systems are big enough to prevent a rewrite.

My rule of thumb: If you can hack something in Perl in a week (or few) to replace a legacy app, go for it. If it takes longer, spend your time doing something more useful. If it's something that requires a -team- of folks working for a few months... then you better quit before you start (if old system works---just leave it alone).

Re:Rewrite != Inefficient (4, Insightful)

stretch0611 (603238) | more than 7 years ago | (#17475922)


The point is why rewrite something that works fine already. These COBOL applications work well now, some do have significant documentation, and believe it or not some (not many) have been rewritten (or just developed) recently.

Before you think I am clueless ponder this.
COBOL has a proven track record of over 40 years. Over that time is has matured and became very stable. It is reliable and quick.

Some COBOL Applications handle massive amounts of data that many servers would choke on. (Admittedly this is mostly due to the hardware architecture.) I personally wrote a program that would process over 35GB daily in about 10minutes. How many servers can process that amount of information? How many languages would you trust to deal with that quantity of information? Think of how much even the smallest memory leak in a language would be compounded with the sheer volume of data that we are talking about.

The Y2K crisis happened because programmers wrote programs that far exceeded the length of time they were initially expected to be used. 20 years ago, programmers used only 2 bytes for the year because they a) did not expect the program to be around in 2000, and b) memory and storage space required a premium price. For the most part it wasn't because they were bad programmer, they tried to be efficient programmers and the program lasted far better than they ever thought it would. Now a neophyte thinks it is a requirement to rewrite any program just because it is old(over 3 years). If you code haphazardly and do not think about future maintenance you may be forced to rewrite old code, but if you code with foresight you make the underly structure easy to maintain and upgrade.

The Y2K crisis also did one other thing. It made people re-evaluate their current needs and see if they were being met. The people who stayed with COBOL did so consciously. They made the decison that COBOL was fulfilling their needs or the programs would have been ported then (time permitting of course)

And yes, there is even new development with COBOL. The program I mentioned above with the 35GB of data was brand new and written in 2002. It processes returned billing information to AT&T from the LECs (Local Exchange Carriers) daily.

Now, I know someone is going to say that I am a biased old fart, but I am in my 30's, and the specific program I mentioned was my last COBOL program I wrote before becoming a Web Developer. The group I was with is still working with COBOL, but I moved on because even though it works well, I find writing COBOL too easy and monotonous. But the reliability, stability, and 40+ years of applications developed for it are why COBOL is still around and why it will still be around for a long time to come.

Re:Rewrite != Inefficient (1)

indifferent children (842621) | more than 7 years ago | (#17476024)

Every person I've met with writing talent throws lots of stuff away. They do it without a second thought, and the next attempt is almost always better. Why should writing software be any different?

Because that chunk of prose that your friend threw away didn't cost $40M to create. You might be correct that it will cost more to fix the $40M codebase than it would to start from scratch, but the managers who have to make that decision have a really hard time telling their managers that the old codebase has not only no value, but negative value. It's a tough sell, and then the uber-managers might ask themselves if they want to start a new, very expensive, project to create a new codebase that might also have negative value.

hmmm (1)

User 956 (568564) | more than 7 years ago | (#17475180)

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.

That sounds less like just plain COBOL, and more like a cabal.

The Tao of Programming (4, Funny)

symbolset (646467) | more than 7 years ago | (#17475182)

The Tao of Programming, 1:2 : [canonical.org]

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

From my experience (4, Interesting)

Dasupalouie (1038538) | more than 7 years ago | (#17475192)

I came out of school specializing in web development mainly with C# .NET and decided to go try COBOL in the industry and see what its like since no one teaches it in school anymore. Right now I am very happy that I decided to started going towards COBOL development. The code is very easy to learn, understand, and maintain (the sole purpose why the language was built, thus why they named it COMMON BUSINESS ORIENTED LANGUAGE). As the article said, almost all enterprise businesses use COBOL for data transactions and batch runs, its a skill easily transferable. And the language won't die, it's been 40+ years and I'm sure you can't replace the existing 200 billion lines of code.

COBOL is so old... (1)

creimer (824291) | more than 7 years ago | (#17475194)

Does any school actually teach this computer language? Have these "legacy" programs been running flawlessly for all these years? Are the programmers from the 1950's still around?

Re:COBOL is so old... (1)

thewiz (24994) | more than 7 years ago | (#17475428)

I learned COBOL in 1984 via a college course. I went on to use it at my first programming jobs (oil and gas company). COBOL is far from dead as it handles transactions, which banks deal with 24/7/365, very very well. Quite a few people I know who still do COBOL are in high demand and are paid extremely well for their services.

COBOL, if you didn't know, means COmmon Business-Oriented Language and was originally developed by a group of large businesses that wanted to make applications easy to understand and portable. COBOL is very easy to understand (How difficult is "ADD ONE TO ONE GIVING RESULT." to understand?) and is porting from one platform to another is a breeze compared to the nightmare of porting C or C++.

Now, pardon me, it's time for me to go back to the old folks home.

Re:COBOL is so old... (1)

Shadow99_1 (86250) | more than 7 years ago | (#17475462)

As of 1999 DeVry University taught COBOL in it's CIS program... I'm uncertain if they still do, but I am going to say they still do... Their program is geared toward the needs of the business community and (where I went to college in their network) that area hosts a bunch of large bank coporate headquarters and insurance company headquarters, so I figure it probably still does...

Re:COBOL is so old... (2, Interesting)

blk96gt (802791) | more than 7 years ago | (#17475510)

I had two COBOL classes, a 200 level and a 300 level, and this was in the past four years. The 200 level was mandatory, but the year after I took it was changed to VB. The 300 level was also changed to VB, and then changed back to COBOL, because some of the companies that come to our school suggested they keep a COBOL class. Surprisingly, I actually rather enjoyed COBOL, I guess because it was so easy to write.

Re:COBOL is so old... (0)

Anonymous Coward | more than 7 years ago | (#17475688)

The 200 level was mandatory, but the year after I took it was changed to VB. The 300 level was also changed to VB, and then changed back to COBOL, because some of the companies that come to our school suggested they keep a COBOL class.

What uni did/do you attend? This sounds dead on one of our local universities... unless of course this is a common thing.

Re:COBOL is so old... (1)

jwocky (900748) | more than 7 years ago | (#17475992)

They're around alright, trying to get retrained for new jobs.

When I was 23, fresh out of college and couldn't find a job I took classes for an mcse. The class consisted of me and 12 out of work cobol programmers. The lesson learned from this group of 50+ year olds is that NO language or os will be fashionable for the length of your career.

Two Points (4, Insightful)

Tom (822) | more than 7 years ago | (#17475226)

One, these figures result from the simple fact that COBOL was pretty much the only high-level language around at those pre-historic times many of the major applications were written. And banks are very, very conservative environments where something that works will not be thrown away for something that might have bugs, even if it's 10x as fast, easy to maintain or whatever. It has to work and that's priority #1, #2 and #3.

Two, the reason COBOL is so widespread in financial institutions has nothing to do with business sense and everything with business mind. It is "readable" to a business dude with zero computing experience. Something like "ADD PROFITMARGIN TO PRICE" just makes these people feel more at easy than "$price+=$p_margin".

A Modest Solution (2, Funny)

BigGar' (411008) | more than 7 years ago | (#17475250)

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.

Re:A Modest Solution (1)

Etcetera (14711) | more than 7 years ago | (#17475604)

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.

Sounds like a job for Parrot [parrotcode.org]!

Note: I'm kidding... sort of.

Easy tasks (5, Insightful)

kahei (466208) | more than 7 years ago | (#17475256)

This simply underlines the fact that there's a huge workload of easy, routine transactions that need to be done.

In terms of total complexity, the financial world is probably something like Excel 20%, C# 15%, Java 30%, C++ 30%, other 5%.

But in terms of transactions, I can well believe it's COBOL 70%, REXX/VB/4GLs 25%, other 5%.

Modelling a CDO *is* hard, and you don't do it in COBOL. Creating a visual system to monitor liquidity *is* hard and you don't do it in COBOL. 'Transactions' pure and simple are not hard... you can do them in COBOL... they're easy to maintain because changes are of the form 'deduct 5% if broker_country_of_incorporation = finland'... and they're also a darn silly way to measure the relevance of a language.

Why the community? (3, Insightful)

butterberg (1046750) | more than 7 years ago | (#17475280)

should the community spend more time building tools to make COBOL livable
Yes, Cobol is still around and probably will be for a long time. It has lived on the hardware of financial institutes for 50 years, and this software cannot simply be completely exchanged by an equivalent system written in a modern language.

But, does this mean that the "community" should help? Why should *I* build such tools, why should *you*? That's the problem of the financial institutes, and they are willing to pay large sums to get their code maintained and modernized in COBOL. And if they want to have a nice development tool, so they have to pay for it (probably indirect by paying a software development enterprise, which creates and then uses such a tool).

Nothing but geeky navel-gazing... (5, Insightful)

CPE1704TKS (995414) | more than 7 years ago | (#17475282)

Once you guys get jobs in the Real World, you will realize that businesses don't care about technology, they care about solutions.

No business person in their right mind would rewrite all their COBOL code into C or Java just for the sake of modernization. That would be foolish and stupid, and they would deserve to be fired from their jobs. Everything works, why change it. Financial institutions that have their entire livelihood based on these COBOL programs would rather upgrade their hardware and make THAT modern, but keep their legacy code. They already went through a multi-billion dollar fixing for the Y2K industry, that's more than enough for them. The next problem is either 2038 or 2050, when the Y2K issue is revisited because of how most companies implemented their "fix" (any date > 50 would be considered in the 21st century).

I was working at a bank during late 90s and during a building-wide Y2K meeting, one of the project managers was explaining to us how they implemented the solution. Someone in the crowd asked "Won't we go through this problem again in 2050?" He answered "Yes, but I'll be dead then, so I don't care."

That is how business people think... they care about solutions, they don't care about technology. Don't waste your time navel-gazing and trying to figure out brilliant ways of modernization COBOL, because no one who uses it cares. Keep your great ideas for the new ideas where the barrier to implementing new solutions and new technology is much lower.

Re:Nothing but geeky navel-gazing... (1)

lysdexia (897) | more than 7 years ago | (#17475970)

Wow. I guess we've just been schooled.

Despite the fact that it's hard to hear you from atop thy high horse, I believe you are speaking true trueisms. However, speaking as an unwashed hippie, I cannot agree with the usage of the term "solution" when describing the temporal logic fix added to these sorts of systems. That is known as the "Fuck-You Forward Fix" (Pronounced 'Fife' as in Barney). Nothing was 'solved' by dumping this dungheap upon the heads of future coders (`though I'm sure the mgt types are thinking only about future mgt types, if at all). It was a crutch. A very expensive flying butress on your cash cathedral with a very definite expiration date.

This does not say that it is the wrong fix for the business' financial state, the business climate and/or time pressure. I sympathise with the money-men. I've committed such boners myself in my own business for whatever reason ... However, half-assing is half-assing and attempting to cover the half-ass by inverting your whole ass with your mouth (i.e. blathering on about "the real world") does not render a 'solution'. If we are going to abuse chemical terms, perhaps we could call this sort of thing a 'suspension', as it is going to settle out eventually.

I hereby nominate "deserves to be fired" to the 'invoking hitler' list of thread-killers.

Wordy (2, Insightful)

ackthpt (218170) | more than 7 years ago | (#17475288)

The problem I had with COBOL, PL/1, Pascal and Modula 2 were they were wordy.

A lot of typing to perform simple operations. This is why I like C, minimal typing for great power.

More or less works for Java and later languages, too.

Re:Wordy stupid (1)

cinnamon colbert (732724) | more than 7 years ago | (#17475712)

Show me some real world data on TCO including lifetime maintenence that terse programs, which saved a few minutes of typing for the programmer, are better then wordy programms whihc save years for the non original authrs that have to maintain

this less typing thing is one of the stupidest memes in the computer industry

Frank Lloyd Wright (2, Funny)

dildo (250211) | more than 7 years ago | (#17475374)

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.

I am 56 years old and would love to learn COBOL (1)

BrentRJones (68067) | more than 7 years ago | (#17475394)

I am 56 years old and would love to learn COBOL, if it means that I can get a better paying job.

Obviously, COBOL works. In fact, if statistics are to be believed, then it is perhaps the most successful of all computer programming languages.

Why replace what works? In fact, why do employers always want to replace me with someone younger and cheaper and not necessarily more gifted?

Never trust anyone under 50 should be my sig line.

Re:I am 56 years old and would love to learn COBOL (0)

Anonymous Coward | more than 7 years ago | (#17475618)

I bet back in your day people cared when you talked, huh?

Re:I am 56 years old and would love to learn COBOL (0)

Anonymous Coward | more than 7 years ago | (#17475724)

Why should "trust" be based on age at all?

Re:I am 56 years old and would love to learn COBOL (1)

BrentRJones (68067) | more than 7 years ago | (#17475830)

You are too young to remember the line: "Never trust anybody over 30" this was in the 60s

Re:I am 56 years old and would love to learn COBOL (1)

Dasupalouie (1038538) | more than 7 years ago | (#17475786)

But I am 21 and im going to replace you :p
Its good you pointed out that issue about age. Sooner or later there is going to be a mass shortage of legacy developers out there, the average age for a COBOL developer is in the 40 range and they will have to retire sooner or later. There is only 1 or 2 specialized institutes in the country here that teach COBOL, what I've been learning so far has been through mainly experience with testing COBOL and reading online IBM manuals.

Re:I am 56 years old and would love to learn COBOL (1)

BrentRJones (68067) | more than 7 years ago | (#17475888)

I hope to code until I reach 80. You have about 60 more years to go.

Good luck to us all!

Re:I am 56 years old and would love to learn COBOL (1)

jshackney (99735) | more than 7 years ago | (#17476068)

Why replace what works? In fact, why do employers always want to replace me with someone younger and cheaper and not necessarily more gifted?

Check out the aviation industry. There's always someone willing to come along and do my job for drastically less money. The bad employers only care about the bottom line, not quality, safety, etc. The good employers that actually give a $#!& have ridiculously low attrition rates.

I worked for a company that used (actually, they still use it) COBOL. Their MO was to scour the state universities for bright kids, bring them back and teach them COBOL. (As a sidenote, we also used OS/2 extensively in the development area.) Well, anyway, these kids were typically coming out of college (about 1996/7) making 45K per year, and by the third year, they had moved on from being burned out.

The community (1)

kaoshin (110328) | more than 7 years ago | (#17475406)

Considering the vast majority of the community hates COBOL with a passion, I think it would be easier to get together a group of people who want to promote (insert your favorite band's name here) latest album.

COBOL is dominant because no change is required. (4, Insightful)

kiwioddBall (646813) | more than 7 years ago | (#17475408)

The reason there is so much legacy code about is because that code has been around for some years, is proven and is bug free.

The slashdot article assumes that because of this the code may benefit from change. In fact the exact opposite is the case. Change introduces bugs and costs money, so I cannot see this happening.

Why? (4, Insightful)

Kjella (173770) | more than 7 years ago | (#17475520)

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.

I mean, it's only big (huge!) corporations running big back-ends that use COBOL, why should "the community" bother much with that? I doubt it's anyone's itch to scratch. Customers want to run COBOL because the code has had decades of real-world production use, not because of COBOLs merits. If the same people still ran assembler code, I'd trust that too. Doesn't mean I'd like to give up on modern languages because of it. If I heard the words "legacy modernization", I'd think "don't break what works". Doesn't mean big new developments are made in COBOL, they interface it.

I'm almost convinced that COBOL will be running on systems a hundred years from now. Any Turing complete language could produce working code to solve anything (or well, as much as any other Turing complete one, anyway). Clearly there's some such code in COBOL, which it makes no sense to reimplement in another language just for the sake of reimplementing it. But I don't see the benefit of trying to revive COBOL development, there are now much better tools for the job. How long has it been since the term "Completely Obsolete Business Oriented Language" was coined? It's dead, Jim. The only tools needed are those to ease its passing.

No emotional motivator for COBOL (1)

cryfreedomlove (929828) | more than 7 years ago | (#17475574)

90% of transactions happen through COBOL? Is this supposed to make me want to programin COBOL?

Sorry friends, but I have to work on code that matches my passion. Otherwise I would not be able to swing my legs out of bed in the morning and live my life with joy. Some people may be making a living with COBOL but none of the cool kids (myself included) will touch it.

Re:No emotional motivator for COBOL (5, Interesting)

Rastl (955935) | more than 7 years ago | (#17475982)


Sorry but I had to let that one out. "Code that matches my passion." is priceless.

When you start looking at a mortgage payment, car payment, grocery bill, doctor bill, etc. you'll realize that you work on something you can do well. Save your passion for your hobbies. Code on the bleeding edge at home.

Do you honestly expect business to conform to what you want to do instead of what works for them? Answer truly. And if you don't come up with "Heck no!" you need to rethink how it works.

Sure COBOL may not be for you. Good deal. Don't learn it. But if you're applying for a job and they need LegacySystem 5.7 and you tell them you don't know it, won't learn it, but would consider writing in BleedingEdgeSystem 0.54 you can pretty much figure out what the answer is going to be.

I've been coding since 1976. Yes, 1976. I've learned many languages. Some I've liked, some I haven't. But if the business needs it I learn it. Sometimes I learn it just because I want to. I missed out on COBOL (don't ask) but may just add it to my list of things I want to investigate.

I'm not being a troll or at least I'm not trying to be one. Some people will probably read that first exclamation and not go any farther. But sometimes you really do have to wake up and smell yesterday's coffee burning in the pot.

COBOL certification (1)

WiseMuse (1039922) | more than 7 years ago | (#17475668)

I've got certification in COBOL. I remember clearly learning the language with punchcards. I liked it that way. COBOL should stay the way it is. We should return to the good old days of punchcards.

What COBOL has that other languages don't. (5, Interesting)

Animats (122034) | more than 7 years ago | (#17475682)

The big advantage COBOL has is that the language is serious about data storage. The language knows about structured files, databases, indices, and formatted fields. COBOL was the first language to have data structures.

Look at what a mess it is to talk to a database from Perl, Python, Java, or C/C++. There's fussy glue code required, and the language doesn't help you make sure that field XYZ in the database comes out as field XYZ in the program. In COBOL, it's straightforward. The language knows about databases. There's even a good interface to MySQL. [www.rldt.fr]

It also has some formatting capabilities that HTML should have had. You can write CREDIT-CARD-NUMBER PICTURE 9999-9999-9999-9999. In some systems, that will eventually result in an input field on a green screen that will only accept four fields of all numbers with all digits filled in and will display a blank form field accordingly. HTML FORM fields should have worked that way.

There are some real advantages to a language where components outside the individual programs can see, check, and use the data declarations.

Re:What COBOL has that other languages don't. (1)

randolph (2352) | more than 7 years ago | (#17475912)

Bingo. Bookkeeping and accounting are the mainstream of COBOL, as they are in no other language, though of course they can be done in other languages. If you want to do bookkeeping arithmetic to four decimal places (the standard for financial calculation in many institutions), COBOL is still the easiest tool. (And if you doubt those are valuable, ask yourself how many penny errors you are willing to accept in your bank statement.) Now, the language was (and probably still is) heavy with complex syntax. It used to be absurdly hard to compile, and had some awful syntax and semantics, which probably still occur in some programs still in use, somewhere. I can easily imagine compile-time switches that turn off the old features. But its best features have not been captured in any other language, and so it goes on.

Why Businesses Use COBOL (1)

littlewink (996298) | more than 7 years ago | (#17475686)

  • COBOL has fixed-point math. All math operations including rounding follow financially-accepted standards,
  • COBOL uses fixed-length arrays and strings,
  • No dynamic memory allocation is allowed,
  • No dynamic (self-modifying) code is allowed.

The last three items make COBOL memory- and CPU-efficient. The programmer is limited in his options, but these restrictions also gracefully limit coding complexity. Portability is simplified with this restricted feature set.

A side-effect: COBOL is an ideal language for WWW applications because of the above restrictions/features. COBOL is the original WYSIWYG language.

There are companies that help with this- (3, Informative)

bishiraver (707931) | more than 7 years ago | (#17475694)

One such company, Envyr Corporation [envyr.com] (makers of iCobol), builds a solid windows-based IDE for COBOL. Their compiler supports many different architectures - AIX on RS/6000, DG/UX on AViiON (though, newer versions aren't supported on this platform), HP-UX on HP Series PA-RISC 1.1, Intel RedHat (above kernel 2.2 for newer releases), SCO (yeah, yeah, I know). They also support the full line of Windows OSes, though older versions like 98, NT and ME only have basic testing performed on them.

They provide tools for transitioning from older Data General COBOL to newer OSes (Windows, RedHat).

Interesting thing also, is they provide a cgi platform for COBOL.

They also provide various APIs for C to interact with the COBOL program you have, services for code migration, etc etc.

The company is run by several ex-Data General employees, and they really know their stuff.

Disclaimer: I do not work for Envyr Corp, but I have family that does.

Let the user choose (0)

Rildo (1047364) | more than 7 years ago | (#17475748)

If the programmers and/or managers still think COBOL is useful, why not let them deploy its applications. If COBOL has survived it is only because it is relevant, or make easy to understand its legacy systems. It is well standardized by several organizations and have several commercial and free implementations. Compare for instance Java, which IS NOT standardized yet, have a few (SUN alone is the standard) implementation, and is a moving target!

If I would choose a language to port COBOL applications, I would prefer Common Lisp. That's because I like it. It gives me control and power. There are many things impossible to do in Java or C++ (and COBOL too) that's easy in CL (real macros anyone?).

Of course, for business applications, or better saying, for the junior programmers that are able to write COBOL or Java code for finnancial applications, Common Lisp is a nightmare with its complex concepts. For a seasoned programmer, there are, along with CL (Common Lisp), a handful of other interesting languages such as Ruby, Tcl, Python, and others.

But remember, there are tricks in COBOL that no other language (except CL, of course, that may implement the syntax you need) which features a MOVE (with type conversion according its PICTUREs), MOVE CORRESPONDING, a precision "money arithmetic", several verbs like INSPECT, STRING, etc. People get used to work with those features! That's why COBOL still lives and will live for much more time than you Java-only programmers (Java morons) expect.

In Brazil there's a saying "don't change a team that's winning".

BTW, I'm NOT a COBOL programmer, but I'm a proud implementor of TinyCOBOL (http://tinycobol.org/ or http://tiny-cobol.sourceforge.net/ [sourceforge.net]), a free (GPL, libraries LGPL) COBOL compiler that peaked 4,000 downloads/month. I prefer to write my code in Tcl, Common Lisp (including CLOS, its object system), Prolog, C (not C++, which is ugly), yacc/lex/ox (compiler tools), TeX, Postscript, Smalltalk, Forht (I've implemented a derivative of it called "Filia" in the early 70's), and othe less known animals...

Rildo Pragana -- "Adventures in Linux Programming" http://www.pragana.net/ [pragana.net]

My gramma used to write code in COBOL (1)

extern_void (1041264) | more than 7 years ago | (#17475906)

If a code has to be re-written (or in this case the own language COBOL) it is time
to switch it by another and modern language.

Everything is evolution, except my score that keeps on 0 indefinitely:)

COBOL migraton nightmares (1)

thinkingpen (1031996) | more than 7 years ago | (#17476020)

I worked with a company that had most of their IT systems on an old mainframe written in COBOL and assembler. We had to migrate a few programs to use DB2 (relational) database instead of IMS (an old hierarchial database). This proved to be a nightmare due to lack of tools to analyze COBOL source code. We had to write REXX scripts to parse the code and automate some of the process. In another project, a variable had to be expanded (in terms of lenght), and another nightmare followed. More rexx to track where this veriable goes, what it is used for, what files it gets written to .. well this part involved parsing JCL files as well using rexx! Yes, we need better (mainframe based) tools to make this language livable with.

uh, what? (0)

Anonymous Coward | more than 7 years ago | (#17476044)

seems it's already quite 'livable', considering its stated dominance in some applications.

Why use COBOL? (1)

wardk (3037) | more than 7 years ago | (#17476072)

geez, it's not riddled with bugs, has a stable development environment, stable kit of tools.

it just works.

unlike what, ALL the rest?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account