Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
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:
  • by tha_mink ( 518151 ) on Thursday October 23, 2008 @02:14PM (#25485041)
    Kill me.
  • Comment removed (Score:4, Interesting)

    by account_deleted ( 4530225 ) on Thursday October 23, 2008 @02:16PM (#25485067)
    Comment removed based on user account deletion
  • by Anonymous Coward

    Or as I refer to it "COBOL of the 90s"

  • by mmxsaro ( 187943 ) on Thursday October 23, 2008 @02:19PM (#25485113)

    Why is Cobol still alive and in demand? What's so good about it? Why can't we just port everything over to a newer language and be done with it?

    Doesn't it cost more to keep paying these rare programmers than to just update/convert/replace the systems?

    • by truthsearch ( 249536 ) on Thursday October 23, 2008 @02:25PM (#25485205) Homepage Journal

      A company can spend a few million dollars rewriting and thoroughly testing a replacement system. Or they can spend less than 10% of that to have one Cobol developer keep the system up and running.

      Very often, the old systems have been working smoothly for many years. A rewrite will bring a monstrous amount of headaches and cost, especially for key systems like financial transactions.

      • A company can spend a few million dollars rewriting and thoroughly testing a replacement system. Or they can spend less than 10% of that to have one Cobol developer keep the system up and running.

        Very true. We're in a similar situation. We have an an AS/400 system and are running TONS of old COBOL code written somewhere in the way back yonder of time. The interfaces are clunky, the data storage ideas are . . . odd (to someone who thinks in terms of relatioal databases anyways), but they are all stable and bugs are a rarity. Now, we DO try to replace these programs as we can, but we're faced with a problem:

        (1) The powers that be have decided that in-house programmers are a dying breed. As such e

    • Comment removed based on user account deletion
    • by Ngarrang ( 1023425 ) on Thursday October 23, 2008 @02:28PM (#25485233) Journal

      Why is Cobol still alive and in demand? What's so good about it? Why can't we just port everything over to a newer language and be done with it?

      Doesn't it cost more to keep paying these rare programmers than to just update/convert/replace the systems?

      Because it is cheaper to patch code written in 1970, than re-write it and go through the QA process to insure the end product does the same thing.

      That is why.

      • Re: (Score:3, Insightful)

        by AppyPappy ( 64817 )

        Especially when you are not really sure what the code does. If it works, you try not to mess with it. Many of these systems were written when memory was pricey and variable names cost something. It can be hard to figure out what they did when you are trying to analyze a variable called WC03-IDX that is used 62 times. COBOL may be "fat" but memory and processors are cheap now. I worked for a company that hired non-programmers to cut code and handle maintenance. It was all in COBOL. Nice, easy-to-read-at-2AM

      • by Kozz ( 7764 )

        Because it is cheaper to patch code written in 1970, than re-write it and go through the QA process to ensure the end product does the same thing.

        Unless you're actually talking about insurance (which I suppose you technically could) the word you're looking for is "ensure". </pedantic>

        • Unless you're actually talking about insurance (which I suppose you technically could) the word you're looking for is "ensure". </pedantic>

          Thank God I'm not the only one around here...

          • Thank God I'm not the only one around here...

            I appreciate the kind axe of the pedants. Were it knot for them, we woodn't realize hour typing errors. Thank ewe!

            Pedants unite!

          • IF WS07-INSULT-TXT = 'LOOSER'
                  MOVE 'LOSER' TO WS07-INSULT-TXT
                  MOVE WI01-USERID TO WA01-USER-LIST[WX01-IGNORANT-SHITKICKER, WX02-IX)
                  ADD +1 TO WX02-IX
            END-IF.

      • Re: (Score:3, Insightful)

        by sohp ( 22984 )

        Cheaper in the short term, and the long term costs are difficult or impossible to see. As anyone who has been paying attention to economic news lately knows, it's all about the short term, and damned be the long term.

        There's no good economic or technical reason to keep these systems around -- the fact that they are still being used and patched is a reflection of office politics and managerial failures.

    • Re: (Score:3, Interesting)

      by bonch ( 38532 )

      If you have a financial institution running on an existing reliable mainframe, why would you disturb that? In the real world, updates don't happen all that often if something already works.

      • by dgatwood ( 11270 )

        Depending on what sort of mainframe we're talking about, the answer quite often is "...because when that existing reliable mainframe takes a lightning hit, you'll probably have to rewrite the software in a modern language to run on a modern system anyway because you won't be able to get parts to fix the ancient behemoth."

        Good managers realize that bad things happen and they try to plan major changes like that ahead of time so that they can happen on their terms instead of on somebody else's. Even in the be

        • GUIs are doubtless easier to learn than text based entry but, if speed is a consideration, a text-based entry system is much faster.

    • Re: (Score:3, Insightful)

      by LWATCDR ( 28044 )

      Because it works?
      A good programmer is a good programmer. They all cost about the same.
      Really if you have a system that works why pay to reinvent the wheel? The pay to retest it.

      So the answer is. Because it works.

      • Re: (Score:3, Interesting)

        by Applekid ( 993327 )

        A good programmer is a good programmer. They all cost about the same.

        Although, the point of TFA is that the COBOL job market is heating up. As in, COBOL programmers are starting to command greater salaries due to a supply and demand.

        Which, if it keeps going that way, will turn itself right around when the salaries (company expense) gets high enough to justify rewrites.

        • by LWATCDR ( 28044 )

          Not really, as the salary goes up more people will brush up on their Cobol skills expanding the pool. In a company that is dependant on Cobol you will probably have some VB, C#, and or PHP/Perl/Python coders.
          The best of them will see that learning Cobol is worth the effort and move into a Cobol seat.

    • Re: (Score:3, Insightful)

      by Ironsides ( 739422 )
      How much do you trust your paycheck to get to you on time with a brand new piece of code vs. one that hasn't had any problems in 30 years?
    • Re: (Score:3, Insightful)

      by jjohnson ( 62583 )

      On an industry wide scale, it probably does cost more to keep paying COBOL programmers to maintain legacy systems. But at any individual company, the short-term cost of paying a high hourly rate to an aging COBOL coder to keep the wheels turning is much less than the cost of rebuilding the system that's run the company for forty years.

      Remember Schwarzenegger wanting to cut California state employee's salaries to minimum wage for the duration of a budget crisis? It was the state IT department that nixed th

    • by Mariognarly ( 1026290 ) on Thursday October 23, 2008 @02:40PM (#25485399)
      It's alive because its ancient, and it was designed by the military. It was designed with the intent to be as robust as possible, and as simple as possible... and that's why it still runs the majority of mainframes today. Mainframe code also doesn't need to be changed that often. There just hasn't been any new latest and greatest features in any other language viable enough to justify a code conversion. My prof in uni was a COBOL guy, and his masters thesis touched on OOP vs top down single line programming featuring C vs COBOL, and the code complexity between the two. He showed us several applications written in C, and COBOL that did the same thing. More often than not the C code was 10-20 pages long, and the COBOL was 2-4. We usually could comprehend and update the COBOL code much faster than the C. The integration with databases was far more seamless, and it just was a really pleasant programming experience. Lots of kids (including myself) loved COBOL because it was easy to wrap their heads around it logically and structurally, while lots of the traditional OOP kids struggled because it was out of the norm of their experience. I believe the going rate for COBOL programmers back when I was in uni was $230 / hr. They were pulling a lot of people out of retirement to fulfill projects, and my prof was one of them. Kinda cool niche to the industry I think.
    • Re: (Score:2, Interesting)

      by dedazo ( 737510 )

      Because it's supported by companies like IBM. There's infrastructure and investment behind the whole thing, and firms have felt comfortable betting the farm on those types of technology for 30+ years. There's also a lot of money to be made supporting it.

      The mainframe platform does move, albeit at a rather glacial pace. They've been doing Java for a few years now, as well as web-based interfaces as an alternative to terminals.

    • by DerekLyons ( 302214 ) <fairwater@@@gmail...com> on Thursday October 23, 2008 @02:45PM (#25485477) Homepage

      Why is Cobol still alive and in demand?

      Because there still exists in the world companies and people that have priorities other than "the latest l33t technology".
       

      Why can't we just port everything over to a newer language and be done with it?

      Assuming the hardware can run the newer language of course... But you still have to face the same basic problem, in a few years your l33t "newer language" will no longer be l33t or newer - it's be the stodgy old stuff that only crusty old farts program on. What then? Go through the same exercise every five to ten years?
       
      That sounds more like a recipe for keeping programmers employed, regardless of value, than it does for keeping a system stable and operational. (Which a large part of why IT is often viewed with such suspicion in many quarters - because the constant rewrite/upgrade cycle that keeps the IT departments e-penis turgid rarely seems to provide much of a ROI.)
       

      Doesn't it cost more to keep paying these rare programmers than to just update/convert/replace the systems?

      A handful of (COBOL) programmers costs the company just a couple of million dollars a year for a stable functional system. A stable of ($l33t_language) programmers costs about the same, plus the potential costs of hardware changes, plus the potential for months of disruption or loss of data...

    • by McSnarf ( 676600 ) * on Thursday October 23, 2008 @02:48PM (#25485525)

      Now... As a former COBOL programmer - this is not just switching one outdated language to something new. For one, COBOL is actually excellent when it comes to doign things it was meant to do, which is commercial software. Need a choice of storing numbers in characters, BCD or float? Reasonable string handling (UNSTRING comes to mind) and a gazillion of other useful features? COBOL is somewhat limited, but very powerful for a certain, limited set of applications. PL/I can do about everything COBOL can - and better, but for some reason, it never became THAT popular.

      (Now if it COBOL only had an ALTER ... TO PROCEED TO ... DEPENDING ON ... )

      I doubt that you can translate it automatically into somewhat readable code in whatever language of choice you might have in mind. That, plus the fact that a lot of COBOL code in use today has been working (and been improved) for more years than Linus Torvalds spent on this planet so far, makes it difficult to replace. (Not to mention the side effects. Imagine rewriting - from scratch - a complex insurance application which comes with CICS (no problem, runs under loads of platforms nowadays), VSAM (you don't want to know) and other file access methods and tons of JCL written for a JES3 environment. Trust me - Unix is trivial by comparison. And you need to understand both to migrate the stuff.

    • Sure you can, for a hefty price: http://www.bphx.com/en/Pages/default.aspx [bphx.com]
      No, I don't work for them. I did get offered a job but turned it down.
    • The legacy COBOL systems are huge and battle-hardened. It took millions upon millions of dollars to build them. It's always cheaper to hire a new $120k/yr developer than to rewrite the entire system.

      To wean off of a system like this you have to write all new software in a hardened modern language. Then take chunks of the legacy functionality and methodically convert it over to the new modern-language-based replacement module.
    • Because it lets us continue to run applications that are 30 years old or more.

      See, bureaucracy gets a bad rap. It isn't, after all, a four-letter word. Bureaucracies let your business grind through the day-to-day stuff without constant intervention. Set up a proper bureaucracy and business can keep running through that flu epidemic, or those retiring employees, or that corporate takeover.

      Sure they can be cumbersome and inflexible. But they can by god run themselves, if done right.

      Now a 30 year
    • There a many, many good things about COBOL. No it's not good at all for wrinng web based apps and device drivers. But there are features built into the language for DBMS interface and forreport writing. For example to write a report that has breaks and subheader andcolums change you don't have to write the logic, just specify how it should work. Soyou are wrinting at a level of 'what to do" rather then "how to do". Complex print formatting is the same. COBOL can use a "picture" rather than C's format c

    • How long is it going to take you to re-write one program I wrote in the early 80's - 5700 lines that includes some lines written by a program before it (1200 lines) and compiled without human intervention every time it is run?

      How about programs where even the source code was lost?

      Many many COBOL programs do things that defy the ability to use a program to translate them, so it is all a hand effort.

      And COBOL is very very good at moving data from point A to point B, especially text data.

      And finally, COBOL was

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

      by Shivetya ( 243324 )

      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

    • by Locke2005 ( 849178 ) on Thursday October 23, 2008 @03:35PM (#25486377)
      Have you seen the documentation for those legacy systems?

      Neither has anyone else!

      Trust me, porting code you don't understand is not an option.

    • by Gonoff ( 88518 )

      ? in demand?
      Because it works, is easy to read, and there is a ***LOT*** of it out there.

      What's so good?
      It is not Object Oriented. I know it can be nowadays - just like MS kludged VB - but it isn't really.
      Real COBOL is text based and can be moved from one platform to another. You write your code in linux your team leader uses Windows and it ends up on a mainframe.

      port it?
      I read somewhere that it is big in banks and corporations.. It said there was more money invested in that code than anything e

    • by mrops ( 927562 )

      I had some experience with this. Our company was hired to make an ancient insurance system modern, Java/Hibernate/spring, the works.

      Turns out they have claims being processed round the clock, some back from the 70s related to asbestos poisoning. When we incorporated federal guideline requirements, turned out there was no way we could migrate from the old system to the new system. Not easily anyway. Further, this COBOL system had years of federal guidelines coded in. 25 odd years of federal policy changes. V

  • 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 Anonymous Coward

      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 solut

  • by AppyPappy ( 64817 ) on Thursday October 23, 2008 @02:24PM (#25485191)

    Cue up the Theme from Shaft, I'm ready to walk that aisle. Twenty-eight years later, I am ready for my place in the sun. You bunch of Java-smoking hippies make a hole cause I'm coming through. I told you that personal microcomputers were a flash in the pan. Take your Winchester drives and Hercules graphics and shove em up your ass. Big Iron is here to stay.

    Dammit, where are my car keys? Honey, where are the keys to the Citation?

    • Re: (Score:3, Insightful)

      by illumin8 ( 148082 )

      Big Iron is here to stay.

      Awesome. You, sir, are a true legend, a veritable man among men, an uber-hacker.

      If you aren't part of the solution, there is good money to be made prolonging the problem

      Somehow, your sig feels fitting for this entire story.

  • Yeesh! (Score:4, Funny)

    by Benfea ( 1365845 ) on Thursday October 23, 2008 @02:32PM (#25485311)
    In other news, Cthulu has risen and has started eating nuns.
  • by daemonenwind ( 178848 ) on Thursday October 23, 2008 @02:40PM (#25485405)

    A couple of things people should realize when thinking about getting into mainframe/cobol:

    1. COBOL programmers are 99.9% baby boomers. If you want to spend your next decade getting talked down to by a 50-something or 60-something who thinks they're a programming god because of their teaching degree and 30 years writing COBOL, then you're probably into leather and whips, and would be happier staying in your dungeon. That's just my opinion, I could be wrong.

    2. COBOL is not challenging to learn (it's designed that way), and the programming tasks are largely mundane. You'll be working almost exclusively on data processing tasks, because that's what the mainframe does best: massive throughput of number crunching.

    3. You shouldn't just learn COBOL, you should spend time with JCL and DB2's version of SQL, and some CICS concepts would serve you very well. But without JCL and DB2, you're practically useless anyway. But they're not hard to learn.

    4. zOS also runs Java now, so if we just stay back and let it rot, eventually perhaps they'll just throw it all to Java.

    5. It's hard to just "take a class" on COBOL, but forward-thinking companies are starting to train people like disaffected teachers, just like what was done in the 70's. So if you want to work with/clean up after that sort of developer....

    If, after all this, you really want to know more, IBM has most of the useful documentation online.
    http://www-01.ibm.com/software/awdtools/cobol/zos/library/ [ibm.com]

    But the "dummies" book should serve you very well.

    Oh, and once you start working with them, expect lots of, "Why does my PC do this", kind of questions, because most of the COBOL people I've met in shops aren't very technical. (IBM people are bright enough though)

    • Do you make anymore writing COBOL than you would doing something else? If so how much more?

      Those are the important questions to ask here.
      • Re: (Score:3, Insightful)

        More as opposed to what?

        Only large organizations use mainframes, so it helps to look at that model.

        Large companies generally bin out salaries for most professionals. Developers are no exception.

        So you'll get tossed into an income bin with people of similar relative experience. Having a scarce skill will push your income towards the top of that bin. So if the range for "Developer 1" is $52,000 - $75,000, you'll be closer to the upper end. If you're comfortable being a contract consultant under your own n

    • So if you want to work with/clean up after that sort of developer....
      I've been cleaning up after C/C++ programmers for 25 years now. It's gotten to the point where I see no tangible difference between my job and that of the guy you see in every parade, following along behind the elephants/horses with a shovel and a broom...
    • Re: (Score:2, Informative)

      by Mong0 ( 105116 )

      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

  • Did I just sleep for 6 months?
  • time flies (Score:4, Funny)

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

    Is it 9999 already???

  • 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

  • Seriously, at this stage no one wants a beginner COBOL programmer and by the time I learn COBOL (which will probably take forever since I have zero care about it) it's little surge will probably be long gone.
  • by davecb ( 6526 ) * <davecb@spamcop.net> on Thursday October 23, 2008 @03:28PM (#25486249) Homepage Journal

    Many moons ago, I wrote a disassembler that emitted mock "c" syntax, which I could turn into real C with a few global substitutes.

    You can do the same with normal assembler syntax and an ad-hoc parser, and therefor you can turn the "accountant's assembler" from add foo to bar giving zot to zot = foo + bar;

    This is just a special case of the semantics-preserving transformation problem, which my old employer used to do on a daily basis (I worked in a porting shop).

    And yes, I'll do this for money if asked (;-))

    --dave

    • nope, the way a computer is directed to add via COBOL, and set the value of another variable has nothing to do with your c compilers direction to do a float or int add and assign that to a var.

      Specifying the (usually) internal decimal or packed decimal representation of a number, with or without sign, and the rules of how those digits are moved into another area of memory are neat tricks real business languages have that are very useful when dealing with money.

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

  • by Locke2005 ( 849178 ) on Thursday October 23, 2008 @03:32PM (#25486323)
    I used to joke about "Visual Cobol" being the next big thing in computer languages... that is, until I learned that it's a real product [amazon.com]!
    I still think this is a trick to get all those Chinese and Indian software engineers to train for a worthless language, so we can get our old jobs back...
  • Here's the question I'm interested in. How many COBOL programmers telecommute?

  • What would be todays Mainframe language?

    I read the specs of a current Sun Mainframe last week and it listed FORTRAN, COBOL, C++ and Java as the key PLs to develop apps in. FORTRAN! (No Joke!)

    I found that rather hilarious. And while I'd have no problem learning COBOL, if the payment is right. After all I've developed in Lingo (as far as developing is actually possible in Lingo), Transscript and the one or other bizar language in the last 10 years. And people still use SQL, which I personally consider the mos

    • On Unisys Dorado mainframes running OS2200 we tend to use Fortran, but Fortran has always been a commonly used language in the airline industry. Not COBOL so much.

      FWIW, Sun doesn't make "mainframes" in the traditional sense of the word. That term is usually reserved for boxes running an IBM OS (zOS) or one of the other legacy mainframe OSes (e.g., OS2200 from the UNIVAC world, MCP from the Burroughs world, etc.).

      Mainframes use a mix of compiled and interpreted languages just like any other complex platfor

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

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Working...