Cobol Programmer

Contrary to popular belief, there still is quite a bit of COBOL [CobolLanguage] code underneath most large enterprise systems, and there's still quite a bit of COBOL development occurring. The front end may take the form of some nifty GUI interface, but the guts are comprised of CICS and DB2 (or other industrial strength database platforms).

We know about it but choose to ignore it and say "I'd rather bag groceries than do a day of Cobol. More challenging." -))

Heh, a remark that displays a lot of ignorance - I've done both PeeCeeWeenie? coding and crunched enough large Cobol systems to accurately say that is a snide, snobbish crack. Large mainframe systems are very complex, with an exponential number of interfaces compared to the average PC system. Crawling into an elaborate system where most of the BusinessRules are embedded in the code, snuggled there even oblivious to the company users, who have an average job position length that is a fraction of the system life.

Sorry, but coding a nice GUI may be nice, but tinkering with the real system engines is incredibly more "challenging" than most PeeCeeWeenie? applications.

It's nice to know that all computer programming can be divided into large mainframe systems written in COBOL with exponential numbers of interfaces and business rules embedded in the code on one hand, and PeeCeeWeenie? GUIs on the other hand. -- FormerCobolProgrammer?

If you've used a charge card, booked a flight reservation, paid your electric bill, had a medical claim adjudicated, odds are excellent that it was done in a mainframe system, even if the front end is some EJB or Web-based GUI, by COBOL programs written by CobolProgrammers.

Does anyone here still work in COBOL?

It seems that AlanCox likes Cobol and spends time hacking in it.

I see plenty of evidence that AlanCox has worked on a Cobol compiler, and no web hits that show him actually working in COBOL. Got a reference?

Cobol challenge: Can you make a wiki-clone with Cobol?

Cobol is TuringComplete, so it is theoretically possible. Whether it is fun to write or maintain such a thing is another matter.

See CobolCausesBrainDamage

"Does anyone here still work in COBOL?"

COBOL still sports the top # of years experience on my resume. However, I've been using OO languages for almost 5 years now.

I think for a lot of people the "COBOL sucks" mantra is just herd-speak. In fact, throughout my consulting life I've noticed that even non-programmers like to chime in about how much COBOL sucks. Of, course they don't anything about COBOL... other than it sucks.

On the other end of the spectrum you have COBOL programmers that seem to have blinders on. They kick around at comp.lang.cobol and will be happy to tell you that anything that can be done in language X, can be done in COBOL... and that COBOL is now OO... and that COBOL can have GUIs other than CICS... and...

I think I can sum up my current feelings about COBOL accurately (based on my experience, and my recent clients) by saying that it was and still is a programming language for the rank-and-file programmer; just like MS Visual Basic was in the 80s. The age of the IN-HOUSE rank-and-file programmer is gone in my opinion... but that's another discussion.

Compared to today's technology, when you look at what COBOL does well there is no compelling reason NOT to use a better language instead (like Perl for batch processing, for example)... except for legacy reasons. Ie: staff and codebase considerations.

And in my opinion the "big critical system" argument doesn't wash. COBOL is only a programming language, just like Java is. It's not an infrastructure. "Big critical systems" run within an infrastructure: like OS390/VM or J2EE.

COBOL, been there, done that. My time on a MainFrame was very educational. It was the JobControlLanguage I despised the most, though the fact you had control of what is usually OS tasks was sort of fun (disk block sizes for an example) the inverted logic and no looping was irritating. Most of the so called OO code I have seen has been what I refer to as COBOL in drag: procedural, inflexible and unmaintainable. You could replace it with COBOL and it would be faster, more efficient, use less code and easier to maintain.

You should have tried COBOL in a Unisys environment. Compared to IBM, ECL was much easier to use and understand than JCL. As for the OO in drag sentiment: it's inevitably the driver that's at fault, not the technology. Case in point: I've made more money from fixing poorly written COBOL programs in the last 6 years (yes that includes Y2K), than I have made developing NEW J2EE and .Net apps. I expect to do the same in the next 5 years as the developers you've cited above create more procedural, inflexible and unmaintainable code.

EliseScher is a COBOL programmer/analyst who is now teaching and wants to program again, She likes wikis.