Why COBOL Could Come Back

snydeq writes "Sure 'legacy systems archaeologist' ranks as one of the 7 dirtiest jobs in IT, but COBOL skills might see a scant revival in the wake of California's high-profile pay-cut debacle. After all, as Fatal Exception's Neil McAllister points out, new code may in fact be more expensive than old code. According to an IDC survey, code complexity is on the rise. And it's not the applications that are growing more complex, but the technologies themselves. 'Multicore processing, SOA, and Web 2.0 all contribute to rising software development costs,' which include $5 million to $22 million spent on fixing defects per company per year. Do the math, and California's proposed $177 million nine-year modernization project cost will double, McAllister writes. Perhaps numbers like those won't deter modernization efforts, but the estimated 90,000 coders still versed in COBOL may find themselves in high demand teaching new dogs old tricks."

Comments

Who Cares What Language, It Reeks of Poor Design

[eldavojohn]

Got that? So if California goes ahead and builds a new payroll system, within nine years -- about as much time as it has taken to get the 21st Century Project off the ground -- the cost of fixing bugs in the new code could exceed the original cost of the project.

If software is implemented correctly, it will stand the test of time.

The fact that there seems to be some hard-coded values or formulas throughout this code is a fair indication that this COBOL architecture did not have the foresight of someone ever changing minimum wage. Where I grew up, minimum wage changed yearly as it was usually necessary to adjust for inflation. Now, if this is an indication of the rest of that software, I would opt for a newer technology. On top of that, I would go to the lead system engineer with a hand written note reading:

The software shall have a management interface for changing minimum wage and cascading that change correctly through all aspects of the software and other machines.

I'll bet this software isn't modularized. I'll bet this software has some pretty low security standards. I'll bet this software requires a client app installed on any user's machine.

Pull your head out of your ass, "dollar amount one
If you're short on funds, you're short on funds but if you're saying it's cheaper I would like to see your pricing chart for usability, stability, maintainability, etc.

Why COBOL Could Come Back

I think there will always be a niche market for every language but if you mean 'come back' like COBOL would become the average developer's language of choice I would curtly retort with a sharp 'ha.'

I don't get it

[snl2587]

Why do people think it's so hard for a new person to learn COBOL? It's not exactly like learning Japanese: find a good reference book, write a few practice programs, and voila.

I personally haven't needed to learn COBOL, but I see no reason why that strategy I just described, which has worked for me with every programming language I've ever learned, can't be applied here.

Re:I don't get it

[Smidge204]

To expand on your analogy a little:

You get your Japanese reference book, study hard, maybe even get your 1-kyuu certification (I think four years of study for that is typical for non-native speakers?)

So you get a job translating. Your first project is to translate a recently discovered and unpublished early 1900's work written by someone like Touson Shimazaki or Mori Ougai. Good luck!

=Smidge=

Re:I don't get it

[Waffle Iron]

Why do people think it's so hard for a new person to learn COBOL? It's not exactly like learning Japanese: find a good reference book, write a few practice programs, and voila.

In my case, I've taught myself to use a couple of dozen programming languages over the years, and I've mastered several of them. However, I've never managed to make it all the way through the senseless boilerplate headers of any COBOL program before puking. Once the monitor is covered with puke, it's too hard to see the screen well enough to continue.

Re:I don't get it

[snl2587]

This is why I said learning a new programming language was NOT like learning Japanese. True, legacy systems use older versions of a language. But there are still a limited number of commands which are well-documented.

I work with legacy systems a little (but not COBOL) and I say this from experience: deciphering someone's shitty programming style in an antiquated language sucks. But it's doable with little training in the language.

Re:I don't get it

[morgan_greywolf]

COBOL itself isn't all that hard. What you also have to know is the stuff that goes with COBOL on a mainframe environment like CICS (pronounced 'kix') and so forth. And then there's the difference between theoretical knowledge and real world experience. It's one thing to learn C by reading K&R, it's another thing to apply that knowledge to writing a real application or a piece of system software.

Just because you can learn COBOL doesn't mean you can match skills with some of those 90,000 coders.

(Spoken by someone who actually knows COBOL, and has actually written a real-world application in COBOL).

Re:I don't get it

[SQLGuru]

It's actually no different than trying to decipher some code writen in a language you are already an expert in. I'm fluent in both PL/SQL and T-SQL and sometimes I look at a procedure and just have to rewrite it from scratch because the original author wrote horrid code. Sometimes I look at it and can trace through it to figure out what it does, crappy or not. Sometimes it's beautiful and pristine and easy to understand. In the end, I have to make a change to it and I figure out how to change it without breaking anything. Then I move on to something else.

If it were COBOL, I might have a slight hurdle learning the syntax, but already knowing how to code and knowing several languages (BASIC, FORTRAN, C, C++, C#, Java, PL/SQL, T-SQL, etc.) means that a loop is a loop whether it's a FOR i=1 to 15 type loop or a for(int i=1; i [lt] 15; i++) type loop. Syntax can be deciphered with a reference manual. Programming and understanding code is a skill.

Layne

Re:I don't get it

[mwvdlee]

I'm a full-time COBOL programmer with a history in Java professionally and C/C++ and a number of other languages in my own company.

COBOL isn't hard to learn. It certainly isn't much more difficult than any other modern language.

The hard part is that COBOL really doesn't help you much. In most modern languages you can just grab a library containing a complete linked list or efficient sort algorithm. COBOL programmers actually need to know how stuff like this works. Now maybe you're an exception, but surprisingly many Java developers don't know the first thing about basic algorithms and memory structures like that. Add to that the need for high performance (the cost of running a COBOL program is often charged by the minute and measured in fractions of seconds), high stability (I've worked with code which could bankrupt a company if not fixed within a week or so) and the complexity of the typical Mainframe environments COBOL runs on, and you can see why it isn't trivial to start working with COBOL.

The language is easy, using it is not.

Re:I don't get it

[HomerJ]

Like was mentioned in a previous reply, it's not JUST learning COBOL, there is also other stuff like CICS, that you have to know as well.

