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

[NewWorldDan]

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

[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

[rbanffy]

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

[jrockway]

Java is popular because strong typing prevents bad programmers from being stupid. If your application is designed by one intelligent architect, most of the coding can be done by code monkeys without causing too much damage (especially if the architecture team writes good automatic tests). With PHP, the code monkeys are going to make a mess. The compiler won't tell them that you can't return strings from functions that are supposed to return integers, etc. If it compiles, you know they're going to ship it. Java does strict checking and won't let people screw things up too badly.

OTOH, if your team is a bunch of good programmers, though, then Java's probably not a good solution. Use something like Perl or Haskell and everyone will be much happier. When you have people that know how to properly bend the rules and understand the consequences, Java is too constraining. (Which is why I use Perl for my personal projects. Wonderfully expressive.)

Re:Easy Solution

[NewWorldDan]

Actually, it's been my experiance that if you wait to relese When It's Done, it'll never be done. At some point, you have to hit the ground running and work with what you've got. That's actually how a lot of those old COBOL systems were built. They got to around 95% and found out what all the odd little business rules needed to be by actually using the system. That's what makes legacy projects such a daunting task; the core application isn't too difficult, it's 30 years of business rules that are embedded in the code (and no one knows what they are, where they are, or even why they're there. But when they dissapear, you find out about them fast).

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.

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.

Re:But it is modern!

[jaavaaguru]

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

Fujitsu COBOL and NetCOBOL for .NET
Micro Focus Net Express

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, 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.

COBOL lives because it's clear

[Gorm the DBA]

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

[ackthpt]

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

[plopez]

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

[COMON$]

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.

Re:COBOL lives because it's clear

[neimon]

THANK you. I realize that an entire two generations of programmers have been brainwashed into thinking that the process is the first deliverable in a programming job, but a lot of us older guys think that, gee, we should plan how the thing works and freakin' program it, not argue over how this method and that inheritance goes here.

You think people didn't know how to program in the past? Read about how programmers used to optimize the placement of their code on drum storage to take into account the latency of reads.

Too much about HOW to program, and not enough about actually getting something done, is what I've seen over and over and over. Style style style. Working code is only a byproduct, and who cares if it's error-checked or idiot-proofed? We've got Objects, dammit! Look! Look! We did it all tidy! ANd we used the latest silver bullet!

Maybe we should take some of the lessons of the past and look at our current tools and say "hmm, you know, we could probably rethink all of this and make it easier instead of harder."

Sorry. End of rant. I'm old. (gums his boiled chicken in the corner)

Re:COBOL lives because it's clear

[dimeglio]

COBOL is such a deceiving language. When I was young, and this is a true story, I went to libraries as I was very interested in computers (early 70s). I pulled out this illustrated book on computers where they showed bits of code here and there. I saw this wonderful line:

MOVE INVENTORY-IN TO INVENTORY-OUT.

WOW! I say to myself... robotics! COBOL is able to control robots by moving inventory. I signed-up for three years of Data Processing only to find out that it in fact only moved data from one part of memory to another... I was very very disappointed.

I bet you that's why COBOL is so popular. By being so verbose, it attracted massed of kids on false promises of what appeared to be the ability to control robots. That would never happen in C or Java.

Key Insight

[TheWoozle]

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

[rk]

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.

Rewrite != Inefficient

[mandelbr0t]

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.

mandelbr0t

Re:Rewrite != Inefficient

[Lord_Slepnir]

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

[stretch0611]

mandelbr0t,

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.

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

Comment removed

[account_deleted]

Comment removed based on user account deletion

Two Points

[Tom]

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

Re:yes COBOL and ADA

[plopez]

I'm sure if someone made it easy to call web services from COBOL

I believe WebSphere does this. Supposedly you can pump COBOL data into EJB applications.

see:
http://www-306.ibm.com/software/data/ims/imsjava/j avcobol.html

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.

Easy tasks

[kahei]

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.

Lords of COBOL...

[Lemming Mark]

...hear my prayer!

Why the community?

[butterberg]

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

[CPE1704TKS]

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.

Wordy

[ackthpt]

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.

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.

COBOL is dominant because no change is required.

[kiwioddBall]

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.

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.

Re:COBOL is so old...

[blk96gt]

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.

Why?

[Kjella]

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.

Re:'legacy modernization'

[nuzak]

ABEND: Syntax error.

You forgot the period.

What COBOL has that other languages don't.

[Animats]

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.

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.

There are companies that help with this-

[bishiraver]

One such company, Envyr Corporation (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.

Re:It has been said...

[lowen]

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

[StarvingSE]

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:No emotional motivator for COBOL

[Rastl]

Bwahahahahah!!!!!one!!

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.

The lords of Kobol

[goombah99]

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

UTTER Nonsense! COBOL is glue language in a stack

[scottsk]

Sorry, but I have to rant: Whoever wrote this has no idea what they're talking about.

COBOL is the glue language in a stack of application components sold by IBM including CICS (or ISPF), VSAM, DB2, etc. These are quite modern and up-to-date, and run on the mainframes that make the world go around by providing reliability and uptime at load levels beyond the wildest dreams of PC and Linux users. Sure, anyone could learn COBOL basics in a day or two, but you're not going to learn and certainly not going to "modernize" a COBOL program running against a DB2 database. COBOL is a glue language that glues together high-performance relational database access, high-performance presentation-layer management (CICS makes Windows API programming look simple!), etc to process umpty transactions per second, where umpty is a number beyond the reach of most Linux boxes. You're never going to "modernize" this stuff because it's the only thing around that can do what it does at that throughput level. The COBOL part is just a driver among the different components. Even the business logic has been factored out into stored procedures now.

There is no problem bolting on web access to databases and data warehouses, or stuff like that, but whoever wrote that (imagine that, a consulting group who will come in and modernize everything for you!) has absolutely no idea what COBOL applications are or do. You are most definitely not going to port legacy applications to new platforms that use CICS or ISPF for their presentation layer! Get a clue. And what platform are you going to port your COBOL program to? The mainframe is already the highest end platform of all time - there's nothing with more throughput - I doubt a company would take the notion of porting to MySQL on an Intel box very seriously. The bottom line is people use the IBM application stack because it works, at a performance level where nothing else works.

Sure, it would be fantastic to have an open source COBOL compiler with a MySQL precompiler so people could learn the language (ever tried to parse COBOL!?). And a Mono COBOL compiler would be fantastic. But no one is going to port their mission-critical business applications from a mainframe to a virtual machine runtime environment. You might use C# or Python to create new apps to access the data in new ways, offline, but you're not going to port mission-critical stuff.

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? ;)

Fortran updated each decade

[peter303]

77, 95, 2003
(I skipped the 80s too.)
Like all the legacy languages it acquired all the new fad constructs. Still pretty conscise for formulas and array operations.

Cobol and research community

[freddieboogiewoogie]

The software engineering research communities have been aware of the problems (decreasing number of developers, hardcoded business rules, required integration with other systems, ...) tied to legacy software systems, and there's still active research going on in these areas.

<shameless plug>
In our research group e.g., we're evaluating aspect-orientation (AOP) as a means to both reverse-engineer (understand) and re-engineer (modify) legacy software written in Cobol or C. To this end, we've designed and implemented an aspect language called Cobble (http://faramir.ugent.be/~kdschutt/cobble/) and applied it on some typical legacy problems like Y2K, transition to Euro, encapsulation of web services, ... (see http://allserv.ugent.be/~badams/publications/2006/ ao4vittel.pdf). Similar work is done for C (http://users.ugent.be/~badams/aspicere).
</shameless plug>

Now, the biggest problems we encountered for Cobol (contrast this e.g. with the Java world) were:

• dozens of existing Cobol dialects coupled to the sheer absence of open source Cobol software (to experiment with)
• lack of a decent (free) IDE or some other infrastructure to start tweaking
• lack of an unambiguous Cobol parser
• Cobol's sheer unlimited number of features

Eventually, we had to implement our tools from scratch, tied to a subset of one particular Cobol dialect. This severely reduced the time for actual research. So, Cobol is not so simple as it may seem at first sight and this is aggravated by the limited (compared to Java, C#, ...) available tool support.

AAAAH!

[gers0667]

Oh please, god, no!!!

I started my professional programming career in 1999 by doing y2k conversion on an s/390. Millions of lines of COBOL. All my friends at college had the cool jobs of C++ GUI's and Java web apps. Even the professors laughed at me when I told them what I was doing. Do you know strange it is to work on code that was last updated 9 years before you were born.

In all seriousness...

I can understand why COBOL is still popular now. From my experience, most major companies made a big technology leap a long time ago, investing millions in massive mainframes to run the company. These systems are still held up and run by their aging staff. (I was 17, the next youngest programmer was 50+). These systems get so massive and complex, "modernizing" is just another word for rewriting.

I suppose 20 years down the road, we'll all be complaining about legacy java systems. 50 years down the road, legacy ruby systems.

Re:Not done much debugging in COBOL, have you?

[FlyingGuy]

Ever chased an else'less IF or a Case where someone forgot to put a "break" in C ?

Ever chased a very subtle bug in C++ where some moron overloaded the wrong operator?

Ever chased an End statement in Pascal where a ; was optional?

Ever chased a ... in any language?

The bottom line is this. Every language has its pluses and minuses. COBAL was designed as a language to handle business operations. It does it well, it does it faithfully and its Proven, Tested, Validated an most of all Trusted (PTVT).

Ask K&R if they think C is a good business operation language, I bet they would reply in the negative.

As to other languages...

• PHP - Wouldn't trust it, it hasn't been around long enough to be PTVT
• Java - Not only no, but fuck no!
• Perl - Not on your {[^/b/n-n]=--} life!
• Ruby - Again not PTVT
• C# - Again, not .PTVT
• Lisp - Question Ask you would why do this?
• ADA - Although this language IS PTVT, it would be ill-suited
• FORTAN - Only if I was sending my bank ballance to Mars, but it is PTVT

The bottom line is COBAL was designed to do exactly what accountants and business need. Its been extended, but the basic functionality that it was designed to do is all still there.

If you don't like the wordiness of COBAL I can understand that, brevity has its place, so go spec a "modern" business transation orineted language, work the bugs out for about 30 years and I am sure banking will adopt it, provided it runs on an IBM Mainframe, since there is simply no way you are gonna handle the transactions on 400 million bank acounts in less then about 6 hours the way BofA or Wells Fargo does, night after night, after night.

Its one thing if your mashup of Perl, Python, Ruby on a rocket sled and javascript all come flying apart and someone cannot read Slashdot for a few hours or someone cannot place an on-line order for a while at Amazon. But just have several thousand ATM's go bonk because the Linux Cluster lost its mind or something like that so that people can't get cash, or make a deposit and see just how fast everyone comes after you with Tar, Feathers and a pitchfork!

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.

It's the enviroment, not the language.

[natoochtoniket]

The problem with all of these modernization projects is not the language. It is the mass of old data, and the huge mass of business rules that are implemented by the old code. Reimplementing the business rules in new code, without interrupting the business, is just about impossible. Turns out the easy way is usually to just port the old Cobol code to the new environment.

The problem is not the language. The problem is the environment. Consider: A lot of that old Cobol code presently runs on Autocoder 790 systems, which are run by emulators on an OS 360 system, which is run by an emulator on a 390 series "mainframe", which is run by an emulator in the old Sun box that gathers dust in the corner of the old data center.

We really don't need a new language. What we need is something like a Cobol compiler, with an ISAM file-system emulation library, that outputs code for a well defined machine such as a java virtual machine. Then the resulting executables can run on whatever box happens to be handy next year.

This is either funny or insightful. Maybe both.

Re:'legacy modernization'

[TheCrayfish]

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

Huh? How does this comment apply to something abstract like a programming language? The COBOL language didn't degrade over time, yet somehow everyone's perception of it went from "this is the tool we need to use to do everything" to "please let it die."

Like every other widely-used language, COBOL has its place. You might not want to write a video game in it, but you also wouldn't want to write a billing system in C++.

Re:It has been said...

[Lord Bitman]

good design and documentation.. or code for that matter.
How do you intend on building a replacement for a system that:
1) Is ancient and pretty hard to understand to begin with
2) Has no source code
3) Can never, EVER be turned off
4) You don't specifically know the function of
?

