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

FIRST!!!

[EvilIntelligence]

Yeah, baby!!!

Why would they teach new people?

[Anonymous Coward]

Just hoard all the money for yourself!

Re:Why would they teach new people?

[treeves]

Sometimes people GET PAID to teach things to other people. You should check into it.

Re:Why would they teach new people?

[WinPimp2K]

because some of the old COBOL folks are old?

As in, having better thngs to do than be hassled by a bunch of whiney snot-nosed MBAs trying to pudh them into 80 hour weeks?

And in some cases, due to failing health and general mortality, just not up to more than a limited amount of work?

And sure, some of them will decide to keep doing it themselves - until they decide to retire, and then who takes over maintenance and development?

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

Save money

[Anonymous Coward]

I though SOA and web 2.0 stuff is supposed to save money?

Re:Save money

[ardle]

And COBOL was human-comprehensible. SOA is definitely in the realm of COBOL, except that it goes one better: not only is the code difficult to read but there's lots more of it.
Nobody better tell 'em that the majority of that code is simply copying Strings around, or we'll all be outta work...

Re:Save money

[PC and Sony Fanboy]

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

And isn't that the point? We need people trained in COBOL to understand COBOL. So human comprehensibility or not, we're still stuck using old technology (which is not always a bad thing).

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?

Re:Save money

[Metasquares]

Perl, properly coded, is not difficult to read. In fact, once you see enough of them, neither are most regexps.

Re:Save money

[Alpha830RulZ]

I agree. I maintain a set of perl scripts for integrating our software, in which I eschew use of the implicit variables ($_, etc) and they are easy for anyone who is newer to the language to pick up. I hope you'll agree the heavy use of the implicit variables can make for a steep uphill climb for the novice. A Perl program which makes no concessions to readability can resemble line noise pretty easily.

I think regexes are a bit harder for most people. I'm not bad at them, but i've had to sit and look at some of them for awhile.

Re:Save money

[donaldm]

Perl IMHO is surprisingly easy to learn if you have some programming experience and a good reference book. The hard part of writing Perl as for any language is making it maintainable. I don't consider myself a programmer even though I do programming so I always heavily comment my code since I adopt the attitude that I may have to come back and fix or extend my code some day.

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

[Anonymous Coward]

I used to do programming/support software written in a 60s era language. It was a step up from COBOL (One of the companies products was written in COBOL, and it sucked), but it wasn't modern. I suspect less than half of my coworkers had a CS degree, and I didn't consider any of them hardcore CS types. In fact, over half were women. Thing is, it's dull and boring business logic. There are probably a few hundred thousand bored housewives with the aptitude to learn and do COBOL programming. Hell, even CmdrTaco could probably do it... with a spellchecking IDE.

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

[DeadDecoy]

But then how else will HR fulfill their asinine and unreasonable quota of resume skills. If I didn't know better, I'd say you're trying to put them out of a job.

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

[Anonymous Coward]

Spoken like one of those 90,000.

It may be hard, but it can be done. Programmers are smart and can be taught new things.

I have never simply read a reference and then claimed knowledge of a language. I just jump right it. There's your real-world experience.

Re:I don't get it

[Anonymous Coward]

No, as someone who wrote plenty of COBOL in the dark ages, you absolutely *do* get it.

Whatever the problem here is, it's not the COBOL, which for all its faults, was meant to be comprehensible almost by someone who'd never seen a computer before. Anyone who can write code in anything can write complex COBOL programs in about 4 days.

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

[ArmyOfFun]

Does he have to do it by himself? Or will he have access to a couple of people well versed in Japanese? It makes a big difference.

I understand not wanting to replace your only COBOL programmer with someone with no COBOL experience. On the other hand, I don't see a problem hiring someone who has never programmed COBOL into a COBOL shop. As long as someone can program well in more than one language it shouldn't be a problem. If the new guy is still struggling after about a month or two, you let him go. Hire him as a contract-to-hire if you're really worried. Even if you burn through a few guys this way, it's still going to be vastly cheaper than hiring a COBOL guru with 20+ years experience. Especially if you just need someone for maintenance/bug fixing/small enhancements.

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

[PC and Sony Fanboy]

OMG the whole meaning changes when you actually bother to read the comment! OMG!!!

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

[Anonymous Coward]

This analogy is utterly inappropriate.

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

[Anonymous Coward]

Just like any other programming job then, I presume? Badly written or maintained systems are everywhere. Your COBOL project might be poorly structured, too; but there are also very sensible systems written in COBOL.

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

[Cro Magnon]

Also, as a COBOL programmer, you will probably have to work with code that was written in the 60s or 70s. Some of that code was butt-ugly when it was written, and has nearly half a century of cruft on top of it. And for a language that is supposed to be "readable", some of those old COBOL programs can be an amazing PITA to decypher.

Re:I don't get it

[snl2587]

I think it would take you a long time to make a complex change to the source code.

Well, yeah. It would take anyone a while if they were unfamiliar with a complex program.

A lot of people seem to be misinterpreting the "book" comment I made. I don't sit there reading a book, nodding my head every once in a while, and then claim knowledge of the subject. I learn by doing it. I see what concept the chapter is introducing and then write a program to test that concept and learn it firsthand.

But then again, I was never formally trained to program, so I have no preconceived notion that the only way to learn something is to have someone teach it to you and then get a degree in the subject. I don't claim to be an expert either. I just do the job I'm paid for.

Re:I don't get it

[karbyn-aceous]

> I didn't consider any of them hardcore CS types. In fact, over half were women

ROFL

Re:I don't get it

[DNS-and-BIND]

For native English speakers, it takes three times as long to learn Japanese as it does another related language. To put it another way, in the time it takes you to learn Japanese, you could learn French, Italian, and Polish instead. I don't know how it is to learn COBOL, but I thought I'd just throw that in there - it's a big opportunity cost. In the 4 years it takes to become literate in Japanese, one could be most of the way towards a law degree, for example.

Re:I don't get it

[morgan_greywolf]

Yeah, I hear you. The thing is that I also don't make my living doing COBOL programming (maybe I should after seeing this ;) nor have I written anything for for a 'real' COBOL development position. I currently make my living doing *nix administration. (working on a broken server now ;)

Re:I don't get it

[petermgreen]

Syntax can be deciphered with a reference manual.
It can but if you have to decipher everything with a referecnce manual than unless you are extremely good at multitasking or you translate the code first and then try to understand the translation (which would probablly work but would be extremely tedious and error prone) you are going to have trouble focusing on truing to understand what the program is doing.

IMO what getting fluent in any language whether human or computer is about is getting to the point where the translation from words and syntax to ideas in your head becomes unconcious. Then in the case of a computer language you can focus on what the code is doing. In the case of a human language you can focus on what the person is trying to tell you/explain to you.

Re:I don't get it

[hanshotfirst]

Yep - easy enough to learn to get by.
I had a class in college (early 90s) where the assignments could be done in Modula-2 or COBOL. I hadn't had to do Modula-2 for a couple quarters, and didn't want to have to use it again, so I decided to learn COBOL on the fly for the class. (And because I was sickly curious why it was so disliked).
I aced the course and haven't touched COBOL since. Easy enough to learn, but not something I put on the resume.

Re:I don't get it

[morgan_greywolf]

Just as there are readable Perl programs (There are. No, really! There really are! See Webmin.) there is unreadable COBOL code, yes. 'Readable' is less about the language and more about the coder who wrote the code. I've even seen readable assembler. Of course, my definition of 'readable' means 'readable by someone who knows the language' not 'supposed to be readable by your Aunt Tillie'.

Re:I don't get it

[maxume]

After the first incident, you should have gotten a bucket. Then, you could come back to the clean screen after you had rinsed out your mouth.

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

[Waffle Iron]

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

Yeah, just like that, but even more senseless, because you don't get the benefit of a GUI out of the effort. (Very few people these days write Windows GUIs in C++ without some kind of nanny IDE doing the work for them anyway.)

The great part was all the programs had the same structure, so a program I wrote was easily understood by someone else.

And the amazing part is that over the course of 5 decades, nobody has bothered to factor out the crap that's always the same in every program.

Re:I don't get it

[TheMCP]

Except, no computer language is anything like as complex as a human language, so the analogy falls down very quickly.

Re:I don't get it

[Anonymous Coward]

I suspect less than half of my coworkers had a CS degree, and I didn't consider any of them hardcore CS types.

My experience is that people who think their CS degree is worth anything in particular aren't worth much themselves. Hence why they try so hard to make it seem as if the piece of paper actually means something.

I hire people who can do the work. More often than not they are largely self-taught, with or without a degree. Passion, self-direction, and the ability to learn trump any of the academic nonsense that is largely useless and soon forgotten anyway.

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!

Re:I don't get it

[timepilot]

I dunno about that. I agree that a degree in computer science doesn't necessarily make you a good programmer, but I think many college degree programs teach more than just the major-specific material.

Good degree programs teach students how to learn, how to research, how to ask questions, and how to communicate better. No doubt people can do those things without a degree, but it is harder to get a degree if you *don't* know how to do them.

Re:I don't get it

[innocent_white_lamb]

find a good reference book, write a few practice programs, and voila.
 
The first step is the problem, as far as I can see.
 
I have done a bit of searching and have even asked a few times on Slashdot (when the subject comes up):
 
Where do you find a currently available and useful Cobol reference and/or tutorial?
 
Everything that I've ever managed to find is either out-of-print or apparently irrelevant, and I've never had anyone attempt to answer my question here on Slashdot, either.

Re:I don't get it

[Baruch Atta]

...SOC-7 error
No, its a SYSTEM ERROR number 0C7 (zero cee seven) DATA EXCEPTION. There! I saved hundreds of queries from /.ers to that overloaded Google server.

Re:I don't get it

[snl2587]

I found this in about a minute: The COBOL Center. The IBM Bookshelf seems like it would be pretty good.

I'm not sure if they have physical books, though.

Re:I don't get it

[apexdawn]

Your post reminds me of some time I spent software testing at a company that maintained a mainframe system.

While I can say that I am not interested in the craft of mainframe applications maintenance/development it was interesting to find out how such systems worked. I was taught by the departments guru on the system as he explained everything from JCL to copybooks.

"It's hard enough to find people that can step into a team to support a major project."

I couldn't agree with you more. Besides the guru the only other person with mainframe experience was the manager (both gentlemen in their 50's) the rest were web testers. Granted the company maintained COBOL apps and their equivalent web apps but the majority of requests came for mainframe application improvements which for large projects only left two people who could jump right in.

Before I left he was looking everywhere he could for a QA tester with the years of mainframe and COBOL experience needed to do what you just said.

-Reed

Re:I don't get it

[Daimanta]

"Comments?"

Yes, COBOL sucks!

Re:I don't get it

[retendo]

I used to think the same way, code was code. But you overlook one thing. The environment matters. And what environment does the COBOL guy coding for the state of California use? The good ole' green screen. Actually, it has been modernized, now it supports five colors. You are working on a mainframe with an editor that makes vi look modern, a file system without the ability to make files read-only, and no, I repeat no semblance of source control. How do I know all this? I am a contractor for the state and one of the COBOL guys sits right across from me.

Our biggest problem lately is the fact that the JCL code on the mainframe keeps getting accidentally changed. There is no way to lock it, no accountability for changes. There is absolutely no way to ensure that when we go into production that the code we tested is the code being executed.

Most folks writing COBOL aren't working directly on a PC, they are working on the mainframe which comes with a whole host of issues. The mainframe is good for certain tasks but as an enterprise development platform is rather lacking in facilities that many consider the norm.

Re:I don't get it

[ACMENEWSLLC]

http://en.wikipedia.org/wiki/COBOL

I took COBOL in college. I use RPGILE now. We do have a few COBOL programs left from about 20 years ago. Still run with no changes. COBOL was designed to be easy, plain English code;

            MULTIPLY B BY B GIVING B-SQUARED.
            MULTIPLY 4 BY A GIVING FOUR-A.
            MULTIPLY FOUR-A BY C GIVING FOUR-A-C.
            SUBTRACT FOUR-A-C FROM B-SQUARED GIVING RESULT-1.
            COMPUTE RESULT-2 = RESULT-1 ** .5.
            SUBTRACT B FROM RESULT-2 GIVING NUMERATOR.
            MULTIPLY 2 BY A GIVING DENOMINATOR.
            DIVIDE NUMERATOR BY DENOMINATOR GIVING X.

as per that WIKI page.

What I find is that it is not the language (COBOL/RPG) that makes me love these systems over PC's. It is that if you run a line of code, the results are always the same.

On a PC I might run a line of code through one PC and get one result, while another generates a different result. This could be due to the Intel FDIV issue, or due to different print drivers which affect the printout, bad RAM, not trapping errors(on error resume next), whatever.

If I run code on a Midrange or Mainframe, the results do not vary like this. We have never replaced one of these systems with a PC based system without accuracy going down. Now, productivity is another story. Some of the PC systems with integrated maps, forms, and so forth can really boost productivity. But they never seem to be as stable.

Re:I don't get it

[Anonymous Coward]

awesome.

Re:I don't get it

[Fulcrum of Evil]

It is exactly like learning Japanese, except that you're in 1850 japan and if you say the wrong thing to the wrong person, they cut your head off. Sort of.

Re:I don't get it

[russotto]

Sure. You could learn COBOL well enough to make this change to their system. So could I. But is there any chance you'd do it for minimum wage? Didn't think so...

Re:I don't get it

[Anonymous Coward]

Actually, z/OS 1.9 can be downloaded (illegaly) from Emule (or Kademlia). Look for "zOS ADCD" there. It also has all other IBM software, such as DB2, CICS, IMS.. It works like a charm in Hercules.

Disclaimer: I am youngster and professional mainframe programmer, and really hate IBM policy with respect to availability of z/OS for students. Times have changed, and there is now opensource to compete with. It's a shame that almost nobody knows mainframes.

Re:I don't get it

[blueapples]

It's near impossible to go grab "COBOL for Dummies"

http://www.amazon.com/COBOL-Dummies-Arthur-Griffith/dp/0764502980

Re:I don't get it

[SQLGuru]

Noone says that you have to use the green screen for all of this work. FTP text files back and forth. Decent editors (even with color coding if you want). Any of a large collection of version control systems. Plus, your files are now backed up somewhere besides the mainframe. All of those problems are solved with relatively simple process.

Layne

Re:I don't get it

[Anonymous Coward]

Pfft, my first part time job was translating the Nihon Shoki. Now get off of my lawn!

Re:I don't get it

[Anonymous Coward]

>> The language is easy, using it is not.

An easy language that is hard to use.. hmm...

Re:I don't get it

[McSnarf]

OK.
You could learn COBOL from a reference book.
You could also try to learn sex from a reference book.

COBOL is old and different. It was conceived at a time when computers and peripherals were much different, when computer science was something weird done by mathematicians, when software needed to be compact and fast. When GUIs and graphic processing didn't exist - nor did most other programming concepts considered "normal" these days. Imagine batch processing. Your program, on punched cards, together with paper on punched cards, would (if you were lucky) refer to data on a hard disk, then produce either a printout, more punched cards or even a magnetic tape...

You can program in eight modern languages?
An analogy. You can drive eight different modern cars. Automatic transmission and everything.
Could you drive a Ford Model T? Or a steam engine?

It will expect you to KNOW why it has a number of different data types to store numerical data.
You might need to understand about memory usage and layout to understand what some of the code does.

Recursion? In most implementations, recursively calling a subroutine is fine. It just won't return :)

Concepts like STRING and UNSTRING are actually very useful. Others, like ALTER, are not. (Hands up, you who have seen ALTER statement...)

And STRING and MOVE can both be used to move data from A to B. Still, there is a tiny difference, not usually explained in the books.

COBOL is a highly specialized language, very good for large volume batch transactions of data. Something it still does very well. You don't want to do that in Java.

It's like teaching BASH scripts to Windows users. They do not really understand the class of problems you can solve with it - and the reason behind some of the shell implementation details.

You can learn COBOL. No problem there. But using it in any reasonable way takes a lot more.

Also, why would you? There's still a lot of us old farts around and the need for even more COBOL programmers just isn't there.

(Disclaimer: I haven't written COBOL for money for over ten years now. I don't miss it. PL/I however...)

Re:I don't get it

[donaldm]

Actually Algol was the precursor of languages like "C", "C++" and "Pascal", so if your Algol program is well written it will be quite readable, however if it isn't, well it will be just like any poorly written program "difficult to maintain".

I know this may come as a shock to some but I have actually seen FORTRAN IV code that was so well written that it was easy to understand 20 years after it was written in the early 1970's. The person who wrote it was a senior research scientist who was about to retire when we found some of his works. It really depends on the person who writes the code and how good they are at documenting.

Re:I don't get it

[The_reformant]

Thankfully most of my needs in that area I can get by with USS. The parent is right though this stuff is seriously weird if your coming from a distributed background.

Re:I don't get it