But you take something else like C. I can get gcc, and start writing code. Same thing if I want to do some web 2.0 project. It's almost trivial to get a LAMP setup up and running.

There's nothing that can simulate a working z/OS environment. There's no compilers to download. There's an emulator out there called Hercules for various IBM mainframes, but you can't get the OS to run on top of it. It's near impossible to go grab "COBOL for Dummies", and start firing up code. COBOL is also rarely taught in university anymore. So the only place you COULD get some exposure to the system, you aren't going to get it. Even if you COULD download the OS, setting it up is very nontrivial. And it's NOTHING like you've seen before.

And these systems aren't just 100% COBOL either. There's a host of mainframe type things like Natural for an ADABAS Database that you're NEVER have experience doing unless you already have a job doing it. You got to the point to where you wrote that program in COBOL, now do you know the JCL to set it up to run? Ok it ran, know what a SOC-7 error is? BTW, it's an uninitialized numeric to save you from typing it into Google.

All these things mean the vast majority of people out there now just don't have ANY experience in dealing with these things. It's hard enough to find people that can step into a team to support a major project. Add in those legacy requirements, and it's probably nil. Anyone qualified to do it, is probably 3 years from retirement from where they are at, and would probably have to offer 7 figures a year to make it worth their while to screw up their retirement options.

Re:I don't get it

[pauls2272]

It's not hard to learn COBOL. I think there is even a COBOL for DUMMIES book. If not, I'm sure there is a SAMS learn it in 24 hrs book.

The problem is being book learned is nearly useless. You need to have a skill set to know what VSAM, flat files, etc are. What JCL and TSO is and how to use it, etc. This just to get to the point where you can actually look at the code and compile it.

Now, if your looking at a good piece of structured COBOL code, changing it isn't too hard. The problem thrown in your way are usually administrative - it takes 4 hrs to actually code the change but 4 weeks to do all the documentation of the change, QA, change control, etc to get the code into production.

Now, if your looking at a bad piece of COBOL code, then it could take a very long time to even figure out what is happening in the program. But this no different than trying to update a poorly written piece of C code.

Imagine needing to update a very complex poorly written piece of Code say of the complexity of Nethack (source is freely available). Now suppose there there is little or no doc to the code and you are fresh from a book on C. I think it would take you a long time to make a complex change to the source code.

So at that point the language is basically irrevelant.

Re:I don't get it

[SatanicPuppy]

You haven't ever needed to learn it, or, logically, ever support anything that was written in it, but you don't see why it's a big deal?

It's a big deal. Legacy COBOL is almost ALL scary code. It's not like it was sexy and clean and professional...The way they wrote that stuff is alien to modern methods. They told the COBOL person what the code needed to do, and he disappeared for a while, and came back and told them it was done. Documentation? Slim. Comments? You must be joking.

I've maintained COBOL code at three significant corporations, and there is so much "hero" code in there, it's hard to even convey to people. This 100,000 line application? It was written by one person, and no one who worked with him was capable of understanding it. No oversight, no review. When he kicked over dead it became a dark spot on the map labeled, "Here be dragons" and no one has touched it since.

Modern methods just don't work like that. In the old days, when you licensed a COBOL app from some company, they sent you the goddamn source code with it, and you could change it...Then the guy who made the changes left, and what is left behind is not supportable by the original company (and the company isn't the original company, but a company that has been bought by a company that was later bought by a different company).

So you need to bring people in, and you need to teach them this application which no one understands, and which isn't really documented, and which is written in a basically dead language, and is often written using the sort of spaghetti code methods we are all told over and over and over NOT TO EVER USE.

Re:I don't get it

[johnlcallaway]

You mean like all the senseless boilerplate crap that you have to use to write C++ GUI programs on Windows??

Crap is crap, either learn it to do your job, or go find another job because you aren't clever enough.

And, just like with C++, once you create a template, it's just fill in the blanks. I had four COBOL skeleton programs back in the 80s that I used, and they covered 90% of all the programs we wrote. The great part was all the programs had the same structure, so a program I wrote was easily understood by someone else.

One of the developer came to me one day and explained a problem he was having. He started to hand me the printout, and I told him what the problem was without even looking at the code. Why?? Because all of our programs looked the same. And I had made the same error before.

Re:I don't get it

[Just Some Guy]

I might have a slight hurdle learning the syntax, but already knowing how to code and knowing several languages (BASIC, FORTRAN, C, C++, C#, Java, PL/SQL, T-SQL, etc.) means that a loop is a loop whether it's a FOR i=1 to 15 type loop or a for(int i=1; i [lt] 15; i++) type loop.

Except that the second one only goes to 14.

Re:I don't get it

[jd]

Cobol was never a good language, and computer scientists fought hard to move the industry away from it because the probability of writing defective code was extremely high. It is readable, but really only in the same sense Intercal is. There are many, many hundreds of programming languages out there with far more programmers in each than Cobol has ever had. Use what makes real sense, not what some medieval history teacher thinks ancient civilizations may have liked. Hell, ADA has more merit - and more support for modern capabilities. If people are really serious about Cobol, I'm going to write an Algol65 plugin for Firefox - see how people like Algolscript pages. Nyah!

No Thanks

[Black-Man]

I learned COBOL in college 20 years ago. I hated it and immediately knew COBOL, TSO, JCL, CICS was not for me. The user was shielded from the complexities of the system, whereas Unix and 'C'... everything was there to learn and discover. No 2-inch IBM manuals to sift through.

Now I work at a place w/ the dinosaur and DB2/COBOL on the backend and I am forced to fix the crap COBOL code written by folks who are long retired. And it sucks... big time. And why these 50-something COBOL programmers think they are hot stuff is beyond me. COBOL is EASY compared to C/C++ or even Java/C#.

The sooner the dinosaur is extinct... the better.

Re:No Thanks

[sm62704]

COBOL is EASY compared to C/C++ or even Java/C#.

That's a strength, not a weakness.

Re:No Thanks

[PC and Sony Fanboy]

You know what is easier? basic. Whether it be Q-basic, Watcom Basic or Woz's handcoded apple basic... it is much easier that COBOL too.

Does that make it better?

What COBOL really needs

[Anonymous Coward]

What COBOL really needs is a hip new framework to make it "cool", just like Ruby!

I propose COBOL on Rails. Any takers?

Mod troll if you wish. :-)