You can either keep using what it was originally built with (okay, not "no" source code, but very little remains)
Or you can add "and is written in very dissimilar and unrelated languages"

Often the best way to "just start using" a better language is to "just start using" a completely separate system, and a propagation tool.
-> which of course leads to "Oracle is slower than our VSAM files! We can't use this!"

I caught the tail end of a talk someone was giving about modern COBOL and how mainframes were becoming more and more relevant (delivered by a hip 19 year old to a room full of 50 year olds) I don't remember specifically what innovation was being talked about, but I think it was along the sophistications of a foreach loop
It was sad.

Re:yes COBOL and ADA

[T.E.D.]

I notice someone has already corrected you on the proper capitalization of Ada. It seems a silly thing to get sensitive about, right? But there's a good reason it gets folk's panties in a bunch. For one thing, it is nearly always done by someone who doesn't know a thing about the language, doesn't care to know a thing about it, and wants to be able to dismiss it (without getting into messy details, like its actual qualities).

That would be enough to annoy many people by itself. Additionally, by capitalizing it you are implicitly categorizing it with older acronym languages like COBOL, FORTRAN. PL/I, rather than its proper contemporaries like Modula-2, Oberon, Java, etc.

That's in terms of age. In terms of use and philosophy, probably the closest language to Ada that most folks here would be familiar with is Java. They both had the same design goals of safety, readability, and reliability. The main difference between them is that Java's designers thought that C-style syntax's marketability outweighed its readability drawbacks. Most of the other differences between the languages are in emphasis.