[tehcyder]

Thing is, it's dull and boring business logic

If that's your opinion, I hope you don't work in a business environment.

Re:I don't get it

[Anonymous Coward]

Hmmmmm

Good luck!

I worked with a COBOL application that had 600+ separate programs, all a minimum of 5,000+ lines, all chaining to one another with various parameters and flags being passed from one to another in an incestuous process.

Bah

[BoomerSooner]

I hate COBOL. Was forced to take a class in college and they told us it'd be easy to get a job if we took the advanced course. Who the fuck wants to work on 60s tech? I took C instead and am much happier for it.

Re:Bah

[cryfreedomlove]

Same here, except for me I was in college 20 years ago. They told me that there were a lot more jobs available if I took the COBOL classes. I willfully decided to deny myself that 'opportunity'. All jobs are not the same. I have to love a job to take it and I don't love COBOL jobs.

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?

Re:Bah

[SoCalChris]

I took C instead and am much happier for it.

So you decided to go with a nearly 40 year old language instead of the nearly 50 year old one?

Don't get me wrong, C is a good language, and still relevant. I just wouldn't complain about COBOL's age, and then start talking about how you learned C instead.

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?

Re:Bah

[SatanicPuppy]

It's not about age, it's about relevance. C is relevant and you can get plenty of jobs working on new code if you use C.

COBOL? You're going to be working on other people's legacy code for the rest of your life.

Re:Bah

[SatanicPuppy]

Nice analysis there Chicken Little.

The dropping dollar spurs foreign investment and makes American products more marketable overseas...Give's 'em more bang for their buck, makes our manufacturing sector more competitive.

Skilled trade work is overrated, sadly; it's about economic opportunity costs. Trying to force your economy to stay in the developing stages is guaranteed to produce stagnation and inflation, while moving to the sort of service economy that can fleece other countries of the money they're making doing trade work is really the next step in evolution. Look at Switzerland.

The demographic problem is real and interesting, but the solution is simply to open the doors to more immigration; we'll need the bodies, we'll have the work, and despite our flaws, this country is still a pretty nice place to live, and unlike the snotty european social democracies, we still let people immigrate.

All in all, interesting times.

Re:Bah

[Anonymous Coward]

Add to that most COBOL programmers think in assembler. Most "programmers" today have not idea of cycles, t-states, registers, efficient data structures, code longevity.

Reminds me of Hook

[Anonymous Coward]

"...and you had better deliver. Or no amount of clapping will bring you back from where I will send you."

You COBOL devs have 3 years!

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

[Anonymous Coward]

You say "COBOL is EASY" like it's a bad thing.

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

[larry bagina]

Maybe it is a bad thing. (VB is easy, too). Garbage in, garbage out. In this case, the garbage in is the low skill and intelligence needed. The garbage out is 2 digit years, poor design that requires 6 months of work to adjust salaries, etc.

Re:No Thanks

[geekoid]

"COBOL is EASY compared to C/C++ or even Java/C#."
that's a good reason for it to go extinct~ I mean, who needs easy when you can have overly complex bloat and 5 times the cost?

Re:No Thanks

[rbanffy]

Isn't being easy a good thing?

I mean, if the harder it is to develop software the better, we would be doing it all in hardware ;-)

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?

Re:No Thanks

[AKAImBatman]

You know what is easier? basic. Does that make it better?

Yes! In some situations, BASIC is "better".

If that confuses you, then you need to learn that "better" is a subjective term. Depending on the circumstances, what is "better" and what is "worse" will change places. In more modern terms, we tend to say, "Use the right tool for the right job." Of course, if all you have is C^H a hammer...

Re:No Thanks

[littlewink]

...and I am forced to fix the crap COBOL...

Nobody's forcing you to do anything! Get another job and quit complaining already!

Re:No Thanks

[Anonymous Coward]

BASIC is not easier than COBOL when you're working with databases. I never understand what people see in BASIC, it's useless for just about everything. COBOL does what it's supposed to do, work with data stored on disks, long before broken SQL "standards" were a glint in IBM's eye.

If you need to procedurally process data, and it's not on an AS/400, COBOL will do just fine. I wouldn't want to force it into doing web crap or transcoding.

Re:No Thanks

[sm62704]

Indeed. A screwdriver is useless for driving a nail, but a hammer is not a good tool to drive a screw. dBase is fine for small data sets (and you can do a hell of a lot) but NOMAD is far better for huge tables and databases. Neither is any good whatever for rendering a web page or writing a video game.

Re:No Thanks

[PC and Sony Fanboy]

Yes! In some situations, BASIC is "better".

... So I'm waiting for an example.

Oh, and if you have TWO hammers, and one is made of dead babies, then ONE of those two hammers is probably not good for anything except dead baby jokes.

Re:No Thanks

[PC and Sony Fanboy]

Are you actually agreeing with the original post? I thought your response was a disagreement. Maybe it was all a misunderstanding...

Re:No Thanks

[Anonymous Coward]

I hated it and immediately knew COBOL, TSO, JCL, CICS was not for me.
  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

Err... forced by whom? Why work on COBOL if you hate it?

Re:No Thanks

[Jaysyn]

No, but it could be considered a strength as well.

Re:No Thanks

[MightyYar]

I had numerous qbasic scripts (programs?) that dealt with oscilloscope data or temperature data and did quick analysis/data formatting.

Basic was better for that, though there are far better tools these days (and the o-scopes and temperature loggers have better ways to grab data).

Re:No Thanks

[PC and Sony Fanboy]

though there are far better tools these days

... and thats the point. Old languages are good enough, but there generally exists a new, better way to do things.

Re:No Thanks

[Anonymous Coward]

No 2-inch IBM manuals to sift through.

I had to comment on this one.

IBM manuals are fucking awesome. They are not exactly light reading, but they aren't meant to be. They are incredibly thorough, precise, clear, and well-organized. The DB2 ones, for example, read like the specifications documents they must have used to develop DB2 in the first place.

I recall a saying about Unix: "Unix is simple, but it takes a genius to understand its simplicity." That's actually a very true statement. Any idiot can grasp cut, sort, uniq, grep (for simple regular expressions, anyway), and paste. But it's actually very difficult to put those utilities together and make them do what you want. Not a lot of people can do it, and frankly, not a lot of people can ever learn to do it. The same thing applies to C. Any idiot can learn to write a toy C program, but very few can write even 1k LOC and have it work reliably (or at all).

It's what makes me think that Unix and C aren't actually any easier at all. We've just tricked ourselves into thinking they are because of their deceptive simplicity. By the time you realize how complex and difficult they actually are, it's too late, you've invested too much time so you may as well keep going.

Sometimes I think I'm a mainframe guy born 20 years too late, though.

Re:No Thanks

[TheMCP]

When I was in college, the dean of computer science had a pin that said "With your help, we can stamp out COBOL within our lifetime."

I know a few "old timers" who know COBOL. They've all taken it off their resumes, on the basis that if they put it on, somebody might offer them enough money to tempt them into taking a job dealing with ancient COBOL code, and they don't ever want to see COBOL again. One of them explicitly told me that she thinks she could make a good bit more money if she'd do COBOL, but doesn't want to touch it, the money isn't worth having to spend the remaining years before her retirement dealing with COBOL instead of Oracle.

But I have to disagree with you in that you said:

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

If it's so easy, people would want to use it. It's not easy. It has simplistic syntax, that's a different thing entirely.

protected against identity theft?

[peter303]

I've wonder why I've seen so few reports of massve database leaks from Federal and State financial systems compared to industry. My guess is there are few hckers conversant in COBOL, OS-360 and nine-track tapes. One of the rare bright spots in this mess.

Re:protected against identity theft?

[topham]

Have you ever tried to get data into, and out-of most mainframe configurations? At best companies will use an FTP like file queue system. You drop files into a folder and the system transfers them to the mainframe, and the reverse.

Hardly a system ripe for l33t script kiddies to hack

Re:protected against identity theft?

[pauls2272]

>My guess is there are few hckers conversant in COBOL, OS-360 and nine-track tapes.

Hackers can run OS-360 on their PCs using Hercules. OS-360 is freely available.

However, no one is running OS-360 in production and I doubt you could find a 9 track tape anywhere.

The reason that hackers can't hack in have more to do with RACF and the structure of the mainframe (user code can only modify itself) than anything else.

Re:protected against identity theft?

[sjaskow]

Um, you would be wrong about the availability of 9-track tapes and drives. A decade or so ago, we had these http://www.sunstarco.com/Tape%20Drives/Cipher/cipher_m990.htm attached to a PC for transfer of data from a mainframe that wasn't allowed FTP access. I imagine you could find interfaces and cables on eBay.

Re:protected against identity theft?

[NateTech]

So? What's so bad about that? It works.

Maybe for maintenance, but

[gnasher719]

I took a COBOL course at university in the very late 70s, passed, never touched it again. Then bought a book a few years ago from the bargain book, read through it, and the language is just absurd. Ok, it would have been hard to design something better in the 50s when it was created, but it is just horrible. If we really want a cheap, simple language to do bog standard things without all that newfangled stuff, then the dBase language would be ten times better. And dBase on todays hardware would just _fly_.

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

[Rycross]

How about Cobol .Net?

Re:What COBOL really needs

[Anonymous Coward]

How about Cobol On Cogs?

Re:What COBOL really needs

[Anonymous Meoward]

I know for a fact that the NC state gov't paid contractors nicely during the dot.com bust to turn COBOL into Java.

I'd imagine you'd make quite a bit for yourself if you could automate that process, or just write a decent COBOL interpreter.

The devil would be in the many many many details. I never learned COBOL, but I know enough about it to know that it's a simple language made horrendously complex with an assload of coupling between I/O subsystems and formatting/presentation code. And then there's database access..

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

[Just Some Guy]

I propose COBOL on Rails. Any takers?

I'd suggest aiming for COBOL on Hoveround.

Re:What COBOL really needs

[hey!]

Well, if you look at the basic, classic RoR demo, that shouldn't be that hard.

90% of the "oh wow" factor of RoR is that it takes care of managing so many niggling organizational, configuration and convention setting details at just the point where you really don't want to be burdened with them, but where other frameworks insist you must.

It's as if the barber you'd been going to all your life starts off every haircut by whacking you on the head with a mallet. Then one day you try a different barber, and you sit down expecting the mallet whack, but instead he just starts cutting your hair. Now your old barber featured stuff like lilac water and pomade and what not, but absence of mallet seems like an extremely significant feature if you've never tried it before.

Re:What COBOL really needs

[Anonymous Coward]

COBOL on Chains?

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.

Re:What COBOL really needs

[Anonymous Coward]

The whole concept of Rails doesn't really serve to make COBOL sound any more modern. The railroads had their heyday back in the 19th century...hardly modern.

As such, I'd propose COBOL on Maglev. It could even be used as the design philosophy...so that the COBOL code never touches the supporting code which is likely written in some other language.

Re:What COBOL really needs

[Anonymous Coward]

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

COBOL does not need framework. It needs co-balls.

Re:What COBOL really needs

[glenstar]

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

Then you will love Cobol on Cogs.

Re:What COBOL really needs

[Quince alPillan]

Its not Cobol on Rails. Its Cobol on Cogs

Re:What COBOL really needs

[Anonymous Coward]

Cobol on Cogs?

Re:What COBOL really needs

[rubycodez]

there are object oriented extensions to COBOL, the ISO COBOL 2002 standard has them and even before that major COBOL compiler vendors had their own, such as Microfocus Object COBOL.

There are even groups working on aspect-oriented COBOL.

Re:What COBOL really needs

[NateTech]

If you didn't have to rebuild the whole barbershop every couple of months for the guy to continue to have a workplace, RoR would be great.

Re:What COBOL really needs

[salesgeek]

I suggest "COBOL on Crack".

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

[Anonymous Coward]

Southeast Community College in Milford Nebraska http://www.southeast.edu/academics/default.asp is One College that still teaches COBOL. They've done some re-vamping with the curriculum since I've been there (creating a COBOL back-end with a pc front-end) but COBOL programming is still their main language. They have multiple hiring agreements with large companies such as DST http://www.dstsystems.com/

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"

[bill_mcgonigle]

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.

Ah, good point. I was only thinking of Computer Science tracks.

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.

That's all true. What I was trying to get at is that no computer system is going to be useful forever. And as you mention forklift replacements are torturous to impossible. So, continual improvement is the only way to do this maturely. And I understand that not every manager has the ability to justify a budget for good IT, nor the staff to envision or implement it. Fortunately, the market can rule on these issues for business. With government, not so much.

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.

Re:"find me a college that teaches it"

[One Intention]

Colleges still teach it on a Computer Science Track:
http://www.atu.edu/acad/catalog/2009/undergradcatalog.htm
COMS 2853 File Processing in COBOL
Prerequisites: COMS 2203. Program
design, development, testing,
implementation, and maintenance in
COBOL. Topics include file structures,
batch file processing, and index file
processing.

Re:"find me a college that teaches it"

[cleatsupkeep]

Another school that has a Cobol course is Carngie Mellon University. It's called Introduction to Business Programming.

http://is.hss.cmu.edu/index.php?p=news&s=news&t=News%20%26%20Events

Re:"find me a college that teaches it"

[bill_mcgonigle]

Ooh, that was close. I downloaded the PDF and it's taught on the Informations Systems track, no the Computer Science track, AFAICT.

Re:"find me a college that teaches it"

[Anonymous Coward]

find me a college that teaches it

James A. Rhodes State College, Lima, OH offers it.

I took 2/3 classes of that and AS/400 and decided if that's what they consider good classes programming major, I'm switching to Networking ... and I did...

Those were the worst 2 college quarters of my life x.x