Re:What COBOL really needs

[lpontiac]

You mean like Cobol on Cogs? :)

Re:What COBOL really needs

[MPAB]

Rip off the B

Re:What COBOL really needs

[Bazman]

First you need an Object-Oriented COBOL, aka ADD 1 TO COBOL GIVING COBOL.

Re:What COBOL really needs

[ajrs]

What COBOL really needs is a hip new framework to make it "cool", just like Ruby!

I propose COBOL on Rails. Any takers?

Mod troll if you wish. :-)

You are right, COBOL probably does need a new hip.

"find me a college that teaches it"

[bill_mcgonigle]

FTA:

find me a college that teaches it

What kind of college class would teach COBOL except as a historical curiosity in passing? Their job is to teach kids how to design good software and understand theory. You know, with local variables, objects, exceptions, assertions, and stuff?

COBOL used to target 'business systems'. I'm sure there are several superlative programmers doing COBOL work, still, but business systems programmers tend to be the largest area under the curve, and that's not a problem. The Ruby and Python guys can sit several sigmas out arguing about which provides the better lambda calculus, but meanwhile Java is providing most of the features 'average' programmers need.

If there's a lesson to be learned from the article it's that business systems software isn't ever 'done'. You need to be continually modernizing, with good methodologies, or you're gonna get stuck like Cal-e-forni-a one day. That's either a problem or an opportunity, depending on your perspective, but this isn't an industry standing still.

Re:"find me a college that teaches it"

[Rinikusu]

My old 2 year school still teaches COBOL, RPG, and AIX classes (Southwest Tennessee Community College) and even offers a 2 year A.S. degree in those technologies. The University of Memphis used to teach COBOL in the MIS track, but I have a feeling they've jumped on the .NET bandwagon. I can't speak for the rest of the country, but Memphis, TN has a lot of legacy mainframes and one of my former employer still churns out around 10k lines of new COBOL code a year, at minimum.

What a lot of folks also don't realize is, you don't just rip out a multi-million dollar mainframe system and just replace it with something new. It's also not as simple as "just coding it in Java" and deploying on that hardware. Hell, even writing it in C has issues on many of these machines. The mainframe I was exposed to didn't support the full ASCII character set and you had to use trigraphs. You can't just "apt-get compiler-for-language-of-choice" on these machines, nor download a .msi and get an instant installer.

These are mainframes. They don't even have a filesystem that you would recognize, much less a bash prompt. JCL anyone?

The point is, it's not a simple matter of just porting the software into a modern language. You'll also have to build out the entire hardware system, write the software, test extensively, and then run both concurrently to ensure consistency, and all of that costs money. Lots and lots of money. If what you have works for what you need it for, there's no impetus to change until something like this comes along. However, I'd be willing to bet it's easier and cheaper to change *policy* (the laws) than to scrap the old system completely and rebuild it from scratch.

Re:"find me a college that teaches it"

[MBCook]

DeVry does, or at least did, a few years ago. I should know, I took the class. It was an upper level course, and part of a set of required electives. You had to take COBOL or (something) or (something). I don't even remember if the other two were languages or theory or what. But it was there. All campuses don't have to teach it, it is market driven. Having a very large and old telephone company not to far away means there is some demand for people who have had some exposure to the language.

As some others here have commented, COBOL is amazing. I learned programing through BASIC, HyperScript, C, Java, and other languages. COBOL is so primitive in so many ways. It feels a bit like trying to use your knowledge of Romance languages to decipher how to say something in Japanese.

Now this makes sense, as COBOL was designed so long ago for machines that only had punch-cards and such. But for most any student who learns programing these days to be given COBOL is going to be a huge logical shift.

And that doesn't include the syntax. Ignoring the special columns and such, no modern languages are very close to COBOL's syntax.

A Question For SW developers?

[loose electron]

Does this make sense? As a HW person, I dont have a clue, but I would be curious to know what the conventional wisdom is here. Should this stuff be used in an obsolete language, using code constructs that were dictated by HW limitations (Y2K and 2 digit nonsnense) OR Should this be done in something that is HW independent (Java - if I can show my ignorance here) or something like C++?

Teach me here folks!

Highly likely

[jrothwell97]

COBOL could easily make a comeback, because it's so damn easy to learn. I could train a cuttlefish to write a complex accounts program in COBOL. Heck, I bet even Mike Huckabee could probably manage to work out "Hello World".

Perhaps the reason it may come back is because of the complexity of modern languages. Most OOP variants are horrifically difficult to understand, and a return to the statement-based languages of yesteryear might actually be a good thing: let the coder get on with writing his code, and let the interface builder do all the fancy OO stuff.

Re:Highly likely

[littlewink]

I could train a cuttlefish to write a complex accounts program in COBOL.

Yeah, those cuttlefish are smart. I once saw a film of an octopus observing another octopus open a jar to get a live crab inside. He learned by observation how to do it quicker. Here's a Snopes link.

But if a cuttlefish is smart enough to lern COBOL, he'll probably learn Java instead so he can earn more crabs per hour. So I don't see COBOL cuttlefish flooding the market yet.

Same COBOL guys from Y2K?

[zentechno]

I learned COBOL way back when (1984 to be precise, then used it for a few years and it eventually rotted out of my brain). I was thinking of coming out of COBOL Retirement back when I heard what huge demand Y2K was putting on the lack of COBOL knowledge. What happened to the Y2K COBOL team -- did they help the state of CA then? I'm guessing if CA didn't find a replacement in 10 years (which is not-so-suspiciously just before everyone starting fretting over Y2K), I don't really see it happening now, or I'd dig out my old COBOL disks, dirty up my resume (re)writing a few more COBOL programs, send out a resume, and move to sunny CA and $clean $up -- but anyone whose been a contractor has already thought like this.