Anyway, I think you can probably see where Ada users would get a little ticked at someone trying to dismiss it at an ancient COBOL-like language. Try talking dismissively about "that ancient language JAVA", and see what kind of responses you get.

COBOL+VB

[dtfinch]

Some of the scariest shit I've ever seen. The old parts are written in COBOL, a pile of over 4000 scripts with 6 character filenames that work together to form an ERP system. It originally used flat files to store records, with multiple record types in each file. At some point they managed to upgrade to a real database server without significant code changes, which means multiple record types, with completely different fields, in each table. It updates database records using the ever popular "delete and reinsert without any atomicity" method, occasionally (dozens of times) deleting a major customer's records because it crashed while updating them. New parts of the ERP system are written in VB6, and store much of their data in Access databases, despite that there's a perfectly good database server they could use. At one point I wrote a script to monitor one of the Access databases and backup and repair it each time it became corrupted.

Re:It has been said...

[theshowmecanuck]

Most of the software rewrites I've seen are done not just because the body of code is dysfunctional, but because the design and implementation are out-of-touch with modern principles and techniques.

You may be in touch with modern software principles but sadly you are out of touch with business principles. Ideology does not make a company money. And a company is about making money not writing code conforming to modern code design.

To make a business case for code change, you need to back up your reasoning by showing how it will either 1) save the company money within 5 years or less (including paying off all the money spent for the code upgrade which at large companies could run into hundreds of millions of dollars) or 2) earn more money for the company (including paying for the code changes) within 5 years or less. You could argue that these are the same things but I look at them differently as one causes earnings to increase indirectly through savings, and the other directly though increased revenue.