(The reason they still teach it is there's a big insurance company in Van Wert that still uses COBOL and i think they have some kind of funding from them or something)

Re:"find me a college that teaches it"

[One Intention]

It's actually all rolled up into a single track "Computer and Information Science". There is no distinction between the two.

Re:"find me a college that teaches it"

[Abattoir]

FWIW, while IBM made AIX, it is a Unix operating system, not related to mainframes. It runs on POWER architecture, including the System i and System p platforms. COBOL does run on AIX though. IBM has a compiler product as well as others I'm sure.

Re:"find me a college that teaches it"

[Abattoir]

As I commented elsewhere, I took COBOL at DeVry as well, as I graduated in 1999, and market demands were for y2k fixing. We had COBOL 1, COBOL 2, Database Programming for COBOL (IMS/DB2) and CICS on COBOL when I went. These were 500-level courses. I went to DeVry in Phoenix, which had a HUGE demand for COBOL programmers for y2k at American Express. My class alone (~50 people) had about two dozen that went to work at AMEX.

Re:"find me a college that teaches it"

[SirLurksAlot]

Columbus State Community College still teaches it as a major part of their CS curriculum. I don't know that I necessarily agree with this, but considering that Nationwide Insurance owns a large part of downtown Columbus and most of their business runs off of legacy COBOL I can understand their reasons for keeping it. I'm guessing the other colleges that still teach it do so for much the same reason.

Re:"find me a college that teaches it"

[fishbowl]

>What kind of college class would teach COBOL except as a historical curiosity in passing?

The kind of college that is focused on being an immediate-term source of labor for skills in demand in a specific market. Full-spectrum, tier-one research institutions don't have the same priorities when forming curriculum.

This is why it actually does matter where you went to school, sometimes.

If you want the kind of job where you program in COBOL, I hope you have also studied all kinds of finance and accounting, business law, tax administration, and so on.

Re:"find me a college that teaches it"

[scepticos]

If there's a lesson to be learned from the article it's that business systems software isn't ever 'done'.

BTW: "maintainability of code is what counts most" - Guido van Rossum, author of Python.

Re:"find me a college that teaches it"

[bill_mcgonigle]

It's actually all rolled up into a single track "Computer and Information Science". There is no distinction between the two.

hrm, I was just going by the description of the four tracks in the pdf. If you've got local knowledge, that's always more accurate!

Re:"find me a college that teaches it"

[Anonymous Coward]

DeVry University did... They stopped with the class of '05.

Re:"find me a college that teaches it"

[Anonymous Coward]

I teach Java, Python, C, C++ ..... and COBOL. Why? Because we were approached by a MAJOR Government department desperately looking for COBOL programmers.

Look, people, relax. You use the right tools for the job. Maintaining a legacy COBOL system you need... umm.. yep, that's right, COBOL.

And don't worry: my students are perfectly aware of the advantages and disadvantages of all of the above languages. That's what teaching is all about, damnit!

Most of the article is bunk...

[Lumpy]

Honestly if WEB2.0 makes websites more expensive, where does it require that a website MUST HAVE web2.0 crap on it?

Honestly I find that most customers despise all the junk that comes with web2.0 and do not want it, let alone pay for it.

Same for everything else, making it more "complex" is by desire not by necessity. California's problem is because of a lack of programmer on staff and the fact the request is a wierd one as far as a payroll system is concerned. you do NOT normally cut people's wages for a temporary time while tracking the wages cut and then paying them back after the fact. What they want is complex but they dont want to pay for it.

Re:Most of the article is bunk...

[bigman2003]

I agree completely.

This is just a STUPID plan that nobody could have forseen.

If you do design software, unfortunately this comes up all the time, and it hurts, even when you are expecting it. This just happened to me recently:

"Okay, new federal regulations state that we need to track the number of miles travelled for all trips."
"Okay, but we only store mileage on auto travel, because that is how they get reimbursed."
"We need it for air travel, and train travel if there was any."
"Umm...okay, I guess I could use mapping software to determine distances."
"But we only will track air travel on US based carriers. We also only want business class travel."
"We don't store that information."
"Well, you need to get it."

F me.

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!

Re:A Question For SW developers?

[Bill, Shooter of Bul]

No it doesn't really make sense to make new applications in COBOL. Many people such as I dislike its verbosity, but the real reason is deeper. If you were to rewrite the system, you would want something that did the job well, but also one that has a number of people who know and understand the particular quirks of the language/platform. Plus you'd want one that had support for modern problems( parsing and validating XML, database client libraries for the popular databases, SOAP, Http, threading, inter process communication, Encryption). While a touring complete language could do any of those tasks, it would be best not to let your developers write implementations for those tasks and focus on the job at hand. At the same time you don't want to have the language allow common coding problems to crash the system (no c,c++). I believe that java would be the safe, conventional choice. A multi vendor requirement ( which I would like to see imposed for government jobs to keep competition) would prelude C#, at least until Mono is more accepted/polished.

Re:A Question For SW developers?

[jd]

If a "legacy" language is used, the smartest choices would be Cilk or Occam, both of which make multicore and multinode processing trivial, and also make secure, robust programming practical. They SHOULD be on any sane IT manager's radar by now - the insane ones will go with COBOL and the notorious software unreliability that plagued the planet as a result.

Those wanting to go with a less drastic update really aught to be looking (by now) at OpenMP (which supports many languages) or Unified Parallel C (which at least lets you leverage existing C skills). Not sure where D is on parallelisms, but it is a cleaner OO language than most (C++ and Java especially take note) and might be helpful just for that.

If you absolutely insist on using existing ancient code, on the grounds that it has had longer to have bugs worked out, FORTRAN is the way to go. Businesses never pushed COBOL very hard, because it's so damn fragile. If you've ever had a trillion dollar water bill, that was a degenerate COBOL application. FORTRAN, by being used by high-end facilities where a single error could fry the entire budget for several years, tended to be used by people with considerably greater skill. So much so that it is still the number one programming language for mathematically-oriented programs, even though C maths libraries are as good or maybe better. The skill that is possible in FORTRAN is such that it is still the language of choice in many specialist sectors.

(Note: FORTRAN and COBOL are correctly given in upper case as they were invented before lower-case letters. It is often assumed that Admiral Grace Hopper was in the US Navy, when in fact the continental land-masses had not yet divided at the time she developed COBOL.)

Re:A Question For SW developers?

[Aardpig]

(Note: FORTRAN and COBOL are correctly given in upper case as they were invented before lower-case letters...

Not anymore; since the Fortran 90 standard, Fortran has been spelled Fortran.

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

[Anonymous Coward]

Right, well, I guess that's what I get for not really previewing ... here's the rest of "Pull your head out of your ass:"

Pull your head out of your ass, "dollar amount one < dollar amount two" is not always the cut and dried determining factor here. I would wager that most of the time the new software is more expensive than fixing the bugs of the old software but you're getting so much more than that if you do this right.

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

[Anonymous Coward]

You're right that there's a language problem, replacing over-complicated messes like C++ or Java with a language that's simple but totally gimped isn't much of a solution. In *any* language worth using, it's possible to choose between statement style code and powerful abstractions simply by using the style you are most comfortable with. We have a *serious* problem when C++ is the canonical language to get stuff done in, and is thought of as something that a coder "graduates" to. I've had people tell me that they programmed a little back in the day, but couldn't get the hang of C++. All I can say is, "It's not you, buddy!"

Re:Highly likely

[Galaga88]

Teach Huckabee COBOL? That's because he didn't major in math, he majored in miracles. And getting quality COBOL code now would quite frankly fall under the latter.

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.

Re:Highly likely

[fishbowl]

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

On the other hand, the understanding of the business processes, law, finance, etc., doesn't always come easy.

I wrote some FORTRAN this week. Sure I could use another language, but if you could see the purely numerical flavor of my work you'd probably agree that it's not necessarily a good idea to port to C or Java or whatever just because FORTRAN is old (and it's not that old, the build date on my compiler is 4-1-2008 :-)

I've never liked COBOL's syntax at all, but what aggravates me even more is the typical programming idioms that are associated with it. And I have never in my life seen more paper used for any process, more than COBOL development. Yeah, I know it doesn't have to be that way, but in many shops it definitely is.

Programming COBOL (or my favorite, PL/I), might be lucrative, but it seems soul-killing to me. I wouldn't do it. I'd try subsistence farming before I took a regular job in COBOL maintenance, and I wouldn't take a job doing *new* development in COBOL, but I'd certainly make a bid for them to hire me to put me in charge at a level where I make decisions about the platform.

Re:Highly likely

[Bill, Shooter of Bul]

COBOL is not significantly easier to learn than most languages. Take a look at the hello world collection and tell me COBOL is easier to write hello world than any other.

Python is a one liner. As are many other languages. Even Java with its "horribly difficult to understand" OOP syntax (?!?!?) is less lines than COBOL.

I'm not saying COBOL is hard to understand or learn, but neither is it easier. Other languages have the same useful capabilities as COBOL, with powerful standard libraries making modern programming easier.

Re:Highly likely

[Pinkybum]

This must be a troll - but I will bite. The reason software has to be complex is because the systems and data handling are complex. It is the only reason. Nobody should use a complex software engineering tool to do something simple. The trouble is in the real world business and engineering problems are complex and that is why software engineers get relatively higher pay implementing systems that make dealing with all that complexity easier. If we weren't then we have no value and a monkey could the job.

Re:Highly likely

[hey!]

Well, there are a vast number of useful programs that could be characterized as filter programs. They take a stream of data, and perhaps a few configuration option, perform the same operation on a sequence of chunks from that stream, and produce an output stream. So much of the useful products of the first thirty or forty years of modern computing fall into this paradigm, that it's embedded in the very conceptual DNA of Unix, along with the pipe. A lot can be done with filter like programs and a staff that has been trained to use them to manage processes.

Things started to change in the 1980s, and but by the year 2000 these mechanisms, while still obviously usable, aren't quite as useful. A basic GUI program looks a lot like an operating system used to look: taking streams of events and routing them to various actors. Information is stored in complex systems such as databases or network services which have both state to be managed and interfaces that are sufficiently rich that they are either a language or bordering on it.

And if GUI prorams are kind of like operating systems used to be, the bits of software we code are marshalled into a common address space and are expected to behave themselves. And between all the things that have been coded by ourselves and others, there is an unlimited number of way we can interact, and even the simplest objects provide a rather rich and often idiosyncratic interface.

The thing about filters is that even a really badly coded filter conforms to an important design criterion: it has a simple, well defined interface.

Programs that would be considered quite simple these days would qualify as systems programs twenty five years ago. And there is much, much, much more detail you must attend to, a great deal of that having to do with arbitrary conventions and limitations of things your stuff has to interface with.

While we've gained a lot, we've lost something too. Programming today is often a lot more tedious than it was back in the day, because you've got so many more details to manage and attend to. Good design is about recapturing what we've lost, which is the ability to work on one aspect of a problem at a time.

Re:Highly likely

[petermgreen]

The thing about C++ is that it allows a huge variety of coding styles. At one end of the scale you have C (well more or less, there are a few things that are legal C but not legal C++), at the other end you have template metaprogramming with comparison methods specified as tempate parameters and so on.

Mastering the higher levels of template metaprogramming in C++ is probablly hard (I tried and failed to understand it but I wasn't trying very hard as I really didn't need it for what I was doing at the time) but IMO there is usually very little need for that. BUT you don't need to reach that level to productively write C++ code.

Re:Highly likely

[jrothwell97]

I must agree. I didn't say I liked COBOL: I'm simply saying it's very simple, because it has a very English-like syntax. However, I find its typing style laborious and slow.

That is not to say that it's not an incredibly simple language to pick up, and practically anyone could learn to code a basic functional program in it within the hour. I do think that there are going to be people who like COBOL who would be quite happy to code in it, for that amount of money, despite the fact that for many developers it is a cumbersome dinosaur of a language.

There are many people I know who were programmers in yesteryear, and love COBOL because of its English-like syntax. So I do think that COBOL could make a comeback (albeit indirectly) because of its simplicity.

Re:Highly likely

[Cro Magnon]

IMO, COBOL is "easy" because it lacks pointers, addresses, or all those other features of modern languages. It is also very verbose. Even worse than Ada. It is probably the absolute worst language for a "hello world" program.

Re:Highly likely

[Bill, Shooter of Bul]

Pointers? Python, Java,Ruby, PHP, they don't have pointers. Pointers are pretty much relegated to c, c++ and Pascal, not exactly a who's who of modern languages.

Re:Highly likely

[Bill, Shooter of Bul]

Upon further reflection, I think by 'easy', you mean 'simple'. Simplicity has its place, but at other times it can make things more difficult.

Re:Highly likely

[Anonymous Coward]

They say the same thing about BASIC. Which is why there's so much crap VB code out there.

In medicine, boy scouts learn first aid, but no one expects them to be able to manage kidney transplants.

In software, we seem to think being able to write a count-to-10 program qualifies any random person off the street to do enterprise web applications.

Java's really no more complicated than COBOL - just has a richer set of support libraries. But if most modern-day Java programmers are expected to know how to use those libraries, at least they don't have to be experts in JCL, the Linkage Editor, and reading core dumps. And if COBOL didn't do transactions there were still checkpoint/restarts.

Life may have been SOME simpler back then, but I wouldn't say it's that much simpler.

Re:Highly likely

[g-san]

I am a cuttlefish, you insensitive clod!

Re:Highly likely

[Anonymous Coward]

Learn more languages.
Learn more languages.
Please, learn more languages.

If you think C++ is anything more than a travesty masquerading as a flexible language, you need to

Learn more languages.
Learn more languages.

Hoping for gumbo, the design group added hosts of contradictory features. What they got instead was a garbage heap, a twisty maze of syntax, none alike, or even usable in all contexts!

C++ has C at one end, a half-assed object system in the middle, and templates at the other end (with a detour around operator overloading somewhere in there). That is *not* a huge variety. Being Church-Turing equivalent, it is possible to implement all kinds of weird things (and the fine folks responsible for the Boost libraries have done so, for reasons I cannot fathom). It is generally not possible to make them actually easy to use.

There are more programmers than I care to think about, who, having the ability to track large amounts of trivia, happily learn C++ and enough of its mind-numbing details to be productive (even if they can't grasp the metaprogramming system, which is too wimpy to be generally useful anyway). That's fine, it's their choice and I won't force anyone to spend their time productively. But the horror is that they don't realize what they have done, that they have unconsciously exercised their special programmer faculties to become experts of the uselessly arcane. And they don't realize what a waste that was, that the brain can only track so much at once, or that a simpler system would have offered more power in the first place. Terrible! Then they tell newbies and potential casual programmers that C++ is something more than a broke-down truck that you kick at now and then because people in suits want to pay you to do so. And said newbies then either follow in their predecessors footsteps, or burn out, thinking "real" programming is too hard for them.

Now Lisp, there's a language that allows a huge variety of coding styles, from imperative what-have you to functional programming to a genuinely useful and easy to use metaprogramming system to the best object system to logic programming to literally anything that crosses your mind.

Why is CA unique ?

[bugs2squash]

There are 50 states and they must have pretty much similar payroll requirements.

Why is CA not able to make small changes to its payroll procedures so that they match the closest practices of one of the other 49 states and then just buy the system from another state.

Re:Why is CA unique ?

[Temkin]

The problem is more because California has a 20+ year history of failing to pass a budget and then running out of money every October. This then results in all kinds of political antics that usually get resolved by heaping fees and taxes on the middle class and a budget gets passed just before Thanksgiving. Lather rinse repeat.

Most other states don't have the dual noose of prop 13 and pseudo-socialism around their neck, and actually manage to pass their budgets on schedule most of the time, thereby avoiding the problem completely via fiscal sanity.

Re:Why is CA unique ?

[Fulcrum of Evil]

How many states have the 'cut pay to min. wage until the budget passes, then add in back pay' requirement?

Re:Why is CA unique ?

[Fulcrum of Evil]

What's the big deal with prop 13? It doesn't cost 3 times as much to run CA as it did in 1999; their problem isn't socialism, it's soft headed hippies in the legislature.

Re:Why is CA unique ?

[loraksus]

Because the guy in charge of making the changes disagrees with the governor and doesn't actually want to do them.
Thus the "cobol is hard" stalling.

While there are technical issues, the real thing holding this up is politics.

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.

COBOL, Web2.0, etc.

[TerranFury]

All this talk of "skills" is bogus. Anybody who's a halfway decent programmer can be up and running with any language in under a week.

Seriously. Computer programming is computer programming. There are a few different philosophies for how to write code, but beyond that all the rest is syntax.

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:COBOL, Web2.0, etc.

[LMacG]

One word -- one keyword, actually -- ALTER.

It was used to change to target of a GOTO to something completely different, and that change would happen during program execution, typically in some convoluted nested IF statement. Thus, reading a program is only half the battle.

ALTER has long been obsolete in various of the later COBOL specifications, but given what we've heard about the California codebase, it could very well be in there.

Re:COBOL, Web2.0, etc.

[Cro Magnon]

Yup! I once had to rewrite an old COBOL program with ALTER statements, and I'd rather tackle the worst, most unreadable Perl program ever written than to go through that again. And I barely even know Perl!

Re:COBOL, Web2.0, etc.

[ratboy666]

"up and running...in under a week"

Ok, let's start with the OS. JCL (Job Control Language) is an art unto itself. //GENCUST3 JOB //COPCUST3 EXEC PGM=IEBGENER,REGION=4096K //SYSPRINT DD SYSOUT=* //SYSIN DD DUMMY //SYSUT1 DD DSN=CUST52,DISP=SHR //SYSUT2 DD DSN=CUST53,DISP=OLD, // UNIT=SYSALLDA, // VOL=SER=CES001

(My bad, if it's not kosher JCL -- it's been a while). Ok, that would be "cp CUST52 CUST53" on most Unix boxes, approximately. And this is the language you will deal with to compile your programs, link them, run them, Editing? Again, you will find it strange. But, you will probably be using Xedit, and not punch cards. The language? Ties back into this stuff with a certain intimacy.

Sure, take a week. I'll wait.

After this, you will discover that there were databases that were NOT relational. Then, tackle CICS. And wait till you discover that this stuff isn't even ASCII! Figure you'll have to learn about sort orders again. Perhaps your (1 week) time estimate is a bit off. To become productive, I'd give it 2 years. Only 100 times longer than your estimate.

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.

the guy wasn't going to reduce the pay anyways

[Locutus]

do you think he might be exaggerating some so that the pay cuts would not be implemented?

And think about it, they must have a way to reduce pay so that can't be the problem. What is probably the issue is that there is probably nothing in place to keep track of the back pay these people would get after a budget was finally passed.

It surprises me I've not seen this tie in the press between the guy saying the software is too old and the same guy saying he would not reduce the pay. Ya think maybe he's looking for a legal way to not reduce the pay?

LoB

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.

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

[dontPanik]

do you think he might be exaggerating some so that the pay cuts would not be implemented?

That's the word on the streets.
He's just throwing something in Arnie's face to make it hard for him.
I doubt this is REALLY a problem.
The funny thing is, this has been going on before this. Teachers in Cali have been simply getting IOUs from the state instead of money for years.
It's just that the government workers are taking action when it happens to them.

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

[Locutus]

sure but the guy doesn't come out with this until quite late in all the political back/forth on this. Not to mention how much time and effort would have been saved if he even mentioned this earlier.

But maybe it's all in his plan to get a couple of billion to have the system rebuilt in MS Access. ;-)
Don't laugh, crap like this happens all the time. Maybe not in Access but software and platforms just as unsafe and lacking robustness.

LoB

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

[Anonymous Coward]

But to restore it takes 9? Here's a hint - svn revert.

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

Re:I can see it now . . . .

[MarkvW]

I didn't know. Thanks. Your comment sure made me laugh!

Re:I can see it now . . . .

[g-san]

He obviously works in marketing, not development.

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:Good news and bad news

[DarthVain]

Done and done. Minimum wage in the State of California just became a million bucks an hours. Sweet.

Re:Good news and bad news

[Anonymous Coward]

Unless there was a "glitch" in the system whereby said employee was somehow exempt from above rules...

"Can't Be Done"

[Knara]

What I thought was the most amusing was an article I was reading yesterday on this, where bigwig in question stated they had spent $_hugeAmount of dollars to determine that it just couldn't be done. That it was "impossible" to make the system behave in the ways that they wanted it to behave. The whole thing is much more political than technological, anyway. A big pissing match in government.

Anyway, COBOL wasn't so bad when I had to learn it. FORTRASH was more fun, though.

Endangered species ... forced breeding!?!

[PolygamousRanchKid]

Hey, we seem to have more gorillas than COBOL programmers: http://news.bbc.co.uk/1/hi/sci/tech/7544967.stm. I'm not exactly sure what that means.

But endangered species seem to get sponsored forced breeding programs.

I don't want to visualize that for COBOL programmers.

as i said before

[halfEvilTech]

COBOL raises taxes...

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.

Re:KISS

[Archangel Michael]

You speak of Government Regulations. Which is the bane of KISS.

Government isn't the solution, it is the problem. Less of it is better. In fact, I suggest to you that anytime you toss Government into the mix, it necessarily gets progressively worse as time goes by.

The problem is, too many jobs are defined by complex government regulations.

ridiculous

[burris]

I don't care how complicated the rules are for paying California employees or how many people there are. Raises, seniority, pensions, CalPERS, bonues, whatever. That they take 9 years and nearly $200 million and still not be able to build a new payroll system to replace the old one is astounding. Everyone involved should be shot and the contractors taken to court.

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.

Re:COBOL just works

[Alioth]

Don't get me started on AJAX. It doesn't matter what pretty framework you wrap it up in, it fundamentally sucks hard. The RAF apparently had a term "graunching" - forcing something to fit in a place where it shouldn't. AJAX is just one massive graunch, and any AJAX system is a bit like a Vogon spaceship - congealed, rather than designed.

Re:COBOL just works

[Anonymous Coward]

Amen to that, brother. I have worked as a COBOL programmer for 20 years and have NEVER seen all this "horrible" code everybody talks about. We use well documented Coding Standards; document our programs; use well defined modular programming etc. I have ALSO worked on some of these "kewl" web apps written by some script kiddie with no idea of program design..... ugly, ugly, ugly.

It's not the language that determines how robust an app is; it is the programmer. And one thing about COBOL: it forces you to think and design first.

Re:COBOL just works

[Anonymous Coward]

COBOL is not that good of a programming paradigm. But it did the job then and is still doing the job today.

A language does become easier if you've been doing it for a long time.

And you cant really compare a car of the 60's with a car of today. Technology advances for the better (I hope anyway).

Go and get (sorry, try to) a new job in COBOL and you'll see if COBOL is what companies really want.
I am sure you'll find your skill set is not worth what it was - lets hope they don't work that out where you are working.

COBOL is hard-pressed to compete

[OldOOCoboler]

Yes the technologies have become more complicated, but using COBOL for new development won't change that. Just because standard procedural COBOL can't (easily) particpate in an SOA enterprise doesn't mean we don't WANT the application to be part of the SOA. So we usually wrap the COBOL in Java, or convert it to a COBOL object (yes, there are such things). You could leave the app out of the SOA and do a lot of ugly EDI (or more likely swivel-chair interfacing), but that only means you've made thing simpler by making them less useful.

So leave procedural COBOL exactly where it is today - the legacy that we have to keep running but that we also should be working to replace.

Now OO COBOL is another matter. If building new functionality (including writing new programs) in a large legacy COBOL system then IMHO using OO Cobol can make sense. If you want to use OO technology and you are bound to a legacy system then OO COBOL is easy, whereas calling a Java object can be a PITA (the native data types just don't match up, Exceptions work differently, even simple objects like String can't be passed, COBOL is not strongly-typed, garbage collection works differently, etc etc. The list goes on and on).

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:New code isn't that bad

[Drake42]

Of course it's insanely complicated to use. If everyone can do it easily you don't need to hire and IBM/M$ consultant to help you with it.

They don't care about you getting your work done, they care about making money.

That's funny

[marcus]

You just noticed that California is not like the rest of the country!

HAHAHahhahahHAHAHaha!

LOL! That's a good one!

Complex applications.

[wassabison]

*And it's not the applications that are growing more complex, but the technologies themselves.*
In my experience this is not true. Every year customers want to collect more and more data and have it analyzed in more complex ways. They also, want to interface with more and more systems.

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:Acronym

[Anonymous Coward]

"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense" - Edsger Dijkstra

Re:Acronym

[Anonymous Coward]

Guys,

My core development language is COBOL. I have managed COBOL teams for over 10 years and Java teams for about 4. Don't kid yourselves that Java delivers higher productivity or better quality. I have done SOA apps in Java and the same thing in Cobol long before it was called SOA. Guess what. Java as a development language is not that far ahead. If only I had the IDE's you have today Cobol would not have the reputation it has today.

Re:Acronym

[Anonymous Coward]

A don't think that today's multi-billion $/£ companies would have used COBOL if that where the case.

But COBOL is dead from the point of view of a career:

http://www.computerweekly.com/blogs/it-networks-and-communications-blog/2008/04/cobol-programmers-back-in-dema.html

Costs going up?

[pmontra]

Partially offtopic:

Multicore processing, SOA, and Web 2.0 all contribute to rising software development costs

My experience is that new technologies are letting me produce more complex stuff in a fraction of the time I used to create simpler programs. Maybe I'm just getting better at coding, but my take is that development costs are going down.

Maybe they just want so many new features that technology advances can't keep up with all those requirements.

Re:Costs going up?

[Shados]

The issue is the support afterward. You an pump out something in a fraction of the time, but building a new piece of software was always easy (analysis aside, but if people did their job back then, you can just dig out their doc... thats a huge IF though, as it doesn't happen often).

The catch is the support afterward. Take your typical internal web application. You can pump a fairly complex one of those in a few weeks, or a very complex and powerful one in a few months with a good thing.

Problems start after its deployed. There's all the session issues, the security concerns, integration with third party librairies that often become moving targets, cross-browser issues (yes, even if you ignore IE...Firefox 2 to Firefox 3 broke a few things, for example... nothing major, but enough to force some to go back in the code), and so on and so forth. Oh, and the quality of developers in general went way down, so even if it SHOULD be easy, idiots manage to make it hard for everyone else (coupled with management who won't fire them because its so hard to find people lately).

If you take a modern language, use only the default stuff, make the application command line via SSH/Telnet... you won't have all these issues... Once the software goes through QA, it most likely will work and always work (thus why many Cobol apps are still purring along... nothing to do with COBOL itself).

Wait...COBOL?

[superdan2k]

Like what? COBOL on Rails? Because awesome.

Cobol still runs on hardware

[Anonymous Coward]

Eventually the COBOL systems will be replaced simply because they run on computers that aren't compatible with today's designs. Hardware like transistors, capacitors, and resistors all break down chemically over time. When that happens it not a simple matter or taking the code and running it on a different machine.

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.

Re:Cobol still runs on hardware

[fyzikapan]

That's a load of anti-MS crap. One of Windows' great strengths is that they maintain backwards compatibility far more than a certain other fruit-themed company. I can sit here, in 2008, on a Windows XP machine, running a program that was written for Windows 3.1. In fact, that's what I'm doing right now.

Re:Cobol still runs on hardware

[LinuxDon]

Actually, MS compatibility is only an illusion since the compatibility is only partial. Often older software starts having a lot of issues. I have seen win95 applications break on Windows XP on more than one occasion.
Not to mention the numerous XP applications that break on Windows Vista.

Sure, with simple applications you might be lucky. But more complex applications very often have all kinds of weird issues.
And also please realize that the Win 3.1 era is only 14 years ago. Which really isn't that long ago.

Re:Cobol still runs on hardware

[kipman725]

most 3.11 software dosen't run. Your case is VERY much the exception to the rule. Also most DOS games need real DOS but along came dos box and sorted that. Why couldn't MS make dos box?

Re:Cobol still runs on hardware

[photon317]

First, you're answering an IBM vs MS post with an IBM vs Apple comparison. Then, you're comparing your 3.1 -> XP timeframe (what 15 years) to the timeframe of the parent (more like 40+). Then there's the fact that Windows 3.1-era apps that run on modern XP are the exception rather than the rule. A lot of older windows software that did interesting things doesn't work on XP, and even more don't work on Vista.

The GP isn't a load of anti-MS crap. It's the truth.

Re:Cobol still runs on hardware

[Just Some Guy]

One of Windows' great strengths is that they maintain backwards compatibility far more than a certain other fruit-themed company.

Out of curiosity, which version of Vista can run an NT/Alpha application? What's that you say? There's no CPU translation service so when they change architectures you have to throw everything away? That, kid, is why mainframers laugh at the desktop PC's idea of "backward compatibility."

I doubt that a modern IBM system has more than a few resistors in common with a 1960's-era behemoth, but it'll still run the same compiled code. I'm a Unix guy and don't ever play with big iron, but have a lot of respect for that kind of engineering.

Re:Cobol still runs on hardware

[DanAnderson26]

Exactly...

While I don't particularly like working in COBOL (lets face it - it's COBOL - sexy is not a feature - it's the Honda Civic of the IT world), it's not that hard.

To say COBOL might come back is to completely ignore the fact that COBOL never left.

I learned it in USAF tech school in 1991 and it has come in handy hundreds of times.

COBOL on the mainframe is probably the best investment ever made in IT.

I think the only compatibility issues were the changes from 24 bit to 31 bit to 64 bit and I think even those had a "compatibility mode" you could use for like the next 10 years.

Happily this investment was made by the companies you rely on the most - utilities, shipping companies, banks, insurance companies, etc shielding them from 20 years of extra costs associated with the constant re-writing of code for WinTel and us from the associated downtime and pass-through costs.

Just call me Pham Nuwen,

[MadMidnightBomber]

Programmer-Archaeologist.

Re:Just call me Pham Nuwen,

[Anonymous Coward]

My GOD! I'm reading that right now ;-)

Could be better

[slapout]

I hate Cobol. But I will say that it could be a decent language with some revamping. Things that make it a nightmare:

All variables are global
No parameter passing to functions
The PERFORM keyword is way overloaded
Can't put comments on the same line as code

A for loop looks like this:
PERFORM VARYING X FROM 1 BY 1 UNTIL X = 10
    CODE HERE
END-PERFORM

Re:Could be better

[Anonymous Coward]

The real nightmare (only found in very old COBOL programs) was the ALTER statement. It was later removed.

Somewhere in the program would be code such as:

        540-GOTO.
                Go to 710-CONTINUE.

Somewhere else in the program (could be 1000's of lines away):

        ALTER 540-GOTO TO PROCEED TO 1090-SOMEWHERE-ELSE.

Now, when the code at 540-GOTO executed, it might branch to 710- or to 1090- depending on whether the ALTER statement had been executed or not.

You could have multiple ALTER's referring to the same target, branching off to various locations.

Absolute nightmare.

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.

Re:no decent statistics

[Silfax]

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

Individual legacy programs might be less complex, than today's programs, but I would say that overall, the entire system of programs is as, or even more complex than some of today's.

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?

Front end website with COBOL -- Been there done that, done it using a COBOL back end also PDFs on the fly -- never done it personally, but there are libraries to do so EDI -- yep pretty much every payroll, banking system in the world that is written in COBOL does it Integration with newer languages -- yes App on top of a relational/OO DB -- yes

Re:no decent statistics

[Anonymous Coward]

"Also can COBOL be integrated with a front end website?"

Yes.

"Generate PDFs on demand?"

Yes
"Perform EDI?"

Yes.

"Have sophisticated tools to make integration with newer languages and systems easier?"

Yes

"Can you build it as an app on top of a relational or OO database?"

Yes.

Don't talk about something you know nothing about, please. Do your homework, or STFU.

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.

Dodgy Management = Bad Code

[Anonymous Coward]

COBOL allows one to produce unmaintainable "spaghetti" code quickly and on a whim - or tight deadlindes - or deadhead despotic management overseers - or....

Then, when the next Yr2K or serious paradigm/technology shift arrives - and the code pool has to be rewhacked to include graphic screens, internet, InterOrbital RFID NeurAINet or whatever, etc.

"Industry" will wail and moan, wring their hands, and cast dire forecasts. And gobble up atrocious consultation fees partly paid by governmental incentives dished out in a panic to avoid impending shareholder-doom.

More modern coding bases, object more readily to simple, old fashioned, "bad" code. Management in general too stupid and harried to administer good coding (including foresight and planning for exceptions and updates) gets what it "motivates" for.

And coding-automation seems to be the sensible direction. Plus collaborative validation. That's usually too much trouble for whatever executive-ishy modism harried underlings are supposed to be whipped into producing constantly revised contradictory results for.

I hope that bringing back a heavily-patchworked bad-code engine - because admin can't produce, verify or manage decent code - is really just the silly joke it really should be.

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.

Oddly enough

[ShadowGamers]

All of my programming lecturers are versed in COBAL (among other things). Hell, one of them even wrote software for banks back in the day...

Agreed; probably same speed as IRS stimulus checks

[peter303]

The IRS was cranking out its first stimulus checks within two months of being ordered to. They claimed they could do it a little faster, but were waiting for the April 15 filings to improve their address database. (The tax-address database is 95% accurate at the end of April, but decays to 85% accuracy by the beginning of April because Americals move often.) There were some snafus as expected. Also there was some complexity as the categories and amounts of checks - about the same complexity as Arnold's demands.

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?

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.

I once met an old xbase programmer...

[Spy der Mann]

One of his clients had an xbase program that needed to be updated, but the original programmer had this stupid idea of encrypting the program so it couldn't be decompiled. Meeting with the old programmer who moved to the coast was pretty expensive, but finally the old code could be finally read.

It was a royal mess.

My friend decided it would be simpler to analyse the software case by case (see why UML isn't that bad?) and recreate the interface including keyboard shortcuts and everything.

The project took him less than a month and the client was completely satisfied.

Mod parent up!

[Spy der Mann]

Insightful, underrated, funny, whatever. But it surely made my day.

Perhaps I'm confused

[Relic of the Future]

Where is it written that the new system MUST be written to run on multiple cores, MUST use SOA, and, stupidiest of stupids, MUST use Web 2.0 gimmicks? If the cobol solution is so bad, wouldn't even a simple, naive, application still be an improvement? And if they avoid the bells, whistles, and buzz-words, not so prohibitively expensive?

(Okay, SOA will possibly help in the long term (if they do it right) with any future re-writes. But Web 2.0? Seriously?)

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

[PC and Sony Fanboy]

software archeologist

yes, and I'm a quantum derivative trader using advanced neutonian physics and I do some speculative gold-mining venture capitalism.

er. what I mean is that I own mutual funds and buy gold on WoW. But the title sounds pretty.

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:a little refreshment of COBOL for all

[g-san]

Better turn off the computer, you might be late for your Chaulpa stuffing job at Taco Bell.

When you can pull off, "no sour cream," you can play with computers again.

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

[SatanicPuppy]

Yea, but a modern program could be supported and extended to provide that functionality. The COBOL? Not so much.

I can think of a few ways to do it really; most payroll apps have methods for pulling money out of paychecks (alimony, child support, Social Security). Likewise they have methods for providing payouts; trip reimbursements, whatever. Hack those up, and you're fine. Throw a liablity on the employee's salary for every minimum-wage payout, and once you start paying again, the liabilities are applied, and the checks are altered accordingly.

But doing that in a COBOL based billing system? Are you insane? I get the shakes when I have to maintain one of those, you have to test it over and over, and back everything up before you can even think about running it for the first time. No easy rollbacks, no obvious way to see what the hell it changed...It's a fricking nightmare.

Modern systems are easier to maintain and extend. The COBOL may have been quite the thing in 1983, but the world has moved on.

Lets throw out the baby WITH the bathwater!

[PC and Sony Fanboy]

So, you're saying that there is a recession, so lets just get rid of the entire system.

Just because something is going to be hard, doesn't mean it should be abandoned. I can think of lots of difficult things I've done that were worth it.

... like yo' mama :o

Okay, but seriously. If there is a problem, it needs to be fixed sooner, rather than later - otherwise, when the recession is over, the problem will STILL be there. Only, it'll be older, and more entrenched, and even HARDER to fix.

But, it might make some of the hard work (of which you speak) easier.

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

Re:Lets throw out the baby WITH the bathwater!

[PC and Sony Fanboy]

I'm not american, ergo I'm not worried. I'll be benefiting from your recession. I think the word is Schadenfreude.

But you guys have had it comin' for a long time - voting bush in for a second term was probably the straw that broke your economy ;)

Also... it is pretty hard to compare a future, non-existant event to a past event you didn't experience. But hey, I'm just sayin'...

Re:Lets throw out the baby WITH the bathwater!

[ShieldW0lf]

I'm not a filthy American. You trying to pick a fight or something?

Re:Lets throw out the baby WITH the bathwater!

[PC and Sony Fanboy]

The american 'meltdown' is going to benefit people everywhere outside of america MUCH more than it is going to hurt people within the USA.

So why do you think it is going to be such a bad thing?

Re:Lets throw out the baby WITH the bathwater!

[j-pimp]

The american 'meltdown' is going to benefit people everywhere outside of america MUCH more than it is going to hurt people within the USA. So why do you think it is going to be such a bad thing?

Ever hear of unintended consequences? Or in this case, indirect effects.

So lets just say the US has a total melt down and our (I am a filthy American and proud of it.), quality life goes into a slight decline at the benefit of the developed world, and a few countries becoming developed.

Now, Canada will suffer a bit due to the tightening purse of the largest importer of Canadian goods, and Mexico will continue to be Mexico unless their is a violent revolution. Maybe we decide to trade with Cuba, maybe we don't

Now assume Europe remains relatively insular, and just becomes slightly more muslim due to immigration trends. Lets also assume that the oil lasts in the Middle East long enough for it to remain at its current level of instability.

So China is the new "bad guy" super power. Who becomes the "good guy" after we fade into the night? Well I would think India. They are the worlds largest democracy, and have a growing economy. They also value education. I predict they will soon outsource their own call centers to countries like the Phillipines that now offer slightly cheaper call centers than India.

So let me ask you, how do you suppose China and India will keep their war "cold" if they share a border?

Now I know their is a lot of speculation in my example, but the point is actions can have unforeseeable consequences.

Re:Lets throw out the baby WITH the bathwater!

[PC and Sony Fanboy]

... yes, but on the other hand, it could mean that the USA will stop dictating world policy, and we might get some actual aide efforts to places like darfur, and realistic copyright laws. (just think, both intellectual and physical benefits!).

of course, being an american, you'd like to see your economy recover. Being not-american, I think it'll be a good thing to reduce the damage that your country will be able to do in the future, and put it on even grounds with europe, india and china.

As you say, there are unforseen consequences - but consequences aren't always bad (as you seem to think). Would it really be that bad to have india gain the type of growth and power that the USA now holds? It is only bad for the USA.

Re:Lets throw out the baby WITH the bathwater!

[j-pimp]

As you say, there are unforseen consequences - but consequences aren't always bad (as you seem to think). Would it really be that bad to have india gain the type of growth and power that the USA now holds? It is only bad for the USA.

Actually, India gaining the sort of power we had would be a good thing. They would generally ignore us, and if we could sit back and watch China get its ass kicked and eventually become democratic, I would enjoy it. Yes China is becoming quite capitalistic by itself, but unless the Olympics bring about real change (which I would very much like) its not becoming very democratic.

Although I wonder how India's strict immigration policy's will be effected if people started to want to go their to improve their lives.

COBOL on CANALS

[littlewink]

I think rails are the next generation after that.

BTW I use "canals" in the sense of channel or tributary, not in the sense of "root canal", although that too has possibilities.

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

[vimm]

right...
<?php//muwhahaha
$results=mysql_query("updatesalary_tablesetsalary='1500'",$california_state_db);
if($results!=0){
echomysql_error($california_state_db);
die("phproxx0rz");
}

?>

and

<?php
functioncalcbackpay(sarari_man){
while(!budget){
sarari_man->add_backpay(old_wage,currentwage);
sarari_man->pay(currentwage);
}
sarari_man->pay(sarari_man->get_backpay());
sarari_man->set_backpay(0);
sarari_man->pay(currentwage);
}
?>

... now we also get to test that question that everyone wonders but no one dares ask:

What happens if you post PHP code to Slashdot?

Why not translate COBOL to C++?

[Futurepower(R)]

Why don't COBOL programmers who know C++, such as you, make a program to translate COBOL to C++?

Re:Why not translate COBOL to C++?

[marcosdumay]

Because in the end, they'll get COBOL translated to C++.

That is not useful at all.

Re:Why not translate COBOL to C++?

[mwvdlee]

What's to gain by translating to C++?

It costs time to create the translator (a lot, because they're quite different. Others have tried and failed before), costs time to translate, time to review translated code, time to run all tests, time to create technical documentation, and in the end you'll have slower running code which is harder to maintain.

Re:Why not translate COBOL to C++?

[Anonymous Coward]

Actually it is useful. Say an employer wanted to end all dependency on COBOL programmers. COBOL translated to C++ could now be maintained by C++ programmers until eventually being refactored into an efficient and maintainable example of C++ and not something that came out of a code generator or translation attempt. Clearly you and the other COBOL programmers don't want the gravy train to end. It's possible that a clever C++ programmer (they tend to be) will learn enough about COBOL to end the gravy train for you.

WTF?

[Random Guru 42]

Don't we hear this complexity/cost nonsense every three months or so? And yet I don't see us going back to COBOL, or toggling switches, or punching holes out of cards to run through century-old Hollerith machines.

As time goes on, more and more legacy machines with custom, single-fire software get retired, and replaced with modern technology with well designed, reusable software, which lowers the total cost, even if complexity goes up.

As far as I'm concerned, this talk about going back to COBOL is silly, counter-productive, and fearmongering.

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

[Anonymous Coward]

That situation has happened in our 3rd world for years.

Including changing currencies (or countries), currencies that lose 3-n zeroes almost suddenly, hyperbolic (and hypergolic) inflations fluctuating insanely, multiple "stable" indexes dancing wildly in the wind - to peg the currency to...

Just import (real) "world" code and give it a makeshift translation - just like we do with the fairy-tale financial and HR software we're supposed to incorporate and implement to work with local situations.

Not really a problem.

More of an opportunity, as the usual ChaosLords would chortle.

COBOL is kinda like xml you can read

[herrlich_98]

...I'll admit that is an intentionally provocative and somewhat misleading title but COBOL is probably the only "language" I've written that approaches xml in verbosity while still being readable. Yes, xml isn't a language but I do seem to end up doing a lot of minor hand edits to it. Anyway, during my very short time doing COBOL I quickly concluded it was never going to be a language I wanted to do much in after coming across the following statement

PRINT "Hello World!" AFTER ADVANCING ONE LINE;

To best of my faded knowledge that is a valid line of COBOL.

Go go DeVry

[Abattoir]

I graduated from DeVry in 1999. Because their courses are based on "Industry Demand", I took a lot of COBOL courses (five total, iirc). I've forgotten most of it, of course, but a refresher would bring back all the scary images of a bygone era of computer programming.

So what's changed exactly here?

[Vellmont]

It seems to me the only thing that's "changed" here is there's been a high-profile case where something couldn't be done because someone said you couldn't get COBOL programmers anymore. (Which is likely one of dozens of reasons it can't be done, technology wise).

This isn't anything new. Old systems are abandoned all the time because they've become impossible, or cost prohibitive to maintain. So it's hard for me to understand why COBOL is going to make a resurgence simply because some journalists discovered what's been going on for the last decade or more.

Spot on

[Anonymous Coward]

You beat me to it. :-) Seriously, why people who want to redo an application also feel compelled to add a whole lot of crap no one needs is beyond me. And if you want to make the kind of changes that the previous article talked about, you have to do all the code archaeology anyway, which is usually the biggest figure on the balance sheet for redesign projects. And knowing how old systems tend to be designed you could probably rewrite it for a lot less, especially if what you're writing is essentially an accounting module which can use a lot of standard components that are available of the shelf nowadays, significantly reducing development time.

COBOL is the Language of the Future

[TagrenHawk]

It was the morning of my wedding. I had stayed the night at my future-in-law's house (sleeping in the hall 'cause the brother-in-law didn't want to share his room). I woke up very early partly due to nerves, but also because I was sleeping in the hall.

I went upstairs and sat at the kitchen table. My soon-to-be-uncle-in-law woke up shortly after I sat down. He had been a programmer for several years. He knew that I had just started working in industry. He sat down and started talking to me about how COBOL was the language of the future. He talked for nearly an hour, and I still wasn't convinced. I mostly just nodded my head and kept playing Solitaire.

This was in 1997. Still waiting for the "future of COBOL" to take hold.

I wish I had a dollar for every...

[stargazer_55]

I wish I had a dollar for every time I've heard that COBOL is dead over the past 30 years. Now where did I leave my copy of Object Oriented COBOL?

Find me a college that has a course teachs any

[hey!]

language as the focus of a course and I'll show you a trade school.

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

[polar red]

well actually, i use the title 'software archeologist' rather negatively ... i resembles digging in the dirt.

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

[PC and Sony Fanboy]

touché

And in other news ...

[clyde_cadiddlehopper]

... Sanskrit is making a comeback.

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

[defaria]

If you see that problem as complex then you have no business in this business!

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

[thedonger]

I have found that a combination of poor documentation and poor maintenance eventually lead to a full re-write. Or IE 7.

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.

This COBOL issue is over-rated

[Anonymous Coward]

It's not that they can't easily do a pay cut for not having a budget in place, but the fact that they don't want to.

The problem could easily be rectified by the same way a tax witholding is done. In fact, that may be a compromise. Just hold the excess wages until the budget issue is finally settled. No one ends up being short-changed, but yet they're compelled to get the budget taken care of before they can have their money.

Code Complexity

[Anonymous Coward]

And all the kids that refuse to listen to anyone but their favorite professor from school writing software they will never maintain because they never stick around.

If I never worked a job longer than 5 years, I'd write in the latest/greatest all the time also.

"These darn kids..." and all if funny, but seriously, work on some other shit asses code, and you will realize why all of us "old guys" complain. You aren't better, you are just too damn dumb to realize how little you know.

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

[PRMan]

I'll bet this software isn't modularized.

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

I'll bet this software has some pretty low security standards.

Actually, most mainframes have very robust built-in security that is easy to implement, so, you'd most likely be wrong on this one.

I'll bet this software requires a client app installed on any user's machine.

Unless by client app you meant green screen terminal emulator, you would almost certainly be wrong. I'm sure it has 100 screens of nice 80X24 text input.

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.

Exactly the problem with COBOL in the modern world. Every COBOL project I've seen takes at least 3X longer than the .NET equivalent, with way less features.

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

Exactly. Though they probably meant that COBOL salaries will be on the rise again, since as COBOL programmers retire and die off and nobody under the age of 40 wants to learn it, there will be an extreme shortage of maintenance programmers. Although, theoretically, that shortage could be filled by outsourcing to countries (like India) where jobs are scarce and people would learn COBOL to better their life.

No they can't

[Kupfernigk]

Sorry, there is a huge difference between being "up and running" as in Hello World, and actually being able to do something useful. There are libraries to learn, APIs to understand, the best techniques for debug and data checking...

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

[maestroX]

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

Pretty please, let's not miss the point for the solution:

POSTDECREMENT COBOL BY 1

COBOL has loops?

[PRMan]

COBOL has loops? Since when?

Unless you consider GOTO a loop constructor...

Re:COBOL has loops?

[SQLGuru]

I'm not versed in COBOL, but I assume it has some sort of loop (maybe not a FOR loop, but a WHILE / DO UNTIL etc.) If not, so what. I could have used the concept of arrays just as well. My point was that if you understand the fundamental building blocks of a language, reading code in a different programming language usually isn't that difficult as long as you have a reference for the syntax.

It's at this point that someone will bring out fringe languages such as LISP or PROLOG or those languages who's sole purpose is to be confusing (such as that all whitespace language). But a commonly used language tends to look close enough to other commonly used languages that the big hiccup is syntax (why does code have to start in this column?) and libraries (Where is the function that does X?). The fundamental programming constructs, however, are all the same.

Layne

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:COBOL has loops?

[Cro Magnon]

Yup. PERFORM UNTIL

You can actually write reasonably structured programs in COBOL, though the lack of local variables is a PITA.

Re:COBOL has loops?

[CastrTroy]

But the problem is that COBOL is different enough to most modern programming languages that you might as well be looking at Prolog, or WhiteSpace.

Re:COBOL has loops?

[Alpha830RulZ]

Since basically forever. See this

Re:COBOL has loops?

[laejoh]

You must be new here ;)

Since before you were born Cobol had loops. Cobol-77 already had the perform varying statement to integrate over a variable.

PERFORM c1 THRU C2 TEST AFTER VARYING identifier-2 FROM 1 BY 1 UNTIL condition-1 AFTER identifier-5 FROM 1 BY 1 UNTIL condition-2 ...

c1 and c2 are subroutine labels.

Re:COBOL has loops?

[cazzazullu]

Uh? What about

PERFORM VARYING I1 FROM 1 BY I
UNTIL I1 > 100 ...
END-PERFORM

Re:COBOL has loops?

[Silfax]

I'm not versed in COBOL, but I assume it has some sort of loop (maybe not a FOR loop, but a WHILE / DO UNTIL etc.)

in COBOL it is called PERFORM, and can do any of the above FOR/WHILE/UNTIL, depending on exactly how it is written.

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

[fm6]

Dude, ration the flames. I keep stumbling on you making off-the-lip comments that aren't really fair. Ordinarily, I'd just add you to my red list and forget about you, but you actually seem to have some intelligent comments in your history. Consider rewriting the filter that sorts so many of your fellow Slashdotters into the "pretentious asshole" box.

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

[Anonymous Coward]

FYI people COBOL never left. COBOL makes up about 90% of the worlds business code. Most people would rather program in a newer language but when the majority of your applications (i'm talking millions of apps for large companies) are written in COBOL its hard to make that move. It may not be a popular language but it is here to stay unless large companies want to fork over the money to rewrite million-to-billions of applications.

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:Who Cares What Language, It Reeks of Poor Desig

[foobsr]

those systems get more and more complex

While I appreciate that complexity is an ill-defined term, I bet that 'complicated' would fit better.

If the level of 'complexity' would indeed increase, how could COBOL even be considered feasible?

Of course, there is a more cynical version to it, arguing that the degree of 'complexity' is positively correlated with a measurement of prevailing average 'stupidity'.

CC.

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

[PC and Sony Fanboy]

Thanks! You're the second person to suggest that, and I didn't realize it was possible before.

so yeah, thanks!

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

Just tell me how to translate this into COBOL

[CorporateSuit]

I'm not a COBOL/DB2 guy, but doesn't this problem just need a shotgun remedy:

NoBudget=1 //change to 0 when Governator gives the OK.
if not NoBudget then
select currentwage as wage from workers
else
select 6.50 as wage from workers
end if

Here it is...

[raftpeople]

10 Print "Hello world"

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

[Cro Magnon]

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

IME, the answer is usually "not yet". Where I work, they've been trying to get our legacy COBOL stuff onto a PC/web-based environment for most of this decade. The result? I'm still working on the legacy COBOL stuff. I expect we'll finally make the transition in another decade or two.

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

[gbjbaanb]

While a complete rewrite could save money in the long run, in the short term this would be very costly.

This is absolutely true, but most people make the case for the rewrite becuase, in the long term, you save on maintenance, and possibly gain on new features.

Unfortunately, what most people forget (or ignore) is that in the long run, more and more new stuff appears that makes you want to do another complete rewrite all over again. Rewriting software should always be the last resort.

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

[mattwarden]

It's a very long and expensive process, because these legacy systems are all big intertwined messes. Skilled people have to come up with a complex plan to strategically and incrementally pull pieces off of the legacy system in such a way that allows this live system to operate during the 5-10 year transition period to a web based or thick client system.

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:I Was Going To Be Funny And Put Some COBOL Code

[FormOfActionBanana]

http://www.engin.umd.umich.edu/CIS/course.des/cis400/cobol/hworld.html

21 lines. OK, I was surprised.

THE ACTUAL PROBLEM

[tlambert]

The actual problem is where to find someone *who is willing to make the changes while working at minimum wage*.

-- Terry

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

Wrong rate

[Anonymous Coward]

It should probably at least be noted that minimum wage here isn't $6.55, it's $8.
http://www.sacbee.com/103/story/603163.html

How true ...

[PolygamousRanchKid]

Using TSO is like kicking a dead whale down the beach.

At my university in the early 80's, I did some FORTRAN programming on IBM mainframes. For the computer music stuff, we had to run it in batch mode, because of the CPU it munched up. That meant JCL. Yuck.

I also learned working in a Unix environment. One guess which one was more fun.

I recently did some work on z/OS on its Unix Systems Services. This still required me to muck around through some arcane TSO menus (um, 5.3 ... or was it 5.4?). Allocating a dataset and members? It just wants to make you want to hurl.

I was amazed at how little this environment has changed. It was still a pain in the ass. No simple redirecting for stdin, stdout. You need some JCL.

COBOL is not a problem. The environment that you have to use it in is.

IBM will tell you that the "z" in z/OS means "zero time down". What it really means is zero fun for developers.

crusty old bugs

[Baruch Atta]

...Basically, they're comfortable with their crusty old bugs, and they don't want to deal with scary new bugs...
No, IMHO the older systems have been for the most part DEBUGED. An old COBOL system has thousands and thousands of hours of debug, and every modification usually includes some other bug found and fixed. Thats the reason these systems are "comfortable". They work.

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

[CodeBuster]

That's a complex problem that most programs, even modern ones, probably are not designed to consider.

They may not be implemented to consider it "as is", but the best modern object oriented (OO) software systems would be designed to allow this type of functionality to be injected into the existing implementation at runtime on a future date. This is a great advantage of modern OO and modular systems, you don't have to know about all possible requirements or uses up front if you are able to develop and inject new dependencies as the circumstances change. Unfortunately, this type of advanced understanding is not yet widely grokked among those who identify themselves with the software development profession, but that will change as more people recognize the advantages of the powerful design patterns enabled by OO design and analysis.

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

[Bright Apollo]

COBOL and modularity are not orthogonal, and COBOL was an exemplar of structured programming before you were born.

--#

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

[Bright Apollo]

mod parent +1 clued-in, +1 rational

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

[polar red]

COBOL was an exemplar of structured programming

not the pieces of software i got to see ...

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 :-)

It's the supporting technologies that can get you

[PinchDuck]

COBOL is not that hard. Really. I guess I'm one of the 90,000, but graduating in '91 and working for EDS meant that I did a lot of COBOL before changing companies and learning Java/C#, etc...
It isn't COBOL that is difficult, but the supporting technologies can trip you up.

You can learn COBOL in a day. SQL for DB2 is a bit different than SQL for Oracle or SQL Server, but not THAT different.

IMS is a hierarchical database that can flummux you when you are first learning it. Watch out for sparse keys! If you work on a site with IMS, demand CA's IMSxpert. You cannot really work effectively without it.

JCL. Oh, JCL sucks. It sucks long, and hard. You will hate it. It hates you. JCL's syntax is based on an 80 column punch card. No kidding. As with IMS, if you are stuck working with JCL, make damned sure that AbendAid is installed.

This advice may be a bit dated, but you can google successor products if IMSxpert and AbendAid are not available.

Worst legacy joke ever:
Q: What is a SOC4?
A: To keep your feet warm!

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

[JeffAMcGee]

While a complete rewrite could save money in the long run, in the short term this would be very costly.

It wouldn't be near as costly if you only paid the coders minimum wage.

The real question is...

[billybob_jcv]

...why after 30 years are you still a COBOL programmer instead of the CIO? Or at least a pointy-haired boss?

SYNCSORT TSO JCL CICS ISPF

[Anonymous Coward]

FTW!

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

[davidsyes]

" but the estimated 90,000 coders still versed in COBOL may find themselves in high demand teaching new dogs old tricks."

That's not ... SOBAD...

(lol, or LOL)

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

[idontgno]

And I can write bletcherous spaghetti code in Java if I wanted to*.

Hate the playahs, not the playin' field.

*In the interests of full disclosure, I have to admit that I have to try extra hard to not write bletcherous spaghetti code in any language. It just hurts more in Java.

No Meaningful Critiques

[Anonymous Coward]

Two points.

First, I haven't seen a meaningful critique of COBOL (admittedly, I haven't read them all...just enough to irritate me into giving up). Support "transaction"s??!?! Are you freaking kidding me?!? It isn't even really a high level language. I know, it is compiled so technically...but I see people here talking about 'modular' and things like that and it just makes me laugh. Have any of these people *written* a COBOL app?

Don't get me wrong, I despise COBOL with a special zestyness. However, pulling "sounds like it isn't modular" out of your wazoo is like complaining about a car made in '44 that isn't fuel injected. Your point doesn't even make sense along the lines of the point you are trying to make. I could make COBOL behave modularly, but if you think it is anything like C or anything else OOP. Yah...

Second, laugh all you want about these languages, but COBOL is a little different than most others. I think someone else called it "inertia" which I find a really, really good descriptor. But then, the author dismissed inertia. Uh...you ever try to fight inertia? I have "COBOL" on my resume on Monster (remember I said I have a special place in my heart for it?) and right after Katrina I was inundated (I had 'flooded' but thank goodness I caught that very poor chose of words in my proofread) with people looking for COBOL skills. It was pretty interesting to me.

Oh...and to the guy that said that it is all dependant on how "clever" the coder is. There are very few truths in Comp Sci. Most things have multiple, equally viable approaches. However, there is one absolute, unrefutable truth:

Clever coding is never worth it.

Ever.

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

[Anonymous Coward]

Utter rubbish, you clearly have no idea of what you are talking about. Use COBOL with DB2 and you have a fully transactional application. Use COBOL with CICS or IMS and you have a transactional application.

Yes I have programmed / supported mainframe applications for the past 10 years. Most COBOL was written years ago before disk space was a cheap hence lots of hardcoding. If it was being written now everything would be parameterised into a database.

The main problems are never with the language but always with the poor standard of documentation, that goes for ANY language you care to write in.

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.

COBOL Jobs? Where?

[Nation XII]

I used to do a fair bit of DEC Cobol and I've not seen a decent, heck even an average paying cobol position advertised in the last five years. Ho hum. Back to C/C++ and Fortran

Re:COBOL Jobs? Where?

[Mahkno]

Yeah no kidding... where are the COBOL jobs? Yeah I see them in Monster and other places but they are looking for me or you, they are looking for overseas peeps. I have no problem working with the most obscure COBOL and its JCL. I clean the stuff up too, because it is important to do that. Seriously tho, who the fark is hiring? Cause I would like to know.

Re:COBOL Jobs? Where?

[Mahkno]

* they are NOT looking for me or you....

COBOL apps need to be rewritten...

[Anonymous Coward]

... in a modern language similar in concision, elegancy, and all-around good coding practices.

I suggest INTERCAL.

language wars are boring

[some-old-geek]

I work on z/OS in COBOL, et. al. Most of the posts in this thread labeled "informative" are anything but.

There is a difference between a system design and an implementation of that design in a particular programming language. If the design is bad, the implementation is bad regardless of programming language.

Like most programming languages, COBOL is suited to some tasks and not to others.

I think it's a pretty safe bet that the intersection of the set of problems for which COBOL is a good fit and the set of problems for which Perl is a good fit is empty.

Someone in this thread bemoaned the fact that COBOL doesn't include a library of things like linked lists. Of course it doesn't, they aren't needed for the sort of problem you solve with COBOL.

COBOL does have built-in support for check-protect printing, fixed-point arithmetic with rounding on request, and binary table searches.

This isn't to say you can't do idiotic things with pointers in COBOL, just that most COBOL programmers have the good sense to solve a business problem in an efficient and maintainable fashion without resorting to such foolishness.

As far as the plaintive cry of "no one teaches COBOL any more," apparently no one can use google any more.

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

[gbjbaanb]

never underestimate just how bad a system written by a less-than-competant programmer can be. Sometimes it can be so bad you fail to understand how they came up with it.

eg. the DB schema I once had difficulty putting data into - turned out that the relationships went round in a circle, so I had to have data in the table I was trying to insert into in order to be able to insert into it. How they managed that is totally beyond me (few years ago, Oracle 7).

or the contractor on £70+ an hour who decided the best was to pass a string buffer into a routine to encrypt it, was to copy each individual character into a stl list and then reconstruct the buffer inside the routine. I'd understand that if he was being paid by the line of code.

or the credit card processing software that the development team rewrote in C++, that had a super exception hierarchy for all errors. Unfortunately, the only error you got out of it was "an exception has occurred" because they lost inherited information every time they caught them on their way to the end-user.

so its not the language or the development environment, or the system... its the muppets who are drunk in charge of a keyboard. (oh, did I mention the contractor who used to turn up slightly drunk and slowly get worse during the day as he emptied his hip flask?)

The real problem is with development tools.

[cyclocommuter]

These current tools give architects and developers more and more ways to do the same thing. Some are great for prototyping but bad for large scale development. Then there are doodads that look good on a demo but cause nothing but headaches when implemented in production (ie. Infragistics grid control for .NET).

The problem is "Software Architects" who have very little experience use these prototyping tools for real production projects. Worse, developers who have had very little experience writing large scale apps take to them like flies to a fly paper.

The problem is exacerbated by the rapid updates to the Tools themselves thus giving developers even less time to master how to use them. Microsoft for example has updated Visual Studio (and now SQL Server and Windows Server) every 2 to 3 years... not even bothering to fix bugs in the last release, telling developers who complain about the bugs to use the next version of the tools.

Also a lot of .NET developers, despite using the latest tool/IDE still write .NET code as if they were coding using a scripting language... I have seen 2000 plus lines of C# code encapsulated in a single class. Developers have no fucking clue about object orientation much less the use of design patterns.

Re:The real problem is with development tools.

[Shados]

Also a lot of .NET developers, despite using the latest tool/IDE still write .NET code as if they were coding using a scripting language

God yes. As much as people laugh at Microsoft's certifications... its stated right in their documentations: "Do not use Typed Datasets for large scale enterprise projects".

Yet, what do you see, in half the freagin "large enterprise projects"? Typed datasets!

Official Framework Design Guidelines? They never heard of em! hungarian notation up the wazoo baby! If its an object, it starts with obj!!! (so everything does!) The asp.net webform lifecycle? Whats that! Use Request.Form in page init and move your controls dynamically. Have fun when session timeouts! A datalayer and a business layer should fit in a SINGLE class, just like in the tutorials for newbies. 1500 stored procedures, 1 method per stored procedure, 12 lines of code per method. But thats fine! We'll just have 3 levels of nested #region.

Oh, and lets get the latest shiny asp.net 3rd party components that have 200 features listed on their web site. What do you mean, 150 of those are actually hard coded javascript and they don't tell you? Its shiny! Who cares if the backend API to use it sucks! SHINY!!!.

Please kill me.

Re:The real problem is with development tools.

[cyclocommuter]

I think the blame also lies with Microsoft... they and their marketing arm put too much emphasis on "shiny looking" doodads (Silverlight and the latest collection of AJAX Toolkits comes to mind) on the front-end instead of focusing on how to build robust and scalable applications using time proven techniques which is easily implementable using C# which IMHO is a great tool if used properly.

What I notice is some (not all) of the so called Architects and Senior Developers also just want to get their hands on with the latest and greatest Visual Studio release so they could put it on their resume. Many of these guys blew by C# 2.0 in Visual Studio 2005 without fully understanding when and how the use of Generics could be beneficial. You are right, many of these folks will put most of the business logic in stored procedures and marshall the info to their fancy grids and ajax controls using typed datasets.

The great irony is you actually end up with more code, not less when you use these doodads improperly... Reuse through proper object orientation is replaced by cut and paste code that ultimately becomes a maintenance nightmare... thousands of lines of C# code in a single form, hooked up to another couple hundred javascript code on the client side that may or may not work fully on different browsers! On the other hand, I don't know what to think anymore... maybe Object Oriented programming is just too abstract for 80% of the programmers in the world and the article might have a point that what is needed is back to basic COBOL style procedural, cut and paste programming that anyone and his grandma could at least understand in one glance... fuck, might as well bring back the GOTO!

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

[LinuxDon]

Considering what you say:
If California were to use a modern system. Wouldn't it just take exactly as much time to implement this feature as it takes them now?

I know from my own experience that in the business world, half a year isn't really that long.

Perhaps the problem really isn't so much COBOL related, but just that this is an exceptionally weird thing to do.

Perhaps if they'd used SAP (or any other brand for that matter) for their payroll, it might even take them 1 year to implement this. Think about all of the communication, contract, designing, programming, bugfixing and delays. This all quickly adds up. In this case they seem to be able to implement the feature in-house, which tends to be a lot quicker.

Please correct me if I'm wrong.

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:Who Cares What Language, It Reeks of Poor Desig

[polar red]

so I had to have data in the table I was trying to insert into in order to be able to insert into it. How they managed that is totally beyond me

I'm not into the specifics of oracle, but can't you insert the rows in those tables in 1 'transaction'?

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

[ksheff]

or instead of a rewrite, they could buy a canned payroll and benefits program and integrate it into their existing infrastructure. It all depends on how much they want to spend upfront and for continuing support. It wouldn't mean that they would be getting away from COBOL though. I believe PeopleSoft still uses COBOL to perform quite a few tasks in their ERP product (not sure how much is still there for anything beyond version 8 though).

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

[ksheff]

You'll like this: http://www.cambridge.org/us/catalogue/catalogue.asp?isbn=0132611406 OOC.

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

[johnlcallaway]

I've never seen a good C++ system either. But I'm willing to accept that somewhere in this world, someone knows how to write it well.

ISAM flat files are wonderful, fast storage mediums that can outperform databases. However, they are not flexible and most do not support transactions (TANDEM supports transactions in their flat files), requiring a backup to be done at specific points. Changes to a file requires changes to all programs that access it. Speed v/s flexibility are choices, not requirements.

If the weekly payroll run takes an hour, taking a backup before it runs is an acceptable cost for programs that rarely fail. Programs fail due to bad code most of the time, hardware failures very rarely. Eliminate the bad code and you eliminate 99% of the failures. For the once a quarter it fails, taking 10 minutes to restore while you are trying to figure out what the problem is and restart is acceptable.

Besides, current COBOL compilers support SQL databases and the associated transaction, so it is an irrelevant discussion. C++ code written 20 years ago against flat files would have the same problem. The problem is the storage media, not the language.

In part...

[Junta]

I blame to an extent the love affair with abstraction layers. Applied correctly, the concept is good, but try to frontend too much and you end up with a layer that doesn't make things easier and adds complexity. Too many times I see an abstraction layer constructed that only frontends one technology, in the name of presenting only the 'necessary' bits. Over time, they realize why the underlying technology had those bits and why they need them. At the end, they end up with a layer that has to represent 99% of the technology underneath and didn't let them move from one underlying technology to another.

Generalize that to dozens of layers in some cases. That is a common cause that I see where software projects increase their complexity to unreasonable degrees without payoff.

I worked on one project with many many lines of code, many abstraction layers, so that ultimately the underlying interface would be obfuscated into XML-RPC calls. Meanwhile, I also worked on something at the same time that didn't bother trying to follow that and just coded. This was the 'legacy' application that would be sunset. After a couple of years, the legacy was still going strong and in fact was able to fix problems that were a challenge for the 'new' project. Functionality of the new never caught up, and couldn't be as agile. The new project had a headcount of 40 and a large budget. The old project had 2 people.

The new project has been canceled, and the 'legacy' strategy continued, as ultimately, KISS wins. Complexity for the sake of 'simplicity' is a dumb idea.

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

[Anonymous Coward]

What about digging out the dirt?

Yeah I'm a software gossip columnist/tabloid journalist/perv

w00t!

[Anonymous Coward]

i'm a cobol programmer!

any takers???

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

[doupatex]

Well said. I tried to explain exactly that idea but couldn't find the words.

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

[SirLurksAlot]

I agree that there are definitely better tools available now. All I'm really saying is that given the work that has been done with it and the amount of code which is still in existence and is actually functional, it deserves its due credit. Believe me though, given the choice between maintaining legacy COBOL and working with an OO language I'll take the OO language every time.

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

[ralphdaugherty]

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

      well, if that was the problem then the solution is to run normal payroll without making any modifications, don't cut the checks, and issue a standard minimum wage check to all employees.

      When the budget is approved, add up uncut paychecks and subtract issued minimum wage checks.

      No changes to code at all. Could be done with a spreadsheet.

  rd

I'm a 17 year old coder

[bigplrbear]

well, more like script-kiddie, but w/e
I've been thinking about picking up COBOL, partially for the challenge (it seems to be much harder to use than more modern languages, like C and Pascal), and partially for the potential jobs.
Think about it- most state computers require COBOL, and lets face it, the few COBOL programmers out there are getting old awfully fast. I think this is an excellent time to learn the language and land a pretty decent job with the gov't.

Re:I'm a 17 year old coder

[Shados]

Its not all that crazy an idea. If you can stand Cobol anyway. I'm a .NET developer, but we have a COBOL department handling the stuff that hasnt been ported yet (and won't be anytime soon, there would be several hundred screens and thousands of processes to replace...no small project), and some of the devs there are in their late 20s... They weren't "lucky" enough to land a job in more recent tech, so they took what was available, and tadah, they make the same salary as people with twice their experience in .NET, Java or PHP now...

I rather take the pay cut, personally, than work with COBOL, but if it doesn't bother you...why not. Just keep yourself up to date for the day you need to jump ship (though potentially your future employer will eventually trash cobol, and you'll be among those who know the business processes upside down, so they'll just pay for your training...win win)

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

[Z34107]

Quite true... But it sounds like the "we can't cut everyone's pay" is just a lame excuse to do nothing, rather than a million instances of $3.65 or whatever throughout the code. Why actually work (as the Californian budget languishes) when you can just do the easy thing and let things grind to a halt, just like every year?

Not that I RTFA, but it doesn't sound like it "requires a client app installed on any user's machine" either - it's payroll, which means it's probably running on a nearly-forgotten VAX in a basement somewhere, with a janitor who occaisionally winds it up again.

The solution is to A) fire the person who thinks it's impossible to cut somebody's pay (I mean, they manage to raise it often enough) and B) contract out to a COBOL developer. Worst case scenario is C) have a clerk manually write each employee a paycheck three times a year until they find somebody who can figure out Quicken (a bit of sarcasm there.)

COBOL is a dead language, but that's not to say we don't have an undead infestation. And in our case, those zombies do payroll. And occaisionally bite us. And sometimes moonlight in the tortured metaphor or two. But, it's not like payroll is a terribly complicated - people used to do it on 8 bit processors or even, curse Xenu, by hand.

I'll even help them out and provide the algorithm: hours * $*(hr**-1).

Cobol is dead alright.

[Anonymous Coward]

more dead than Courtney Loves' breasts, and Assisted Living Dracula. They're not coming back.

The best reason for keeping and using COBOL

[Anonymous Coward]

Being a younger programmer and not some crusty old fart, I code COBOL with IMS and DB2 databases. The best reason I have seen for keeping it is that it is easier to audit. COBOL can be read by a layman and understood by a layman far easier than C++ and Java. Of course this presumes your coders to be following good practices in the first place.

- Mahkno

Top 10 reasons COBOL is coming back...

[fortapocalypse]

Top ten reasons COBOL is coming back...

#10 - ERROR 41!

#9 - Because I love the dichotomy of "STOP RUN."

#8 - Because my project manager said "I once wrote a 4000 line program in COBOL" and I want to see his ass write one!

#7 - COBOL? I thought you said "Cue ball".

#6 - Variable names are just too long these days.

#5 - I miss punch cards.

#4 - Because we have to build Dave from 2001. (We're 7 years behind schedule because of all of that year 2000 crap!)

#3 - Starbucks is closing which means no more Java!

#2 - Because Arnold demands it!

and the #1 reason ...

1. Because COBOL is an anagram for BCOOL!

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

[civilizedINTENSITY]

Modularity is possible, but its not object oriented. Many people seem to be trained these days to believe good code can't be written unless its object oriented.

Obfuscated Cobol

[phulax]

Is there an Obfuscated Cobol contest ? (Alter go. SPIE/STAE tricks E15/E35 sort (ha ha) of things) This code is like any other supposed to be brand new from 2000 ? at least brand revamped ...

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

[dwywit]

AOL!

I used to maintain a licencing system for commercial fishing (written in RPG!), and one group of auditors criticised me for making changes to the source code. "Why is this?" came the question from management. My response drew silence - "Because you keep changing laws and management strategies. For example, last year, you charged fees that rose in a straight line according to the length of the fishing boat. This year, you've brought in a somewhat more complicated structure that requires us to calculate the under-deck-storage-volume, add in the number the 'tender boats', etc, etc. I could re-write the system to cater for this and future strategies, but that would cost $BIGFRACTIONOFTOALORGANISATIONBUDGET. Shall I get started?" And of course, nothing changed.

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.

Re:The real problem of Cobol

[ahmusch]

Kindly note the existence of the EXEC SQL / END EXEC. block in COBOL. Systems which use exclusively VSAM/ISAM are not nearly as prevalent as they once might have been, for a couple of reasons; DB2 is little more than a transactional wrapper around VSAM/ISAM, and DB2's generally a sunk cost in most z/OS or OS/390 shops. I've certainly never heard of a mainframe environment without DB2 on it.

It is, if not trivial, generally as easy to read/update/delete from an RDBMS (specifically, DB2 and Oracle, but there may be precompilers for others) in COBOL as it is from a language like Java. Heck, COBOL's data types are generally more database friendly from one perspective -- they have to be declared with precision and scale, whereas your average Java jockey simply starts using integers or floats -- and then financial mathematics start getting tricky. The absence of date and datetime types is a pain, but once one's written proper modules for dealing with it, it's possible to work with them.

Also, how is a class/object with multiple properties different than a C structure or a COBOL table?

Similarly, if you want a scheduled, repeatable process on a Unix, you'll end up writing parameterized scripts that end up being functionally equivalent to JCL.

COBOL isn't the modern programmer's enemy unless they've been completely brainwashed by OO concepts; it's the entire mainframe environment (and let's be honest, there isn't all that much COBOL running on other OSes) regarding JCL, CICS, TSO, and all the rest. COBOL isn't any better or any worse than any other language; it's the culture that's so radically different that your average born-in-Java developer simply has no choice but to run screaming.

Re:The real problem of Cobol

[jbolden]

COBOL isn't the modern programmer's enemy unless they've been completely brainwashed by OO concepts; it's the entire mainframe environment (and let's be honest, there isn't all that much COBOL running on other OSes) regarding JCL, CICS, TSO, and all the rest. COBOL isn't any better or any worse than any other language; it's the culture that's so radically different that your average born-in-Java developer simply has no choice but to run screaming.

Well that was point of my post its the environment COBOL programs live in that creates the complexity the problem isn't COBOL.

Also, how is a class/object with multiple properties different than a C structure or a COBOL table?

The COBOL may be defined system wide, and it may use OS related automatic data structures. So the programmer needs to know: the individual COBOL program, the family or programs, the OS level data conversion services (often invoked non obviously), and custom definitions in books/tables.

As for DB2 it is not having DB2 that is the problem but code that makes use of non relational features. For example implicit sequencing that exists in a COBOL table which would be a join, group by, order by in a RDBMS environment and they would have to figure this out.

That is what makes it more challenging.

COBOL programmers are needed

[stanjam]

In one of the schools I attended recently, one professor insisted on teaching Cobol. They have since forced her out. However, students who did well in her classes were immediately snatched up and given good paying jobs, even though they only had AS degrees. Why? Because they know COBOL. There are a lot of systems still running on COBOL. It is a good language for what it does, and there is only one reason to replace it: No one knows it anymore. However, it is worth it, if you want a job, to learn COBOL. You will get a job. That is, IF you can find a school that teaches it.

Enterprise Cobol Hello World!

[argent]

DATA DIVISION.
  WORKING-STORAGE SECTION.
    01 CURR-ARG-COUNT PIC 9(9) BINARY VALUE ZERO.
  LINKAGE SECTION.
    01 ARG-COUNT PIC 9(9)BINARY.
    01 ARG-LENGTH-LIST.
      05 ARG-LENGTH-ADDR POINTER OCCURS 1 TO 99999 DEPENDING ON CURR-ARG-COUNT.
    01 ARG-LIST.
      05 ARG-ADDR POINTER OCCURS 1 TO 99999 DEPENDING ON CURR-ARG-COUNT.
    01 ARG-LENGTH PIC 9(9) BINARY.
    01 ARG PIC X(65536).
PROCEDURE DIVISION USING ARG-COUNT ARG-LENGTH-LIST ARG-LIST.

I give up. That's just the "#include " and "main(int ac, char **av);" parts.

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

[TheMCP]

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

No software anticipates everything that could happen in the future.

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.

The fact that you seem to think you know everything about how the software works and what the problem is tells me you're arrogant and don't know nearly as much as you think you do about software.

I'll bet this software isn't modularized. I'll bet this software has some pretty low security standards.

That's easy to say because they're true of most software in general.

I'll bet this software requires a client app installed on any user's machine.

Dude, it's COBOL. It probably runs on a big box somewhere and gets accessed via terminals, or the software equivalent thereof.

As another poster pointed out, it's one thing to say "we can't make the software pay everyone minimum wage", it's a far different thing to say "we can't make the software temporarily pay everyone minimum wage, then put their pay back to what it was before the change at a later date, while meanwhile adjusting everyone's pay for what they lost in the meantime." It may simply be that what the Governator asked for is simply too oddball for it to have been designed into any pay system, so they'd have to create a bunch of custom code to deal with it. Or it may be that the manager in charge of it is simply lying because he doesn't feel like complying with the Governator's orders.

But you, being on the outside of it all, have no way to tell.

The real problem with COBOL

[symbolset]

One thing I think may be a problem..

Various flavors of "innovators" and entrepreneurs have developed middleware, 4GL, operating environments, libraries and front ends and sold them at ridiculous rates to organizations that have adopted different sets of them for 40 years. And they've sold them so well that to the people who bought them every unmade choice seems dirisible. Every choice between every option is a potential flamewar on the scale of Emacs VS vi. The odds of a new coder successfully negotiating this minefield long enough to get his code running on the very important systems that still run COBOL seems to be nearly nil. The odds of shopping this knowledge to competing companies seem exceedingly remote. This is obvious from the greybeards posting here.

Besides, who wants to get 2/3's of their way through a 30 year career as the FNG?

Thanks, but no. No COBOL for me. Not even as an historical oddity. Just no.

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.

It is just a language, learn it!

[forgoil]

I'm happy to learn and use new languages (with the exceptions of perl and java which I can't stand myself), in fact, it's fun and interesting. What the hell makes COBOL such a demanding thing??? The one and only thing I can think of is lack of language documentation, but if I have enough of that, it's just go go go.