Re:Who Cares What Language, It Reeks of Poor Desig

[idobi]

I think many people missed the point of the California problem. It wasn't limited to lowering everyone's earnings to minimum wage. The main problem was that after the budget was approved, everyone's wages needed to be adjusted again AND those people need to have back wages paid for the period that they we being paid less. That's a complex problem that most programs, even modern ones, probably are not designed to consider.

I can see it now . . . .

[MarkvW]

Object-Oriented COBOL, Visual COBOL, JAVA-BOL, COBOL++ . . . Functional software subordinated to the elaborations of the programming class!

California! Prepare to warmly welcome your programming overlords!

Re:I can see it now . . . .

[Shados]

I can't tell if you're jesting, or if you simple don't know that most of the cobol variants you named actually do exist....

Good news and bad news

[base3]

Good news: There's a job for someone with legacy COBOL skills because the State of California needs someone to update their payroll software to pay their workers minimum wage.

Bad news: The gig pays minimum age.

Re:the guy wasn't going to reduce the pay anyways

[jesdynf]

I've seen it, sure, but... I dunno. I've got no reason to think the guy's lying.

You want everybody's pay cut down to six whatever? I can do that for you in /ten minutes/. Guaranteed. You say you want it to happen, I make it happen.

You want everybody's pay cut down to six whatever, recalculating all employees as if they were paid on an hourly basis, reclassifying employees as appropriate, comply in full with all labor codes while I do so, maintain an escrow account with the difference between their real pay and their current pay, pay that out at some undetermined point in the future -- and have all of it work, perfectly, the first time and every time, taking full responsibility for every employee of the STATE OF CALIFORNIA?

Man says six months, I'm not telling you he's wrong.

The real skill is 'thinking before coding'

[myawn]

One thing about the mainframe coding mentality was that compilation time was expensive, processing time was expensive, and sophisticated debuggers didn't exist (and it's expensive to print 500+ page core dumps on fanfold paper). So programmers tended to do much more up-front design so that the first effort tended to be much higher quality.

Or, as I saw on someone's whiteboard once, "It's easier to teach a COBOL programmer C than to teach a C programmer discipline".

KISS

[Archangel Michael]

Keep IT Simple Stupid.

No, not it, IT.

Keep Info Technology Simple. We tend to want to add in all the bells and whistles we "want" but don't "need" because we can.

When I build a system from scratch, it is fast, clean efficient. It has everything one of the user "needs" to do their job. It is fast, efficient and clean. And it doesn't have problems if they keep it that way.

But they start adding in all the add-ons, upgrades, multiple versions of the same basic tools. Google, Yahoo, Myspace, Coupon cutter, Weatherbug, Ding (SW Airlines) etc ....

Then they start to complain about how "slow" and "Buggy" the computer is. All those bells and whistles do nothing but distract the user from doing what he OUGHT to be doing.

I see this within applications as well too. Feature creep is a real problem, as is trying to over simplify the front end, at the expense of the back end.

Take a look at the comparison of Vista and XP, there is NOTHING in Vista that is really "needed", but it is a bloated mess when compared to XP. why?

They don't want to KISS, they want "fancy", and fancy breaks, and is more expensive to fix when it does.

Re:KISS

[serviscope_minor]

First you say:

Keep IT Simple Stupid.

Then you say:

When I build a system from scratch, it is fast, clean efficient.

Which makes me suspicious. Simple and efficient rarely go hand in hand. My first implementation is usually slow and stupid and simple, because stupid (=slow) is generally simplest.

On another point entirely, you say:

It has everything one of the user "needs" to do their job.

and:

Feature creep is a real problem,

The trouble is that COBOL is generally used for financial apps. They never do everything the user needs, because the apps are meant to last forever. Everything the user needs lasts about a year until the legislation changes, or organisational structure changes or various other things. These programs have to feature creep because features keep creeping in from the outside. You can't write a complete, finished financial program.

Generally as programs are incrementally modified, they get nastier as the original program was designed with a certain structure and dataflow in mind. Sooner or later, a new feature comes along which requires a modified dataflow, and that can be nasty to add. So, maybe a little global variable gets added to allow this data to be passed around. To do it "properly" would require a considerable redesign which may not be fesiable. Remember, these programs have to reflect the world right now, so features must be added in a timely manner.

Repeat that process for 40 years where multiple language standards have been ratified, programming styles have come and gone, the original developers are long dead and the employment structure and tax law is completely different and you have a real mess.

But that's not just complexity for the sake of it, and no amount of KISS will solve that problem.

COBOL just works

[One Intention]

Where I live, COBOL is used everywhere. I'm 33 years old and I use it on a daily basis and have been since I graduated from college 10 years ago.

Companies like Wal Mart, ACXIOM, and large transportation companies such as JB Hunt, ABF, USA Truck, Wingfoot Commercial Tire, and Data-Tronics use it day-in and day-out.

However, unlike the COBOL I always read about here on Slashdot, the code we work with is standardized, modularized, and backed with a relational database (IBM DB2).

I also happen to work in more modern languages (compared to COBOL) such as PHP, ASP, and .NET, and compared to them, working on COBOL is like taking a day off. It's top-down design makes it easy to read and follow, and as long as you aren't dealing with "go to" code, it's no harder than anything else out there.

Don't disregard a language simply because it's old, or because you don't have a fancy IDE to rely upon. Compared to some of the messy AJAX implementations I've seen, I'd take COBOL any day.

New code isn't that bad

[MikeRT]

It's the way that we're expected to code. I'll give an example of what I mean. I first learned a bit about using SOAP via SOAP::Lite in Perl. Setting up a CGI script to run web services in Perl is so easy that I have to pinch myself to realize that, yes, Virginia, I really am using Perl and not Python or Ruby when using that package. My day job is Java-related, so I tried Axis2, which seems to be the popular way to do SOAP with Java.

Like all things Java Enterprise Edition, it required at least a dozen steps to replicate a few in another language. XML files everywhere, deploy it here, now put this file here, now that file there. Start this, do that.

