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:
  • 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 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 Zordak ( 123132 ) on Thursday October 23, 2008 @02:26PM (#25485217) Homepage Journal
    Get ready to shell out some money. I think to compile the examples in Cobol for Dummies, you need a copy of Microsoft Visual Cobol. Those licenses aren't cheap.
  • 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.

  • by bonch ( 38532 ) on Thursday October 23, 2008 @02:30PM (#25485273)

    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 Anonymous Coward on Thursday October 23, 2008 @02:31PM (#25485289)

    Back when I was in school, my COBOL prof brought a statistic up to everyone. There are more lines of code written in COBOL than every other language combined. We asked him the same thing, and consider re-designing the frameworks and applications COBOL programs run on, as well as converting the code over. That would cost quite a bit. Keep in mind, if it ain't broke, don't fix it. Mainframe code doesn't need to be changed as often as other code.

    We all thought BS, but when you think of all the systems that run anything related to nitty gritty banking transactions, invoicing, let alone any mainframe service... you start to realize that .NET and equivalent languages are just a small part in the presentation and application layers.

  • by Anonymous Coward on Thursday October 23, 2008 @02:39PM (#25485391)
    A rewrite will bring also an amount of opportunities to reduce operational costs, add new functionality, adapt the system to new business needs and don't pay outrageous consulting fees to ibm. Sometimes the best option is a complete rewrite.
  • 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.
  • 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)

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

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

  • by Applekid ( 993327 ) on Thursday October 23, 2008 @02:58PM (#25485725)

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

  • by CrazyBusError ( 530694 ) on Friday October 24, 2008 @05:52AM (#25495489) Homepage
    That's why you have coding and variable-naming standards.

    Seriously - 10,000 lines? I regularly work on programs with at least ten times that. Not including the copybooks. Use a sensible variable naming convention, plenty of level-88s and redefines and you're sorted. And like any other language - *comment the code*. There's really no excuse given that, without too much difficulty, it's quite easy to write virtually self-documenting code anyway.

    And the biggest aid to working on it? A decent damn text editor. I can never understand why so many COBOL developers hobble themselves with what are essentially line editors, when the facilities exist to bring the code across from the development platform, edit it with something like gvim (which has COBOL syntax highlighting) and actually have a clue what they're doing.

    Yes, I'm 33 and I'm a COBOL developer. No, I've no idea how that happened either...

With your bare hands?!?

Working...