So if anyone wants to hire me for lots and lots of money for COBOL coding, just email me :)

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

[chthon]

Yes. So you also know the feeling of accomplishment that you get when you are able to reduce the total size of a program, it still having the same functionality (or sometimes even more) ?

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

[chthon]

Hey, this is a nice remark. You can think of it as an analogy with building chips. A wafer with many small chips has a better yield than a wafer with big chips.

Edsger W. Dijkstra

[Exitar]

"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense."

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

[donaldm]

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

You're too nice I don't think "ha!" is suitable. Garlic, a cross and a sharp pointy stick would be more appropriate, after all you could argue that you are using these items for the common good of humanity and you may get a medal for it :-)

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

[Nutria]

I'll bet this software requires a client app installed on any user's machine.

You're joking, right?

These are 35-40 YEAR OLD MAINFRAMES. California is probably still using 3270 terminals, or PCs with IRMA boards.

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

[donaldm]

While a complete rewrite could save money in the long run, in the short term this would be very costly.

It wouldn't be near as costly if you only paid the coders minimum wage.

This is why major software companies like to offshore coding. A software company can get two or even three coders offshore to one onshore coder. The trouble is that while the offshore coder can do very good work they are not stupid, once they get enough experience they leave for better paying jobs leaving the coding projects with just "good enough" software, so you are forever training people. Eventually the cost of the overseas coders start to approach that of the onshore coder and the company then looks around for a new country where they can pay cheap wages to highly trained people and the spiral continues.