WHY DOES IT HAVE TO BE THIS FUCKING COMPLICATED TO GET ANYTHING DONE IN JAVA OR .NET?!

Oh, right, because we need a server that costs 10s of thousands of dollars to run something that a free copy of Apache would run in half a dozen scripting languages that are tried and true. Besides, as a condescending executive told me in college during a business presentation, no one uses PHP, Perl, etc. anymore. It's all enterprise shit with hellaciously expensive servers and support packages.

Re:Who Cares What Language, It Reeks of Poor Desig

[Krishnoid]

If software is implemented correctly, it will stand the test of time.

Sturgeon's [Ll]aw applies to software -- except probably with the 90% figure adjusted upward as some function of Moore's law and the observations of Fred Brooks, of Mythical Man-Month fame.

IMHO, after a couple decades of accretion of existing software systems, poorly implemented and even designed software systems are production reality today. If you don't take this into account, you're dealing with an ideal that will statistically exist only 10% or less of the time, and when it does, only when rigorous administration and maintenance is continuously applied to the software.

Acronym

[sm62704]

Crappy Old Bad Obsolete Language

Re:COBOL, Web2.0, etc.

[s31523]

It's not just the COBOL aspect. It is the legacy PDP-11 that is running it, or the VAX-VMS, or whatever... The language is easy, but figuring out how to login, setup the build environment, decode the weird legacy build script, and then transfer the program load to the target computer can be a tall order for a noob.
And what hot young smart kid wants to learn all this for next to nothing pay and the prospect of never using the skills again?
It can be done, however, and whoever has these systems should make it a priority to start finding a good maintainer either by trade or self-taught or make a replacement system.

Re:Bah

[geekoid]

I know COBOL programmers making 150 an hour that have been on the same contract for 10 years.
They work 40, and rarely are on call.

So there is a certain appeal. Plus COBOL is interesting.
I mean C? who wants to work on 1970's tech?

no decent statistics

[hellfire]

I'm having problems following the money on this article. Does an article that says COBOL may not be so bad really attract a lot of eyeballs for ads?

I say this because the article is bullshit on a tortilla. They talk about how much bugs cost and how many people found, but how does that truly compare to 10, 20 even 30 years ago? They had a source, why didn't they put that in?

No software is perfect. I'm even willing to agree that complexity has increased while quality has decreased, but by how much? The problem is you can't make these assertions without proper comparative facts, including adjustments for inflation.

Finally, COBOL is COBOL. Programs designed in COBOL are, on average, less complex than today's programs. They require more resources to develop, which means more manpower or more time. Also can COBOL be integrated with a front end website? Generate PDFs on demand? Perform EDI? Have sophisticated tools to make integration with newer languages and systems easier? Can you build it as an app on top of a relational or OO database?

COBOL was sufficient for it's time to do what it needed to do. It may be sufficient for many processes now. But COBOL isn't going to magically come back and everyone's going to start creating sophisticated ERPs from scratch with it. It's just another tool.

All this has happened before,

[AP31R0N]

All this will happen again.

Re:Who Cares What Language, It Reeks of Poor Desig

[polar red]

yeah, as a software archeologist myself, i can testify that old systems still need maintenance: new laws, changes in organization, new products,... that means that those old systems all need continuous 'fine-tuning' - no administrative program really is 'complete'; to make matters worse: those systems get more and more complex. While a complete rewrite could save money in the long run, in the short term this would be very costly.

I had mod points but didn't see Uninformed listed

[crosseyedatnite]

Oh the dilemna of mod points....

IBM still makes brand spanking new Big Irons. But they're not quite as big as they used to be. And they do more. And they also do stuff like run Linux.

Please go educate yourself before you look like a bigger moron.

Re:Who Cares What Language, It Reeks of Poor Desig

[SatanicPuppy]

Coming from someone who is currently supporting a legacy COBOL system, you're right on target.

COBOL is shit. Most legacy COBOL code is not designed with anything like what we'd consider "best practices" today. The language itself is unfriendly, and doesn't lend itself to the modern world.

What it does have is inertia. It works, right? Why replace it? It's the product of decades of business evolution, do you think you can replace that overnight? New code will never be as good.

Basically, they're comfortable with their crusty old bugs, and they don't want to deal with scary new bugs.

In my environment we've basically thrown this whole interface built on Oracle and Java on TOP of the old COBOL MPE/ix system. Placates the conservative financial types, while providing some modern functionality.

Still there are all kinds of problems with the old systems. You can end up with some really scary problems with old code, because it doesn't recover from failure like you'd expect modern code to. A java billing application running on a modern transactional database...If it crashes, you can just run it again. A COBOL app on a legacy database? That just ruined your day.

I would hope that the response to the situation would be to finally migrate your systems, not to accrete more levels of unsupportable crap by dragging COBOL programmers out of retirement, or forcing existing programmers into that outdated mold. I know the money types though; they are perfectly capable of trying to stick with the outdated method simply because it's in their comfort zone.

COBOL Less Expensive?

[kenh]

As a recovering COBOL Programmer (MVS/XA, IMS/DB, CICS, DB/2, VSAM, JCL ;^) I find it hard to believe that coding COBOL programs is "cheaper" in any real, absolute sense. If you are comparing "KLOC", then yes, COBOL is cheaper, because each line is "easier", but it likely does less work than a "higher-level"language line of code would do...

Comparing LOC per function point, not sure - it seems that we have lower expectaions/goals for COBOL code, so function points don't really compare.

Is it because programmers are cheaper for COBOL, ignoring function points and KLOC? Perhaps, but that ignores the likely greater number of cheaper COBOL programmers.

COBOL, Mainframes, and timesharing technologies have been on the way out for my entire career (I've been in IT since the late 80's), and the driver seems to be fashion, and it's saving grace is always that these proven technologies have stood the test of time and still work just fine, thank you very much.

Also, I refuse to believe that it would take half a year to cut state worker salaries to minimum wages - they can accomodate annual salary increases can't they?

Re:Bah

[ShieldW0lf]