If you can't do either, then forget it. If you don't understand why, think about where your paycheque comes from and how the company is going to be able to afford to pay you to work on no-gain projects. If you don't want to understand why, then stay a coder... not even an analyst, stay a coder. You must justify the costs of these kinds of expenditures. Now it is possible and even likely that someone was able to justify the costs of fixing design issues on projects you worked on. However, in corporate life, wholesale 'fixing' of 30 or 40 year old stable code is not usually justifiable for design sake alone.

For example on on projects I have worked on where large companies have modernized their systems (often replacing Cobol code) it always involved monetary reasons. Many times Cobol systems are built on other Cobol systems, which are built on other Cobol systems... Business domains begin crossing back and forth across system boundaries and things (for example customer service) become a nightmare. Take a customer order management process: Customer wants three things, it might take three systems to order it, two different customer service reps, and if something goes wrong, support has to track things across 3 systems. If you want to create a new product package it takes too much time to coordinate between systems and one or more might need programming changes which might mean data conversions if the interfaces change between the systems, etc. If the pain threshold gets to high by holding back the company in effectively competing because their systems piss the users off, piss the customers off, and hold back introduction of competitive products (in other words, if it is costing them more money keeping the old system than replacing it will cost), then they will consider replacing the old systems.

Since we are talking Cobol and financial transactions, we are talking *mostly* about the corporate world. When you are talking about large corporations, the cost to replace even an ordering and billing system can run well into the hundred million dollar range or more. Tens of millions is not uncommon either. Projects in the million dollar range are a dime a dozen in the corporate world.