Note I am not trying to say that offshore coders are bad, a few are, but many are very very good. It is just that these people are not stupid and they have to look out for themselves so I can never fault them for jumping to a new better paying job when one becomes available.

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

[Alioth]

You seem to be under the mistaken impression that object orientation is a silver bullet. It isn't. Going from a well-written COBOL program to something 'that supports objects' doesn't buy you anything except having the program in a language that more people know (which is a valid benefit, of course, but a personnel benefit, rather than a technical one). You can write modular programs in COBOL already (and have been able to for decades).

Hip relacement

[QuestorTapes]

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

>> I propose COBOL on Rails. Any takers?

A 'Hip Replacement For Aging COBOL'.

The ads can be something like:

"You're an active senior. With your new hair, new heart valve, and new hip replacement, you're ready for -new- challenges. Give your old COBOL code a hip replacement too!"

Although rails might be a bit dangerous with a new hip. With that ad, perhaps, "COBOL on a walker' (zimmer frame for the brits) might be better.

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

[tehcyder]

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.

It doesn't sound that complex to me, on each employee's payslip, you just set up another line for "underpayment" then add these up to give a total of backpay when you change the pay rate back again.

I'm sure it's complicated because of the number of employees, but that is why payroll was one of the first business processes automated/computerised.

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