The US is about to experience total economic meltdown. After the Fannie May and Freddie Mac debacle, loans to the nation will be harder to come by, damn near half the population is about to retire, there are more people in Law, Finance and Advertising than there are in skilled trades, companies are fleeing overseas, etc, etc, etc.

You're going to see little old ladies with wheelbarrows of cash unable to buy bread in short order, just like when the Cold War ended. Who really cares about fixing these financial systems? It's just wasted effort by a nation that has a lifetime of hard work and painful sacrifices ahead of them. Why even bother?

Counterpoint: Bah

[rah1420]

I love COBOL. I have programmed in many languages throughout the years but I can do my best work in COBOL. I recently started working on it again after a 10 year hiatus and was amazed at the advances in the language.

The thing that you don't understand is that unless your college did not keep up with the compilers that were deployed, that COBOL is not "60's tech" any more. Yeah, it has its idiosyncracies but so do any other 3rd generation languages.

Re:Cobol still runs on hardware

[pauls2272]

>Eventually the COBOL systems will be replaced simply because they run on computers that
>aren't compatible with today's designs.

Completely wrong. There is Cobol code from 1960s running on todays IBM Z10 processor. IBM is almost always backward compatible. IBM ain't Microsoft where the code breaks every couple years when MS releases a new windows or a service pack.

I am happy

[Mong0]

I am so glad that COBOL is not a sexy language. Why? Because it keeps the majority of coders out and keeps the need for developers at a high premium. This allows those of us that know COBOL and actually enjoy coding it to laugh all the way to the bank.

I have been coding COBOL/DB2 for ten years now and have never once felt that I could not get another job doing the same thing making the same or more money.

You can make the statement that COBOL is a dead language all you want but banks, insurance companies, telecoms, energy companies, etc. will continue to use and develop new project around COBOL because "no one has ever been fired for going blue".

You go ahead and continue to develop your little web apps and I will know I have a stable job out look for the next 30 years.

Re:Who Cares What Language, It Reeks of Poor Desig

[bws111]

Yup, no doubt the people that implemented this system were complete idiots, unable to come up a system that was 'well designed'. Oh wait, I wonder what 'good design' was when this was written. Maybe it included things such as 'being able to run in a machine with 16MB virtual address space, with 1MB real memory installed'.

As for security, you're probably also right there. It seems just about every week I read a report of some COBOL-based payroll system being hacked (which you would expect, since there are probably thousands of such installations). Oh wait, I never read that.

It seems to me you are quick to criticize, without even a basic understanding of the requirements for this change. It is NOT some simple 'raise minimum wage'. It is 'temporarily lower ALL employees wages (hourly and salaried) to minimum wage'. When the budget is passed, put the wages back where they were and issue back pay. Don't forget about little details like deductions for taxes, insurance, retirement, etc. How do you calculate the withholding rate for income tax? What do you do when someones deductions exceed their pay? When the pay is restored, what do you do about people that have left, retired, or died in the meantime?

I think that the timeframe they give is not all that unreasonable, considering all that must be done. It will take a substantial amount of time just to come up with complete requirements. Then the coding must be done. Since this is a financial application I am sure there is much testing, and probably some fairly stringent auditing that must also occur.

Re:Who Cares What Language, It Reeks of Poor Desig

[pauls2272]

>I think many people missed the point of the California problem

That was part of it but reality is that it is mostly politics.
According to a post on USENET (in bit.listserv.ibm-main) by a guy who actually worked on the code, it is all VSAM files for database and table driven. Trival to change to min wage and just being VSAM means you could just duplicate the files and easily maintain 2 sets of files - one with min wage and one with the real wage.

No, the answer is the politician don't want to do it so just come up with any excuse to say it is "impossible".

a little refreshment of COBOL for all

[nawcom]

http://99-bottles-of-beer.net/language-cobol-1820.html

*nawcom reads the first part of the code and pukes all over the screen*

Re:Lets throw out the baby WITH the bathwater!

[ShieldW0lf]

I'm saying that before this is finished, it's going to make the Great Depression look like a trip to Disneyland, and regardless of what you do, it's all going to go to shit and your dollars are going to be cheaper to wipe your ass with than toilet paper. But, hold on to your illusions as long as you can anyways...

If they pay for it, I'll learn it

[Rastl]

If I'm told by my company to learn COBOL and it's on their dime, I'll learn it. Why should I care one way or the other? It's just another language to know.

Zealots aside, if it's needed then learn it. It might not be as 'sexy' as the newer stuff out there but if it keeps me employed and puts me into a hard-to-do-without niche I'm perfectly happy.

Then again I may be the exception in that I'll learn anything my company needs me to learn. There's a few languages I've learned on my own, for my own reasons, but overall I'll take any training they're willing to dole out. Kind of like the reward pellets. I'll keep whatever I learn no matter where I go so I don't see a downside.

Re:Who Cares What Language, It Reeks of Poor Desig

[johnlcallaway]

Payroll is one of the BEST applications for COBOL. It's very table driven and procedurally oriented. There are very specific discrete steps to be taken when calculating gross pay, pre-tax deducations, tax deductions, and final deductions. Then calculate where the net pay is distributed via EFT or paycheck, create files or print checks, and you are done.

I managed a COBOL based payroll system back in the 80s with green-screen interface, and it was one of the easiest systems to work on. It was written in discrete elements that were easily changed without impacting other programs. New programs could be easily added into the stream. Any system that is well designed can be simple to extend.

That crap about not being able to roll back sounds like someone who doesn't know how to write maintainable code. And anyone who doesn't do backups (or make sure the daily ones were done) before installing new code is an idiot.

I just got through migrating an 8 year old C++ system to Java because it was an abysmal failure that no one wanted to touch. Replaced 12 programs that basically all did the same thing with 1 program and 2 stored procedures, reduced complexity, and increased flexibility.

No language is immune to bad development.

Re:Who Cares What Language, It Reeks of Poor Desig

[johnlcallaway]

What a bunch of horse shit. Don't blame poorly designed code on the language. I wrote plenty of COBOL code in the 80s that was able to recover from failures, even those that wrote into ISAM files. It's not about the code, it's about how clever and imaginative the coder is.

