Become a fan of Slashdot on Facebook


Forgot your password?
Businesses The Almighty Buck

Cobol Job Market Heating Up 288

snydeq writes "Developers seeking job security in the years ahead could find an unlikely edge in Cobol. According to an InfoWorld report, demand for Cobol skills is surging, with salaries on the rise. More importantly, the short supply of offshore Cobol programmers and the fact that mainframes aren't going away anytime soon are spurring longevity for big-iron skills, with many companies looking to hire in-house Cobol pros to bridge mainframe Cobol apps to the rest of the enterprise. The report provides further evidence that Cobol may indeed be primed for a comeback, with new kinds of Cobol integration jobs emerging to prove old-guard skills are critical to some of the hottest areas of software development today."
This discussion has been archived. No new comments can be posted.

Cobol Job Market Heating Up

Comments Filter:
  • Short supply? (Score:5, Informative)

    by dedazo ( 737510 ) on Thursday October 23, 2008 @02:22PM (#25485139) Journal

    I'd disagree with that. Schools in India are still providing lots of people with mainframe skills. The whole shebang, like InfoMan, CICS, etc. Not just Cobol. At least that's my impression. I see a lot of people from Tata, InfoSys and IBM Global Services doing mainframe-centric maintenance and even new development at companies I have contact with these days.

  • by theaveng ( 1243528 ) on Thursday October 23, 2008 @02:25PM (#25485195)

    I'll do it!!! I'd even be willing to clean toilets if they paid me engineering wages. Yes I'm a sellout. "I know Cobol, and I charge $90 an hour. When do you want me to start?"

  • by Anonymous Coward on Thursday October 23, 2008 @02:38PM (#25485377)

    All the big Hartford insurers have their own programs: The Hartford, Aetna, Travelers, United Health Care, and I can't remember the rest.

    They're the big consumers of Mainframe Cobol.

    By the way, the reason they are staying with Cobol isn't just because of their legacy code, it's also because mainframes are the only solution now that solves their business problems.

    Don't get me started on "distributed systems" because I'll have to slap you silly. Mainframes solve problems that can't be solved by other solutions. That's why they still exist.

  • by dedazo ( 737510 ) on Thursday October 23, 2008 @02:38PM (#25485381) Journal

    $90? You're selling yourself cheap. Try somewhere around $120, for starters. It goes up from there. And these are rates for long-term projects, not wham/bam/thankyou/ma'am two week gigs to solve some obscure CICS problem.

    That's assuming you have the resume and enough systems experience to back it up, but most people who do COBOL for a living do anyway.

    In the mid-00s I seriously considered learning COBOL and C mainframe development after seeing how much those old farts from IBM were pulling in. It's far from sexy, but it's a lot of cash.

  • by Anonymous Coward on Thursday October 23, 2008 @02:48PM (#25485517)

    Actually, there is an OpenCobol:

  • by viridari ( 1138635 ) on Thursday October 23, 2008 @02:49PM (#25485545)

    Microsoft Visual COBOL? *blech*

    Back in the day I used Microfocus COBOL [], which is still available today.

    There are plenty of books out there on COBOL but O'Reilly, being geared mostly towards lower end machines, isn't likely to have much that is mainframe-centric like this. It's been over 15 years since I've written any COBOL (not long enough!) so I can't recommend a good modern guide.

    Honestly, I think anything you can do in COBOL you can do better in Perl.

  • by killmofasta ( 460565 ) on Thursday October 23, 2008 @02:55PM (#25485639)

    And so is Brain Damage:

    "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence." (1968) - Dijkstra

  • by Gonarat ( 177568 ) * on Thursday October 23, 2008 @03:00PM (#25485751)

    There are COBOL compilers for the PC, some are even free (even if they are a few years old). Google COBOL compiler or take a look at this site: Thefreecountry [].

    Included at this site are links to old favorites such as COBOL650 and Fujitsu COBOL compiler (student version).

  • by truthsearch ( 249536 ) on Thursday October 23, 2008 @03:01PM (#25485781) Homepage Journal

    Typically, with these old systems, adapting to new business needs and adding new functionality are done secondary to the core system. For example, at MasterCard all transactions eventually go through the ancient mainframe system. That feeds daily into a very modern data warehouse, where all the new applications perform reporting and analysis. These newer systems can be changed as often as necessary without any impact to the old mainframes.

    Reduced operational costs and reduced consulting fees would very often be offset by the cost of the rewrite and ongoing maintenance of the newer system.

  • by Rhabarber ( 1020311 ) on Thursday October 23, 2008 @03:02PM (#25485791)
    No idea about COBOL but for LISP there always is Practical Common Lisp [].
  • by VeNoM0619 ( 1058216 ) on Thursday October 23, 2008 @03:20PM (#25486099)
    While a joke, I must disagree/explain. It does not require you to use all uppercase.

    The only problem I have with COBOL is that every variable is a global variable, defined at program startup.
  • by Anonymous Coward on Thursday October 23, 2008 @03:28PM (#25486231)

    As for your LISP wishes.

    Great (and free) book:

    There is also a video series that goes along with the book taught by some MIT geeks back in like the early 80's or something:

    Good luck with that

  • by OwenDMoney ( 963991 ) on Thursday October 23, 2008 @03:28PM (#25486243)










    001000 DATA DIVISION.

    001100 FILE SECTION.





    100300 BEGIN.


    100500 DISPLAY "Hello Money!" LINE 15 POSITION 10.

    100600 STOP RUN.

    100700 MAIN-LOGIC-EXIT.

    100800 EXIT.

  • by Animats ( 122034 ) on Thursday October 23, 2008 @03:32PM (#25486311) Homepage

    Just think of COBOL as a scripting language for business applications. Yes, the syntax is wordy. But the big advantage of COBOL isn't in the procedural code. It's in the data declarations. COBOL has very clear ways to talk about external data structures, and good integration with external data in files and databases.

  • Because it works. (Score:3, Informative)

    by Shivetya ( 243324 ) on Thursday October 23, 2008 @03:35PM (#25486371) Homepage Journal

    I know COBOL, I do not program in it for a living. The simple fact is that it works and it works well. Don't compare JAVA, C++, or C#, to it. Sorry those languages are so damn cluttered and so easily made incomprehensible it really is silly. The one thing I notice as a difference from COBOL (or similar) programmers compared to those using newer languages, the COBOL folks will use proven routines over the latest gee-whiz attempt to do it another way. I can go look into the C++ CMS and find a dozen ways to do the same damn thing because of developer ego or just plain ignorance. I have seen five lines of C exploded to a dozen lines simply because one guy didn't want to learn it or care to use something he didn't fully understand and was too sensitive to ask for help on.

    I do code on the iSeries. I do RPG/LE, C, C++, SQL, and CL (iseries version of JCL). I can combine modules from each easily meaning I can easily make use of some of the COBOL our mainframers bring over. One or two minor changes and I have all the integrity of their routine which has been running for years. That running for years provides a great level of comfort that the other languages MUST earn. Declare the language of the week to be superior for whatever reason you want, it cannot provide the comfort level from proven existence and stability.

    Would I want to go back to COBOL, not really. I will do so in a heart beat if it keeps me employed. I will do JAVA if necessary to stay employed but for ease of programming some of the older languages are where it is at. Now these languages are extended to share with other languages and you can embed SQL into IBM versions of SQL so you can have very good data access. All our interfaces to the web rely on COBOL/RPG backbones. The PC people tell us what they want and we deliver it. We might have one meeting to hash it out but for the most part we have our side done in a third of the time if not less.

    Yeah, mainframe/mini bigot ... but I do each platform.

    Finally, there is no reason to replace working systems just because you can. Businesses don't stay in business if they just replace it simply because someone has a woody over a glossy ad.

  • by Mong0 ( 105116 ) on Thursday October 23, 2008 @03:55PM (#25486837)

    Funny because I am a 36 year old COBOL developer and we have no gray beards on my team. We have close to fifteen COBOL developers and none of them are older than 50, with a median age of 34 between the group.

    Also I have worked with a few gray beards in my time and I have found them to by polite and very knowledgeable. Some of which could write CICS programs that do more unique display routines than some of your current gui's.

    If someone is truly interested in getting into COBOL for the first time your best bet is to find a company that will offer to train you. Most companies are realizing that developing the talent local and keeping things in house is actually cheaper than out sourcing as they will be able to retain the talent once the project is up and running and have an in house staff for support.

    Another avenue might be to start inquiring with some of the major contracting companies, as they provide a large part of the workforce for open COBOL positions. Some of them have their own training programs.

  • by iggymanz ( 596061 ) on Thursday October 23, 2008 @04:18PM (#25487279)
    Anything Cobol can do, any other language can do as well absolutely false, most languages are incapable of doing proper decimal arithmetic out of the box.
  • COBOL isn't evil. (Score:3, Informative)

    by lancejjj ( 924211 ) on Thursday October 23, 2008 @04:30PM (#25487541) Homepage

    Many years ago, right before the dot-com boom, I was out of college and looking for any job. The economy was lousy in 1988, and I had a computer science degree, and a big firm offered me a killer job with an awesome salary. Sadly, the job was all about COBOL.

    Happily I had another job lined up at a famous research center. But it was heavily government funded, and their funding disappeared. So I took the Cobol job, as it was a job, and it paid well.

    Well, it was the most awesome job I had ever. I learned a lot. COBOL was the worst part about it, but there were plenty of other design challenges, and I worked with a bunch of smart people who were also saddled with COBOL. Of course, you can do just about anything with enough COBOL and enough creative thinking. And, of course, as a computer science guy, sometimes it is fun to exercise a mainframe even if you can only exercise it with an antiquated language.

    The nice thing about COBOL, of course, is that its pretty hard to get yourself in trouble. The bad thing is that it can't easily do all the great things that a modern (post 1962) language can do. Or at least in can't do those things in an elegant way. Yes, even in COBOL-72 you can dynamically allocate memory for a complex data structure - if you're creative enough.

    The other nice thing about living in a Cobol/Mainframe shop for a while is that you realize that everything in modern computing was delivered like 40 years ago by IBM. Sure, some things have changed, but just about all the big important things have been in that mainframe environment forever.

    Of course, the web and dot-com boom started to emerge and I left the mainframe world after a couple years. A lot of my mainframe buddies did successfully make the transition, and the others mostly retired.

    I still have fond memories of the people and systems. Yes, they are both all crusty and old, even back then, but all those things ain't as bad as people say.

    Except for JCL. I always hated JCL. Now that was a total senseless hack.

  • by Zordak ( 123132 ) on Thursday October 23, 2008 @05:25PM (#25488795) Homepage Journal

    Okay, I thought I was joking, but apparently, somebody really has a Cobol implementation in VS []. This unholy union is clearly the work of Satan.

    When I see Visual x86 Assembly for .NET, I'm going to have to smash something.

  • by Nefarious Wheel ( 628136 ) on Thursday October 23, 2008 @05:58PM (#25489359) Journal

    Actually, I don't think you need a modern guide. COBOL hasn't changed much, older books may be ok.

    MicroFocus is good. Another segment in that space with a lot of potential is in the Sun CICS emulators ( These are large systems that can offer a way out of the IBM mainframe trap while still supporting legacy OLTP systems. I don't know that they've achieved huge commercial success, but the options are out there.

    It's all in the dollars, I guess. For some firms -- say, with 20 or 30 million customers to keep track of, the cost of the computing equipment isn't all that significant compared to the value of the data assets, so they're less likely to want to move away from Big Blue for their big iron. But for those in the middle with a strong desire to move down the ladder a bit, there are still things you can do before you have to re-engineer the lot. Much of the logic in old COBOL has to do with business rules and database manipulation.

    You could probably redefine most of it as simple database table IO (which you could knock together in Iron Speed in a very short time). The problem is in the custom rules that would need to be rewritten in something else, like SeeBeyond -- to get verification and test, you'd need to talk to the business people, and getting them to agree would open up a brand new can of vermiform invertibrates. It would be like re-convening the Continental Congress. So although there are strong technical cases for re-engineering, there are equally strong business/political reasons for a simple application port to a different underlying platform. For mostly political reasons, code is remarkably difficult stuff to change sometimes.

  • by kjots ( 64798 ) * on Thursday October 23, 2008 @11:27PM (#25492975)

    Edsger Dijkstra remarked that "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense".. From Wikipedia [].

    I believe that quote was directed towards BASIC, not COBAL ( [], first quote in the list), although I suppose he could have said that about both.

  • Re:Job market (Score:2, Informative)

    by jwsmith00 ( 262885 ) on Friday October 24, 2008 @10:04AM (#25497215)

    I wrote this up quickly this morning. I'd like to expand on it a little bit.

    If you're looking for a profession where you don't have to continually upgrade your skills, then COBOL is for you. You can go for many many years without having to learn the new latest craze in the industry.

    I work supporting Peoplesoft code which has a large COBOL base of code that we need to support and customize. I have a couple Java certifications, but I am not doing anything related to it. I got the Java certs simply to redeem myself in a way. I wanted to know I could still write thread safe GUI object oriented code in a client/server environment and that's what the SCJD did for me. But the COBOL pays the bills.

    Now if you want to code in Java or any other modern language, that's fine. But be prepared to have to continually upgrade your skills. Be prepared to get past the resume screeners and first interviews that you will need to get through to get jobs. But as an example, if you don't know a specific version of hibernate, you may be out of luck.

    There is also a lot of truth in the COBOL is written once, modified hundreds of times, and runs for decades. That's job security! Java is re-written in the latest craze framework every few years. That might be considered job security, except the fact that HR staff will seek out people specifically with those skills. Constant upgrade of skills on your part is important.

This process can check if this value is zero, and if it is, it does something child-like. -- Forbes Burkowski, CS 454, University of Washington