[Anonymous Coward]

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.

'all aspects' and 'other machines' is not a well written requirement.

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

[kevin_conaway]

Thread here. The gentleman in question is Tom Harper.

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

[SatanicPuppy]

We have a "relational database"; it's an old TurboImage/V database, running on MPE/iX. Flat table, 8 character names, no hierarchical file system. The system was maintained by 2 30 year vets who retired the same year, to be replaced by yours truly.

Our recovery is pretty much the same; either you edit the jobstream so that you can "re-run" the program from the point at which it crashed, or you restore and re-run.

Too often when I look at the problem I find its just some simple conflict or some weird missed condition; our nightly backup tries to stop a job before it runs. If that job has already been stopped, the backup crashes.

It's just not my world really. Manual recovery...The idea just hurts my brain. The program logic should be able to recover simple errors; if it runs into a file locking condition it should be able to pause for a moment, not just crash.

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

[johnlcallaway]

Is the system built so that it isn't possible to script the recover points? I.e. run the job with parameters that say 'restart at step x' and then do the file copies and such in the script?

Of course, it all depends on whether or not they it's worth it. For something that fails once or twice a year, probably not worth it. For something that fails once a week, probably worth it.

Of course, if it is failing once a week the same way each time, I'd be looking into fixing the problem. hehe.....