Is COBOL suited for everything?? Of course not, nothing is. That is why a good coder will have several tools and be able to use the one that best suits the task at hands. Creating fixed-output reports?? COBOL. Writing applications to process HTML?? I don't think so.

As someone who currently spends his career rewriting 'legacy' code, whether it be COBOL or C or C++ (10 years ago is still legacy in some minds), I can tell you that rewriting a complete system is a recipe for disaster. First, all maintenance on the new system has to stop. Secondly, someone has to go through every program LINE BY LINE and document what they all do, I can guarantee that what people think they do is not what they really do.

Then you have two choices ... rewrite, or re-engineer. Rewriting many times ends up with the same garbage that ran before, just in another language. Re-engineering is better, but takes longer and is more difficult to parallel test.

My preferred method is to take subsets and gently migrate. 10 small projects with a one or two failures is much better than one large project with one failure.

Re:Who Cares What Language, It Reeks of Poor Desig

[SatanicPuppy]

I agree; the stuff worked well in old systems. It was optimized to save CPU cycles and disk space...It was a conscious decision which made good use of the resources of the day.

Unfortunately that day is gone. We should focus now on code reliability and maintainability and COBOL is not great in those areas. Trying to write in intelligent failure into a COBOL app is a nightmare compared to JAVA where it's almost the backbone of the whole language.

Re:Who Cares What Language, It Reeks of Poor Desig

[mattwarden]

What it does have is inertia. It works, right? Why replace it? It's the product of decades of business evolution, do you think you can replace that overnight? New code will never be as good.

State governments are paying millions and millions of dollars to replace their legacy COBOL based systems, so the question of "Why replace it?" has some pretty convincing answers...

Re:Highly unlikely

[PRMan]

a return to the statement-based languages of yesteryear might actually be a good thing: let the coder get on with writing his code, and let the interface builder do all the fancy OO stuff.

Not hardly. I just rewrote a VB 3-6 application into C#.NET because nobody can compile it anymore (requires a 16-bit tab component and nobody has VB4 16-bit install disks, let alone floppy drives even if we did).

The original application was 13,000 lines of BASIC, written (mostly full or half time) over the span of 11 years. The new C# application is 900 lines and has MORE functionality (not to mention nice commenting as opposed to NONE) and I wrote it in 2 months.*

Return to the bad old days of underpowered languages that require thousands of lines to read a database and display it on the screen? No thanks.

*BTW, this brings up a good point. Just because some company has 9 million lines of COBOL doesn't mean that the programs couldn't be replaced with 500,000 lines of an OO language.

Re:Who Cares What Language, It Reeks of Poor Desig

[raftpeople]

It seems to me you are quick to criticize, without even a basic understanding of the requirements for this change. It is NOT some simple 'raise minimum wage'. It is 'temporarily lower ALL employees wages (hourly and salaried) to minimum wage'. When the budget is passed, put the wages back where they were and issue back pay. Don't forget about little details like deductions for taxes, insurance, retirement, etc. How do you calculate the withholding rate for income tax? What do you do when someones deductions exceed their pay? When the pay is restored, what do you do about people that have left, retired, or died in the meantime?

The voice of experience. I'm constantly amused by posters who think they "know" the answer and it's so simple, everyone else must be dumb. Yet they've never had to execute a project of that magnitude. This entire topic really has very little to do with COBOL and more to do with the issues you raised (as well as the numerous other ones that will be discovered as you walk through each of the questions you listed).

Re:COBOL has loops?

[raftpeople]

PERFORM ... UNTIL

Re:COBOL has loops?

[LMacG]

> Unless you consider GOTO a loop constructor...

Why not? Ultimately, the compiler is going to produce the machine language equivalent of a goto anyway, so what difference does it make if you have to hand code the initialize, test, iterate portions of a loop or if the language has it all packaged up for you?

Granted it's been over 20 years since I worked on a COBOL program, but the last guy I worked for had developed some pretty decent coding standards that let us use a fair amount of structure in our programs. It wasn't perfect, but I know for a fact that the number of late night phone calls I got went way down after learning to do it George's way.

Re:Who Cares What Language, It Reeks of Poor Desig

[SirLurksAlot]

COBOL is shit. Most legacy COBOL code is not designed with anything like what we'd consider "best practices" today. The language itself is unfriendly, and doesn't lend itself to the modern world.

The language itself is fine. Yes it's verbose, and yes it's old, but it does what it needs to do, which is solving business problems. Look, you need to keep a historical perspective here. COBOL was created back in the "bad old days" before all the best practices were written, because at the time they were still being written.

Basically, they're comfortable with their crusty old bugs, and they don't want to deal with scary new bugs.

Ever heard the phrase if it's not broke don't fix it? By your logic we need to pull out core modules in the Linux kernel just because they've been in there for 10+ years! (Note: I don't actually know what the lifespan of code in the kernel is, but you hopefully get my point.)

Still there are all kinds of problems with the old systems. You can end up with some really scary problems with old code, because it doesn't recover from failure like you'd expect modern code to. A java billing application running on a modern transactional database...If it crashes, you can just run it again. A COBOL app on a legacy database? That just ruined your day.

Not to ruin your rant here or anything, but you're comparing a modern language using a modern transactional db with a legacy language using a legacy db. Of COURSE you're going to see a difference in your ability to recover from a failure! It's not as if you can't code for a proper recovery in COBOL if you're using a modern transactional db on the backend.

I know the money types though; they are perfectly capable of trying to stick with the outdated method simply because it's in their comfort zone.

I think you're forgetting why most of us are employed as developers. 95% of us (I'm speaking about employed devs, mind) are not here to write code simply to write code, we're here to solve problems, and most of the time that is for a business that is out to make money. Also most of the time if there is no business case to update the code then it doesn't get updated. As for outdated models, how is it outdated if the model still serves it's purpose?

Re:Who Cares What Language, It Reeks of Poor Desig

[SatanicPuppy]