Note: I don't particularly like Cobol... actually I don't like it period (I like C/C++/Java syntax better because I understadn it :-). But for me to justify something to a customer, it must solve a customers problem. The first thing to remember is their main problem is how to make more money. Period. It is not about supporting good code design. They could have something in place that was the worst coding job in the history of the planet, but if it makes them money it won't matter. Unless of course you can show them in concrete terms that a good design will pay for itself by directly or indirectly making them more money.

Object-oriented COBOL on the Java Virtual Machine

[dazedNconfuzed]

Just to twist knickers, there's Object-oriented COBOL running on the Java Virtual Machine.

Re:It has been said...

[mrmtampa]

"COBOL is hands down the worst language in common usage today"
Why? Do you have some facts that support your position?

IMHO, as a business oriented (that's what the B stands for) procedural language COBOL is at the top of the heap. COBOL, coupled with top-down structured coding techniques has produced some of the most bug free and easily maintainable code around. That's why it's still running. Think about it every time you stick your plastic into an ATM.

Maybe your problem is with procedural languages in general. When I look at the OOP extensions to COBOL I cringe. But I felt the same about C++. [flame bait]How in the world did C++ gain favor over Objective-C?[/flame bait]

You know....

[Shads]

... I can program in C/C++, Pascal/Delphi, Java, VB/Basic, Perl, a bit of Ruby, Python, and several shell scripting languages/applications like sed/awk. I find cobol to be the most obnoxious pain in the ass language I've ever used. I had to take two semesters of it in college and I hate it. I hate it just like I hate RPG. They're underpowered, obnoxious, and annoying to work with. Screw cobol, screw rpg. I'd sooner bag groceries than program in either language.

Re:Not done much debugging in COBOL, have you?

[FlyingGuy]

Alternatively, you can begin teaching programming as a trade, much like plumbing, construction, etc.

Programming business processing is neither exciting, nor particularly fun, but it is however a pretty good way to make a living. You dont need the chops of someone who can write a TCP stack or a Kernel or a new Compression or Encryption algorithym to do so. What does it really take to say calculate the interest on someones savings account and post it to the acount transaction file, not much programming wise. There is no parsing involved, no tokenizing, nothing fancy at all.

I make a decent living writing custom applications and I rarely do anything very complicated. I write nice custom apps in Delphi, mostly against Oracle. Nothing earth shattering in the GUI, I stick to the basic control set and they just hum along either on windows or Linux ( Kylix ).

Business operations production coding can be tought to just about anyone with a logical mind that can understand the concepts of data flow, which as many have pointed out, things like VB, Delphi and the like support very well, even if they are pourly coded by people with no formal training.

Someone with business background ( mine came from banking and healthcare ), that can understand the concepts of programming in a logical progression to get from point A to point B can be trained in a given language like COBOL or TCL in a matter of a few months, possibly less, and can then function confidently in a business transaction production environment.

I went further and taught myself most of the very low levels of SE by reading many many books and experimenting. Programming anything is no magic, it is understanding the interaction of software with hardware. The first really difficult thing I ever wrote was an interupt driven serial I/O processor, back in uhmmm, around 1985, I wrote in a combination of 8086 assembler and Turbo Pascal 3.1.. Hmmm I think i am getting old.

I dont have a degree in anything except hard work and study.