False

[Slashdot Parent]

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've used QuickBooks, PeachTree, and Paychex to process payroll. All three of them handle backpay trivially.

Backpay is a very common payroll scenario. Companies give raises all the time that are effective some date in the past. Inability to handle backpay means your payroll system is improperly designed.

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

[Slashdot Parent]

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.

Don't you know that there is now an Object Oriented version of COBOL?

It's called: ADD 1 TO COBOL.

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

[Silfax]

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

modern versions of COBOL do support classes.

COBOLs not dead, it just smells funny

[Anonymous Coward]

It's amusing to read some of the comments in this section. Most seem to be made by folks who haven't a clue about COBOL or even the new standard. (BTW the next standard is Object Oriented for those who have to have that silver bullet.)

What they are dealing with in CA is likely old SPU-GETTI code, written to the old COBOL 68 standard and littered with GO TOs, GO TO DEPENDING and probably an occasional ALTER verb. (A firing offense that last one.)

Likely too, some of the code is probably older than most of the people posting here, and has been patched so many times that 75% of it is dead. Likely too it is difficult to tell what's live or dead and when you change one line you break something else. (And anybody who tells me that that can't happen with C, C++ or Java (C++ with its pants on?) is probably in management or marketing.)

But just by way of edumacating the masses out there I offer up the following.
The new COBOL 85 standard is quite an improvement over the 68 and 74 versions of the language.For example:
SET WEOF-FOUND TO FALSE.
PERFORM UNTIL WEOF-TRUE
        READ FINPUT INTO WS-DOHICKEY-GROUP
        AT END
                SET WEOF-FOUND TO TRUE
        NOT AT END
                PERFORM VARYING WS-DOHICKEY-SUB
                        UNTIL WS-DOHICKEY-SUB > WS-DOHICKEY-SUB-MAX
                        OR WS-DOHICKEY-ITEM(WS-DOHICKEY-SUB) = SPACES
                        PERFORM PROCESS-DOHICKEY THRU PROCESS-DOHICKEY-EXIT
                  END-PERFORM
        END-READ
END-PERFORM

Now, how hard to read is that?

COBOL is a very primitive language and in many ways looks assembler-ish. But with a sense of history you'll realize that it was a vast improvement over assembler when it was first developed. (In fact I think the first version was called FLOMATIC or something.) You won't get the nicities of COLLECTIONS but you could 'roll your own' and distribute them as COPY (read INCLUDE) files. You've got arrays (OCCURS) and that's a start.

Ah well. I'm retired from all this anyhow. Time to go out to the vegetable garden and get some fresh stuff for a lunch.

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

[VdG]

never underestimate just how bad a system written by a less-than-competant programmer can be. Sometimes it can be so bad you fail to understand how they came up with it.

Even worse is a system written by someone who's talented, but not quite as good as they think they are. Worst of all is the "genius" programmer who decides to use some design methodology that nobody else has ever heard of. There's a lot to be said for the boring, mediocre programmer.

COBOL and Data Processing

[d17g]

I learned COBOL in the late 1970's. I never used it professionally, but it and numerous other languages that come from that period and before (e.g RPG) are all about data processing and business systems. Newer tools that map to that space we now call ETL (think Ab Initio, Informatica, Data Stage). The reason COBOL went out of vogue is because the applications built in that language have stood the test of time - no-one was need to build replacement bceuase the originals worked. This meant we (as programmers) moved on to languages that support other needs. C++, Java and related languages are great for what they do (for instance ETL tools tend to be written in C++), but they are not suitable for many business systems application without first building up a code infrastructure that supports them. If I were writing a new business systems application, I probably would choose a modern ETL tool over COBOL (less coding to get the job done), but I would think long and hard before abandoning COBOL for an existing application just because it is "old". I would also point out that just because we understand the concepts needed to properly design and implement an interactive application does not mean we have the concepts needed to properly design and implement a data processing application.

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

[Anonymous Coward]

Someone may have written crappy code, and they may well still be using a flat file structure. But, most COBOL programs use 7 or less 'verbs' such as add, subtract, compute, move, perform, ... If you have experience in any other development language, and can't figure out COBOL in less than an hour - Your either lazy, or NOT a developer, just another hack who can write code.