I've rarely ever seen good COBOL, so maybe it's possible. From what I HAVE seen, especially with the never-to-be-sufficiently-cursed KSAM flat table POS wannabe database files, suggests to me that good, recoverable, code, is nearly impossible to write. None of that stuff is transaction safe. The programs work in too many discrete steps; if it fails, it hardly ever fails in such a way that you can just RE-run the program; either you need a recovery-specific subset or you have to traverse the program until the point of failure and see if you can recover it.

The line by line approach is a recipe for disaster. In old code, especially in old code, most lines are suspect. What is dependent on system crap (ISAM/KSAM files are a good example) that doesn't apply in the modern world? What is part of an ugly kludge? What is just unnecessary?

You need to step back, analyze the process, and replicate the functionality, not the code.

Yes, it's a sucky process. Yes, there are going to be problems. But it's only going to get worse going down the line, and supporting COBOL is getting more nightmarish by the year as there are fewer and fewer people in the market who are capable.

It's going to have to be done. I'm not against an incremental approach, but I am strongly against just pretending like the current situation can continue forever.

Just translate COBOL to C++.

[Futurepower(R)]

Or, better idea, translate all the COBOL to C++. No teaching needed.

Re:Just translate COBOL to C++.

[donaldm]

Or, better idea, translate all the COBOL to C++. No teaching needed.

Actually the link you provided has converters from COBOL to "C", "C++", "Java" and "C#". If these converters/filters produce anything like the output of yacc and lex (open source bison and flex) then the code while runnable is more or less unmaintainable but not to worry you have a job for life if you want ;-)

If you read the following the best quote on cobol is as follows:
Critics have argued that COBOL's syntax serves mainly to increase the size of programs, at the expense of developing the thinking process needed for software development. In his letter to an editor in 1975 titled "How do we tell truths that might hurt?", computer scientist and Turing Award recipient Edsger Dijkstra remarked that "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense".

Hey it's a quote so please don't shoot me!

Re:Who Cares What Language, It Reeks of Poor Desig

[polar red]

Rewriting software should always be the last resort.

not if you could go from COBOL to a language that supports classes, or even just more modularity would be great ...

Re:Who Cares What Language, It Reeks of Poor Desig

[doupatex]

I've rarely ever seen good COBOL, so maybe it's possible. From what I HAVE seen, especially with the never-to-be-sufficiently-cursed KSAM flat table POS wannabe database files, suggests to me that good, recoverable, code, is nearly impossible to write. None of that stuff is transaction safe. The programs work in too many discrete steps; if it fails, it hardly ever fails in such a way that you can just RE-run the program; either you need a recovery-specific subset or you have to traverse the program until the point of failure and see if you can recover it.

It is possible to write good COBOL :-)

In the programs I maintain, the recovery is per-program or per-job. Each "unit" of work has a documented (albeit manual) rollback. It usually implies replacing the trashed files from a backup tape (*).

Manual well documented recovery has an advantage : it requires that someone actually looks at the problem and finds why it crashed.

(*) Yes, we don't have a relational database on our mainframe. Only flat files. With 8-chars names. And no hierarchical filesystem. It's called "DOS/VSE with ICCF" and it's so old I feel like a caveman, which is actually kind of fun sometimes :-)

Re:Who Cares What Language, It Reeks of Poor Desig

[Timothy Brownawell]

The language itself is fine. Yes it's verbose, and yes it's old, but it does what it needs to do, which is solving business problems. Look, you need to keep a historical perspective here. COBOL was created back in the "bad old days" before all the best practices were written, because at the time they were still being written.

I don't see that this has anything to do with whether COBOL is an OK language. This means that it was an OK language (or maybe even a good language) in the "bad old days", but Moore's Law has given us the luxury of having much higher standards now.

Re:Who Cares What Language, It Reeks of Poor Desig

[Alpha830RulZ]

Since COBOL doesn't have subroutines or any way to pass parameters save global variables, I would say that is a safe bet.

Actually that is what CICS and other architecture layers are used for. What we like to refer to as a COBOL program is usually a module or piece of a larger system flow. The language doesn't provide robust support for modularization, so various architects developed frameworks to support the need. One of the aspects of that is that many systems are composed of small, fairly simple modules which are passed a communications control record, which is used for inter-module communication. Within each module, you're right, all variables are global, but COBOL modules in these systems tend to be comparable in size to class files in the Java I work with today.

It's possible, and fairly common even, for large COBOL systems to have quite a bit of architecture and structure available. Sure, I like modern stuff better, but it's just ignorant to pretend that modern coding practices emerged in 1997 like a mushroom after the rain.

Re:Save money

[Alpha830RulZ]

most programming languages are human comprehensible... provided you've been trained in them.

Haven't worked in Perl much, have we?

The real problem of Cobol

[jbolden]

The real issue of Cobol is not Cobol in and of itself but that so many other ideas are used which are not currently in fashion.

Operating provided data structures
Tables with multiple types of data
ISAM/VSAM rather than databases
job control cards with values need for the programs to run
etc....

That will make the environment highly unfamiliar to younger programmers. The IT management has been very irresponsible in creating a situation where code crucial to most companies is undocumented and uses concepts which are difficult for new programmers to understand. Heck most companies did excellent work for the Y2K crisis in documenting their systems which they have lost and not maintained over the last decade.

COBOL, FORTRAN and mainframes

[jandersen]

We have been predicting the demise of both COBOL, FOTRAN and mainframes for how long, now? Decades? I have suspected for a long time that we are not going to lose them any time soon - COBOL is certainly no beauty, but it is proven and seems rock solid. And it is not even all that bad a language to work with, although I must admit it looks rather painful, doing anything but simple programs with it. Still, I worked with COBOL for years - and enjoyed it too.

The same goes for FORTRAN: an ugly language with some horrifying features; but one that has a huge, old code base in the science community - because it was first, but also because it has the exactly the features you need for numeric programming. A bit like a meat cleaver - not a thing of beauty that your girlfriend would have on her make-up table (depending on your relationship, of course), but functional and to the point.

Re:Who Cares What Language, It Reeks of Poor Desig

[kevin_conaway]

Thread here. The gentleman in question is Tom Harper.