As for Java, I've seen apps that crash, and you lose a week, and maybe a client!
!
It's takes a seasoned professional to understand that it's not the code! It's a good analyst and developer first choosing the right tool for the job, then putting together a quality product.

Proferssional, or Code Hack

[Anonymous Coward]

Someone may have written crappy code, and they may well still be using a flat file structure. But, most COBOL programs use 7 or less 'verbs' such as add, subtract, compute, move, perform, ... If you have experience in any other development language, and can't figure out COBOL in less than an hour - Your either lazy, or NOT a developer, just another hack who can write code.

As for Java, I've seen apps that crash, and you lose a week, and maybe a client!

It's takes a seasoned professional to understand that it's not the code! It's a good analyst and developer first choosing the right tool for the job, then putting together a quality product.

Since 80% of 'development' is code maintenance. I'd prefer simple, easy to read logic that is standardized and cohesiv, over something that is spread into 20 disjoint pieces that requires a cryptologist to decipher

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

[Anonymous Coward]

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.

A crashing COBOL program never ruined anyone's day that I know of and I've been around COBOL systems for 25 years now. Most shops with half a brain built in restart capability. We also have lots of new "cool" stuff - Java, JMS, WAS, MQ, WBI - and it seems to take way more people and time to find and fix problems in that environment than it does in MF batch/CICS COBOL.

Re:I Was Going To Be Funny And Put Some COBOL Code

[Silfax]

of those 21 lines 5 were either comments or blank lines 3 were superfluous labels 4 were required by the COBOL standard -- mostly for documentation purposes, and to tell the compiler what to expect next 1 was a name so the operating system could find the program (unlike Java, the program source can have a different name than the actual program) 1 was a do nothing statement as the program was coded 2 were basically hints to the compiler -- not actual program code 2 were basically compiler directives, allowing compilation for a different architecture than where the program source was stored of the 3 remaining lines of actual program code 2 were extensions to the language, a single display would have worked also 1 was a return to the operating system (some compilers will generate that one if not present) The whole program could have been written as IDENTIFICATION DIVISION. PROGRAM-ID. TEST0001. ENVIRONMENT DIVISION. DATA DIVISION. PROCEDURE DIVISION. DISPLAY 'HELLO WORLD' GOBACK. I think that PROGRAM-ID is sort of self explanatory the DIVISIONS must be present, but are mostly to tell the compiler what is coming up next I personally prefer "GOBACK" to "STOP RUN", as it returns to the calling program, the "STOP RUN" returns to the OS, which might be a bad idea, if you are several subroutines down.

Re:I Was Going To Be Funny And Put Some COBOL Code

[Silfax]

ARGH --- hit submit, not preview with default set to html....


it should be

of those 21 lines 5 were either comments or blank lines

3 were superfluous labels

4 were required by the COBOL standard -- mostly for documentation purposes, and to tell the compiler what to expect next

1 was a name so the operating system could find the program (unlike Java, the program source can have a different name than the actual program)

1 was a do nothing statement as the program was coded

2 were basically hints to the compiler -- not actual program code

2 were basically compiler directives, allowing compilation for a different architecture than where the program source was stored

of the 3 remaining lines of actual program code

2 were extensions to the language, a single display would have worked also

1 was a return to the operating system (some compilers will generate that one if not present)

The whole program could have been written as

IDENTIFICATION DIVISION.
PROGRAM-ID. TEST0001.
ENVIRONMENT DIVISION.
DATA DIVISION.
PROCEDURE DIVISION.
DISPLAY 'HELLO WORLD'
GOBACK.


I think that PROGRAM-ID is sort of self explanatory the DIVISIONS must be present, but are mostly to tell the compiler what is coming up next

I personally prefer "GOBACK" to "STOP RUN", as it returns to the calling program, the "STOP RUN" returns to the OS, which might be a bad idea, if you are several subroutines down.

COBOL=NASCAR

[Anonymous Coward]

If I remember correctly (I was about 10 years old when I messed around with a COBOL training program called PASCAL ? the robot) you had to make 3 left turns with the robot to make a right turn.
If that's the program and language I'm thinking of, it should catch on here in the South (US).

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

[Anonymous Coward]

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

To which I reply:

"You obviously know absolutely nothing about mainframe programming"

One of the main reasons why these old systems are still around is that they were designed and built to last YEARS. Highly modularized, parameter driven, bug-free. Yes, BUG FREE.

And "any user's machine" were / are dumb terminals. ie NO local processing.

Now fuck off back to your slow eye candy Web 2.0 crap and get off my lawn!

Sorts????

[Muchsake]

Sorts are a job for the operating system not the programmer. Why constantly re-invent the wheel.All the only sorting I did in over twenty years of COBOL programming was done by the operating system (VME/B VME2900)which had a multipass sort routine smart enough to pick out the best algorithm after the first pass.

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

[kikimann]

WHEW! Is this a religious war or something? OK - VETERAN COBOL PROGRAMMER (1974 - 2008) HERE SPEAKING! PLEASE LISSEN UP! (ignorance is a costly commodity that few people or businesses can afford). If you read through these posts "statistically" you will find a preponderance of gripes and "apples-to-oranges" comparisons. Poorly-written, poorly maintained, old, old, OLD code is - you guessed it, REALLY unpleasant for everyone (we seem to have that point of view well-covered). How many 40-year-old JAVA apps has anyone worked on lately, hmmm? OK - NEWS FLASH! GET THIS! please! (don't be ignorant). Believe it or not, there is a HUGE difference between "COBOL", and poorly-written, poorly maintained, old, old, OLD code that happens to be written in COBOL. Did you get that? What is getting bashed is poorly-written, poorly maintained, old, old, OLD code - and people are mistakenly thinking they are bashing COBOL - a bit ignorant, you might say? OK - moving on to the bright side. As a few have tried to point out here, besides the all-too common, all-too prevalent preponderance of poorly-written, poorly maintained, old, old, OLD code - there ARE companies running their businesses RATHER HAPPILY on some WELL-WRITTEN, WELL-MAINTAINED, new, clean, modularized code that just HAPPENS to be written in (are you READY!) - ta-dah!: COBOL!!!! Yeah! Honest - it happens. OK - yeah - these are mainframes - they're the machines that suck up, and hold, and process, and route, and re-route, the billions of transactions that all you little JAVA applets and PERL folks toss around out there. OK - to be fair - I would NOT want to have to try to do some of the customer-facing stuff you guys do - not in COBOL -- in fact I couldn't. COBOL is not intended to do everything. So I am not belittling ANY other language. Just understand, NO language is any better than it's deployment and/or maintenance. But COBOL DOES let me design, develop, and maintain HUGE apps - almost anywhere in the world - EASILY! Hard to Learn? Why heck, I've bought my house, cars, you name it, using about a dozen or so words: OPEN, READ, WRITE, MOVE, ADD, SUBTRACT, COMPUTE, IF, AND, OR, ELSE, NOT, END, PERFORM, GO TO (we don't like to use that one a lot), CLOSE, STOP RUN. Now - that wasn't so bad, was it? NOW - to the REALLY bright side - you should just SEE what can be done on an Unisys Clearpath or Libra (running with a fiber optic disk sub-system) using COBOL85 (or higher) with intrinsic functions, scope terminators, etc, etc, using WFL (a highly-programmable "jcl"), DMSII and COMS - FULLY-AUTOMATED DATABASE ROLLBACK AND RECOVERY, ZERO transaction loss (out of billions)... Oh awright, I know, mainframes are not for everybody ... My heartfelt sympathy goes to those who have suffered, and are currently suffering under code which is the result of years of neglect, abuse, mismanagement, political decisions (sadly, "IBM" (JCL, VSAM, ... etc.) Sadly - you have not a CLUE as to just how good COBOL can be - and it's not likely that many of you ever will. (oops-- just had a spike in my transaction volume - I'm almost at 30% capacity - gotta go - ta-ta) ... tum-de-dumm (love my Unisys) PS - there are PLENTY of sites on the web for those who are interested in lowering their CIQ (COBOL Ignorance Quotient). Meanwhile, let's not continue to confuse bad code that is written in COBOL with COBOL itself, and let's all educate ourselves about a language that has billions of lines of code -- most of them fairly potable, and maintained by only 90K pprogrammers.

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

[kikimann]

OK - VETERAN COBOL PROGRAMMER (1974 - 2008) HERE SPEAKING! PLEASE LISSEN UP! (ignorance is a costly commodity that few people or businesses can afford). How many 40-year-old JAVA apps has anyone worked on lately, hmmm? OK - NEWS FLASH! GET THIS! please! (don't be ignorant). Believe it or not, there is a HUGE difference between "COBOL", and poorly-written, poorly maintained, old, old, OLD code that happens to be written in COBOL. Did you get that? What is getting bashed is poorly-written, poorly maintained, old, old, OLD code - and people are mistakenly thinking they are bashing COBOL - a bit ignorant, you might say? As a few have tried to point out here, there ARE companies running their businesses RATHER HAPPILY on some WELL-WRITTEN, WELL-MAINTAINED, new, clean, modularized code that just HAPPENS to be written in (are you READY!) - ta-dah!: COBOL!!!! Yeah! Honest - it happens. To be fair - COBOL is not intended to do everything. So I am not belittling ANY other language. Just understand, NO language is any better than it's deployment. But COBOL DOES let me design, develop, and maintain HUGE apps - almost anywhere in the world - EASILY! You should just SEE what can be done on an Unisys Clearpath or Libra (running with a fiber optic disk sub-system) using COBOL85 (or higher) with intrinsic functions, scope terminators, etc., etc., using WFL (a highly-programmable "jcl"), DMSII and COMS - FULLY-AUTOMATED DATABASE ROLLBACK AND RECOVERY, ZERO transaction loss (out of billions!). My heartfelt sympathy goes to those who have suffered, and are currently suffering under code which is the result of years of neglect, abuse, mismanagement, political decisions (sadly, "IBM" JCL, VSAM, ... etc. - I, too have worked with some COBOL installations from the pits of hell). Sadly, you have not a CLUE as to just how good COBOL can be - and it's not likely that many of you ever will. There are PLENTY of sites on the web for those who are interested in lowering their CIQ (COBOL Ignorance Quotient). Meanwhile, let's not continue to confuse bad code that is written in COBOL with COBOL itself.

The difference between COBOL and bad code

[kikimann]

VETERAN COBOL PROGRAMMER (1974 - 2008) HERE SPEAKING! PLEASE LISSEN UP! (ignorance is a costly commodity that few people or businesses can afford). If you read through these posts "statistically" you will find a preponderance of gripes and "apples-to-oranges" comparisons. Poorly-written, poorly maintained, old, old, OLD code is - you guessed it, REALLY unpleasant for everyone (we seem to have that point of view well-covered). How many 40-year-old JAVA apps has anyone worked on lately, hmmm? NEWS FLASH! GET THIS! please! (don't be ignorant). Believe it or not, there is a HUGE difference between "COBOL", and poorly-written, poorly maintained, old, old, OLD code that happens to be written in COBOL. Did you get that? What is getting bashed is poorly-written, poorly maintained, old, old, OLD code - and people are mistakenly thinking they are bashing COBOL - a bit ignorant, you might say? Moving on to the bright side - as a few have tried to point out here, besides the all-too common, all-too prevalent preponderance of poorly-written, poorly maintained, old, old, OLD code - there ARE companies running their businesses RATHER HAPPILY on some WELL-WRITTEN, WELL-MAINTAINED, new, clean, modularized code that just HAPPENS to be written in (are you READY!) - ta-dah!: COBOL!!!! Yeah! Honest - it happens. OK - yeah - these are mainframes - they're the machines that suck up, and hold, and process, and route, and re-route, the billions of transactions that all you little JAVA applets and PERL folks toss around out there. OK - to be fair - I would NOT want to have to try to do some of the customer-facing stuff you guys do - not in COBOL -- in fact I couldn't. COBOL is not intended to do everything. So I am not belittling ANY other language. Just understand, NO language is any better than it's deployment and/or maintenance. But COBOL DOES let me design, develop, and maintain HUGE apps - almost anywhere in the world - EASILY! Hard to Learn? Why heck, I've bought my house, cars, you name it, using about a dozen or so words: OPEN, READ, WRITE, MOVE, ADD, SUBTRACT, COMPUTE, IF, AND, OR, ELSE, NOT, END, PERFORM, GO TO (we don't like to use that one a lot), CLOSE, STOP RUN. Now - that wasn't so bad, was it? To the REALLY bright side - you should just SEE what can be done on an Unisys Clearpath or Libra (running with a fiber optic disk sub-system) using COBOL85 (or higher) with intrinsic functions, scope terminators, etc, etc, using WFL (a highly-programmable "jcl"), DMSII and COMS - FULLY-AUTOMATED DATABASE ROLLBACK AND RECOVERY, ZERO transaction loss (out of billions)... Oh awright, I know, mainframes are not for everybody ... My heartfelt sympathy goes to those who have suffered, and are currently suffering under code which is the result of years of neglect, abuse, mismanagement, political decisions (sadly, "IBM" JCL, VSAM, ... etc.). Sadly - you have not a CLUE as to just how good COBOL can be - and it's not likely that many of you ever will. PS - there are PLENTY of sites on the web for those who are interested in lowering their CIQ (COBOL Ignorance Quotient). Meanwhile, let's not continue to confuse bad code that is written in COBOL with COBOL itself, and let's all educate ourselves about a language that has billions of lines of code -- most of them fairly potable, and maintained by only 90K pprogrammers.

Re:The difference between COBOL and bad code

[BSDetector]

How dare you question the intelligence of the resident Slashdot denizens! You must be a shill for somebody !

Re:The difference between COBOL and bad code

[kikimann]

my bad -- I thought that the terms, "resident Slashdot denizens" and "intelligence" were mutually exclusive if not/and/or an oxymoron (as opposed to real morons -- or in addition to real morons, or the same as real morons ... ?)

nope - I'm my own person -- nobody's shill ... (shill indeed! ... what a shilly idea) - just Columbus all over again - tellin' the flat-lined world folks that the world is round ... sail on, silver girl

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

[vacuum_tuber]

I can't speak for the IBM COBOL world but I can speak for the Wang VS COBOL world and Wang VS mainframes. The VS has optional transaction processing at the OS / file system level. Any indexed file can be initially built or later reorganized to have recovery blocks. Any program that opens such a file will cause the OS automatically to create a BIJ per user of the file. Wang COBOL 74 and 85 both have COMMIT and ROLLBACK verbs. Moreover, the Wang VS transaction system supports committing nested transactions into the higher one or rolling back just the current nested level.

If a program lacking COMMIT/ROLLBACK statements is suddenly given to deal with a soft recoverable file, all the updates it makes will accumulate and will automatically commit when the program successfully completes. If the program is canceled or the system stops, all the changes it made will be rolled back.

When testing software, the ability of the system to roll back changes is not the way it's done in Wang VS systems. It's more efficient to back up the files to be modified, disk-to-disk, and put them back if a rerun is necessary. In many cases the tests are done on a development system or a development partition in a VM environment. In these cases file snapshots are brought into the development environment, where it is just common sense to park copies of them in case the inevitable reruns become necessary.

One of the problems of using tools like COBOL outside the mainframe environment is that you won't have the infrastructure like transaction processing.

In the Wang VS mainframe, now virtualized and running on Dell PowerEdge servers under Linux, we have transaction processing and specific file types at the OS level. The VS OS knows about consecutive files, print files, object files, indexed files, alternate indexed files, relative files, etc. Record-level compression is an option at the OS level and is the default for indexed data files, source files and printfiles. Compressed records are an option for the program or utility that creates a file but are transparent to programs reading a file.

We also have a good 4GL and relational database, PACE. I can create an example customer file in less than five minutes, with a full range of access screen programs, without writing a single line of code.

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

[SatanicPuppy]

For the most part, stuff doesn't fail. It is pretty reliable, and the system is not under heavy utilization (thank god).

Some of the better bits of code have good recovery points; some of them even have "restart" options in their parameters.

With all the custom code, however, things have a tendency to fail in interesting ways.

ha

[Anonymous Coward]

At least you agree that COBOL is dead.

http://www.computerweekly.com/blogs/it-networks-and-communications-blog/2008/04/cobol-programmers-back-in-dema.html

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

[kikimann]

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

Quite true - the "average developer" has to deal with the environment he/she is in. If that environment is not COBOL, then COBOL makes no sense at all.

HOWEVER ... where the environment IS COBOL, it makes perfect sense, does it not? Why get rid of COBOL just because it's COBOL??

The ONLY "come back" COBOL needs to make is to come back out from under the ginormous mountains of ignorance and 80' - 90's client server marketing hype and mythology, into being understood as the superb language of choice for developing solid, portable (if properly standardized) mainframe business applications ...

COBOL make a "comeback"? HAH! -- it never left in the first place !