Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Programming Security IT

Major Banks and Parts of Federal Gov't Still Rely On COBOL, Now Scrambling To Find IT 'Cowboys' To Keep Things Afloat (reuters.com) 300

From a report on Reuters: Bill Hinshaw is not a typical 75-year-old. He divides his time between his family -- he has 32 grandchildren and great-grandchildren -- and helping U.S. companies avert crippling computer meltdowns. Hinshaw, who got into programming in the 1960s when computers took up entire rooms and programmers used punch cards, is a member of a dwindling community of IT veterans who specialize in a vintage programming language called COBOL. The Common Business-Oriented Language was developed nearly 60 years ago and has been gradually replaced by newer, more versatile languages such as Java, C and Python. Although few universities still offer COBOL courses, the language remains crucial to businesses and institutions around the world. In the United States, the financial sector, major corporations and parts of the federal government still largely rely on it because it underpins powerful systems that were built in the 70s or 80s and never fully replaced. And here lies the problem: if something goes wrong, few people know how to fix it. The stakes are especially high for the financial industry, where an estimated $3 trillion in daily commerce flows through COBOL systems. The language underpins deposit accounts, check-clearing services, card networks, ATMs, mortgage servicing, loan ledgers and other services. The industry's aggressive push into digital banking makes it even more important to solve the COBOL dilemma. Mobile apps and other new tools are written in modern languages that need to work seamlessly with old underlying systems. That is where Hinshaw and fellow COBOL specialists come in. A few years ago, the north Texas resident planned to shutter his IT firm and retire after decades of working with financial and public institutions, but calls from former clients just kept coming.
This discussion has been archived. No new comments can be posted.

Major Banks and Parts of Federal Gov't Still Rely On COBOL, Now Scrambling To Find IT 'Cowboys' To Keep Things Afloat

Comments Filter:
  • Milk Them (Score:2, Interesting)

    by Anonymous Coward

    I hope all these COBOL programmers are smart enough to charge outrageous rates. Minimum $250/hr.
    They've got the banks over a barrel, any time the situation is reversed the banks don't hesitate to screw us.

    • Re: Milk Them (Score:5, Insightful)

      by Type44Q ( 1233630 ) on Monday April 10, 2017 @12:08PM (#54207341)
      $250/hr is an "outrageous rate" to charge a bank? What are you, 14??
    • Re:Milk Them (Score:5, Interesting)

      by swillden ( 191260 ) <shawn-ds@willden.org> on Monday April 10, 2017 @01:46PM (#54208277) Homepage Journal

      I hope all these COBOL programmers are smart enough to charge outrageous rates. Minimum $250/hr. They've got the banks over a barrel, any time the situation is reversed the banks don't hesitate to screw us.

      $250 per hour is a pretty normal rate for an experienced professional, hardly outrageous at all. When I worked for IBM Global Services, they billed me out at $300 per hour. Granted that IBM commands a premium due to their marketing channels, but I'm sure I could have gotten $200 per hour on my own and my expertise is far from as rare as deep COBOL experience. I'd expect people like the one mentioned in the article to cost more like $500 per hour, if they're actually aware of their own worth, and I wouldn't consider even that outrageous.

      If I were in the position of those programmers, I would probably try to avoid quoting an hourly rate at all. Instead I'd do it all as piece-rate work, based on detailed specifications -- especially if I'm working on a system that I know, so I have a good idea of what sorts of obstacles I might run into. Then I'd try to set my price based on the value of the work to the business, rather than on the time it would take me to produce it. That could easily result in contracts that work out to many thousands of dollars per hour.

      A friend who is a lawyer told me that the best piece of career advice he ever got from his father, also a lawyer, is "Take the money, son." He didn't mean to take money for unethical work, but just that one shouldn't balk at accepting high fees just because they seem too high. If the customer is willing to pay, take the money. That attitude should absolutely be applied to doing contract work for banks.

  • by religionofpeas ( 4511805 ) on Monday April 10, 2017 @12:05PM (#54207323)

    Any good programmer can learn to program in COBOL given enough financial incentives.

    • Indeed. Probably the easiest language I ever had to learn. I'm sure I've mostly forgotten it now because I've never used it since I learnt it in University (besides converting some old Cobol to VB6 a long time ago... but that was reading not writing).

      • by Archangel Michael ( 180766 ) on Monday April 10, 2017 @12:34PM (#54207583) Journal

        Easy to learn, fairly easy to read. However, the Lords of Cobol are masters at programming in a way that most people today can't think. it is a quite literal programming language.

        • It's not just the COBOL language you have to learn, you also have to know JCL (Job Control Language) CICS (Customer Information Control System) and SQL (Structured Query Language) - most programmers will already know SQL - but you are going to have to deal with the little quirks of DB2 sql. Now depending on your environment you MAY have someone else there who is the JCL expert and they can write the jobs, but you still need to know enough to read them otherwise the JCL expert is going to be a VERY busy per
      • by Jerry ( 6400 )

        Been there, did that, but with VFP6, which is also a dead language.

    • by aicrules ( 819392 ) on Monday April 10, 2017 @12:37PM (#54207631)
      I agree. I haven't even "learned" it but I was able to contribute to fixing a project that had it. In 2012 at a major pharmaceutical company merger I got tired of being told some mainframe cobol thing was working one way and seeing it work another. So we finally did a live code walkthrough and I easily spotted the logic error that was causing the actual behavior. Granted this COBOL was written and structured about as well as COBOL could ever be, but in the end it's just another set of terms and syntax to learn.
      • I agree. I haven't even "learned" it but I was able to contribute to fixing a project that had it. In 2012 at a major pharmaceutical company merger I got tired of being told some mainframe cobol thing was working one way and seeing it work another. So we finally did a live code walkthrough and I easily spotted the logic error that was causing the actual behavior. Granted this COBOL was written and structured about as well as COBOL could ever be, but in the end it's just another set of terms and syntax to learn.

        More than that, COBOL has far fewer features than any modern language, making it even easier to figure out what's going on. If you know any computer language you can easily determine exactly what 99% of all COBOL programs are doing simply by looking at them. That doesn't make you a COBOL programmer, but it's not like Ruby where you really have to know the language to a pretty good extent to figure out what a block of code does.

    • This.

      I took COBOL and it was one of the easiest to understand.

      The goddam language is almost English. Fuck, I never had to "press 2."

      Mr. Hinshaw needs to be teaching a bunch of COBOL graduates.

    • by kiviQr ( 3443687 )
      The thing they are looking for is experience. I have seen people who came into Java from main frame systems. They wrote Java in a main frame/functional way. No thank you.
  • by freeze128 ( 544774 ) on Monday April 10, 2017 @12:10PM (#54207349)
    I worked for a company 20 years ago that had a Windows program written in VISUAL COBOL. It was terrible. It crashed all the time. When it worked, it was slow. We don't need more COBOL programs, but I hardly think that Python is the answer.
    • Re:COBOL (Score:4, Interesting)

      by rickb928 ( 945187 ) on Monday April 10, 2017 @12:23PM (#54207487) Homepage Journal

      I supported several apps based on Microfocus COBOL and so-called Visual COBOL. No significant problems with either platform, the apps worked as well as thne programmers did, or more correctly, bugs happened. One was rock solid, the other had predictable issues with every major release that were resolved without much delay.

      Stereotyping COBOL is inevitably just age discrimination. It's functional, as the history and current situation proves. It's a language, competent programmers that have progress from C to C++ to Java will figure it out if they see profit in doing so. I work with an old-school COBOL programmer who has no patience with the young whippersnappers who whine about every problem a legacy platform presents. There is so little interest around here to abandon the core transaction systems that claims that COBOL is 'obsolete' fall on deaf ears. They train new maintainers here. What a concept, training your team! Gah!

      • Re:COBOL (Score:4, Interesting)

        by shadowknot ( 853491 ) * on Monday April 10, 2017 @12:35PM (#54207605) Journal
        The COBOL programmers at my place are actually using it to develop new functionality that's keeping up with the financial world and actually pushing the leading edge. They've done nightly program releases since literally decades before the term "agile" was a thing. The notion that COBOL is just a legacy hold on that is in maintenance mode everywhere is also somewhat of a misconception. That's probably the case in some locations where it's providing a core business function and the rest of the infrastructure has evolved around it to patch the functions that support whatever the modern requirements are but there are plenty of people using it to create new function as well.
    • I worked for a company 20 years ago that had a Windows program written in VISUAL COBOL. It was terrible. It crashed all the time. When it worked, it was slow. We don't need more COBOL programs, but I hardly think that Python is the answer.

      I imagine the failure modes revolved around the words "Windows" and "Visual" rather than "COBOL". As other posters have pointed out, running real COBOL on grown-up, production hardware like IBM System z, etc... is a better metric.

  • by mykepredko ( 40154 ) on Monday April 10, 2017 @12:10PM (#54207353) Homepage

    Ever since I first joined /. there has been an article a year stating:
    - Major organizations, banks, governments, etc. are still relying on COBOL.
    - COBOL programmers are in great demand so dust off your old MVS skills (and maybe pull out those JCL manuals) and offer up your services, you're in demand!

    What I really think is the big takeaway from all this is simply that the need for supporting for your old software is never going away - so think of a way of monetizing it.

  • by reginaldo ( 1412879 ) on Monday April 10, 2017 @12:11PM (#54207363)
    From what I've seen, the issue in finding developers for these codebases isn't in the language knowledge (i.e. COBOL), it's in the knowledge of the poorly-documented legacy software. Sure, you can get a developer to learn COBOL fairly easily, but when the software is full of dead ends, spaghetti code, and unknown business logic and workflow logic, their knowledge of COBOL won't help. Instead you need to hire someone who knows the system, and was probably complicit in creating this mess, to do anything. Either that or bite the bullet and start a huge replacement project that costs several magnitudes more than exorbitant hourly rates.
    • by barc0001 ( 173002 ) on Monday April 10, 2017 @12:27PM (#54207533)

      Except the linked article specifically notes that the 75 year old's company is a group of 20 or so "code cowboys" who parachute in to fix systems they have no prior knowledge of and get paid $100/hr for the pleasure. So it would seem deep understanding of the language and the ability to troubleshoot bad code in said language is indeed the crux of the issue.

      • by Tablizer ( 95088 )

        So it would seem deep understanding of the language and the ability to troubleshoot bad code in said language is indeed the crux of the issue.

        It could be both. Bad code can be written in ANY language such that COBOL itself is not necessarily the direct problem, but rather mis-use of COBOL by the original-but-gone staff. If the original code was in say Java or Ruby, it too could have been sloppy code, leading to the same problem.

        And if there are no domain (subject) experts around, then the organization may

      • The only reason these "code cowboys" are of note is because nobody new wants to bother learning what they've learned. The only barrier to entry preventing some millenial from learning COBOL is the lack of consistent jobs maintaining COBOL code. If these cowboys die of old age, the demand for people who can fix/modify COBOL code would lead to a few young people learning it and being paid $100/hr. This isn't the Middle Ages, where craftsmen kept trade secrets which they passed on to their heirs only in whi
        • by barc0001 ( 173002 ) on Monday April 10, 2017 @03:11PM (#54209107)

          > The only barrier to entry preventing some millenial from learning COBOL is the lack of consistent jobs maintaining COBOL code

          Actually, no. There are plenty of jobs at unexciting companies for long term full time COBOL programmers. The company I work for, for example is constantly looking to backfill retiring COBOL programmers in one of the financial divisions. To be honest, if I had to do life over again I'd seriously consider picking up COBOL 25 years ago as the wage and job security at those big companies for that position are great - no offshore outsourcers do COBOL, and even if they could, many of the systems involved are sensitive financial systems so outsourcing that could be a big legal minefield so no company wants to risk it. Plus the added little bonanza of the whole Y2K thing where COBOL programmers were making INSANE money in the year leading up to it - like $200/hr insane. In 1999 dollars as well.

    • Indeed it's not just the language - it's exceptionally verbose and you're hardly likely to misunderstand the meaning of "MULTIPLY NumA BY NumB GIVING NumC."

      Partly, it's about understanding the way data is encoded (which is likely to be packed decimal or ASCII/EBCDIC numeric characters) but when people say "COBOL" they're often referring to code that's intricately linked (possibly through embedded macros) to legacy transaction-processing systems (like CICS) or legacy CODASYL (network-model - as opposed to re

    • by reanjr ( 588767 )

      Some of us actually thrive doing this sort of work. Rewriting working code is such a lazy cop-out.

    • This is the issue.

      I won't go into more details as I'm writing analysis software for these type of systems (iSeries/AS400 rather than Z/Big Iron).

    • Either that or bite the bullet and start a huge replacement project that costs several magnitudes more than exorbitant hourly rates.

      Cost is only part of the reason why replacement projects are avoided. Another major reason is the risk involved. Software developed in the 60s, 70s or 80s couldn't rely on many things we take for granted these days. Requirements engineering, robust libraries, development tools, testing mechanics and so on (warts and all) just were not quite there yet or did not exist at all.

    • This.

      In my experience, inheriting legacy apps is very difficult because there's a steep learning curve before ever touching anything.

      To fully grok the application, I had to read and understand and become the past programmer(s) so that I could predict what and how the program worked as the program pointer zipped along.

      I could recognize different programmers by the signature coding approach in each module.

      Then there's my world view, which I used to reshape the whole goddam thing.

      Coders before me never documen

    • Actually it is much, much worse.

      In the 1960's and 1970's compilers, and particularly COBOL compilers, were very expensive. They could easily cost more than a decent home.

      This produced an interesting business model where a few programmers who happened to own a compiler would write custom software for various businesses. When the business wanted their software modified, they could contact the original authors and pay them to make the changes. Nice business model with a nice lock-in, The problem was that s

  • Where? (Score:2, Informative)

    by Anonymous Coward

    Every year I see articles about how COBOL programmers are in high demand and companies are scrambling to hire them. But I learned COBOL and liked it and regularly keep my eye out for COBOL jobs. In the past 15 years I have seen a grand total one one COBOL placement within 1,000 miles. I call BS on the article, the local job boards are all for Java, C++, mobile languages and PHP. Not a COBOL position in sight.

    • by TWX ( 665546 )

      I suspect that most entities that look for this kind of service don't post it in this way. Financial institutions in particular seem to play their cards close to the chest, they probably work with specific hiring agencies or headhunters to fill positions and don't just post them openly.

    • by creimer ( 824291 )
      When I worked at Fujitsu in 1997, our virtual world division got a temporary vice president from Japan for three monhts. This VP was in charged of mainframes. He always asked the same question in broken English, "Are you a mainframe programmer?" He was disappointed that no one in our division was a mainframe programmer. For years since then I've always heard that mainframe programmers were in high demand. The catch, of course, is having previously worked on mainframes. Seems like no one wants to hire an ine
      • mainframe programmers were in high demand

        Sort of - but somehow, in spite of the "high" demand, mainframe programmers don't command much pay. As in, I have about 5 years of mainframe (COBOL, JCL, Adabas Natural) programming experience, but I clawed my way out of it into desktop C++ programming just so I could make enough money to actually afford a car payment. If I went back to it now (from my current "enterprise Java" role), I'd probably take a 50% pay cut.

    • Every year I see articles about how COBOL programmers are in high demand and companies are scrambling to hire them. But I learned COBOL and liked it and regularly keep my eye out for COBOL jobs. In the past 15 years I have seen a grand total one one COBOL placement within 1,000 miles. I call BS on the article, the local job boards are all for Java, C++, mobile languages and PHP. Not a COBOL position in sight.

      You're obviously not a part of the Order of the Secret Knights of COBOL. The OSKCOBOL cabal keep all those lucrative COBOL jobs hidden from prying eyes of interferers. Let me know when you know the secret handshake and we'll open up the cushy job market of $500,000 per anum COBOL jobs to you.

  • "You will get no course credit for COBOL, but you might want to take the class so you can get a job between semesters"

    Few of us did (and I wasn't one of them), but those that did always had jobs come summer while a lot of the rest of us didn't.

    • The grass isn't always greener. I did take that advice, and I did get a job maintaining decrepit mainframe-based COBOL for the U.S. government (I was making about $25K/yr). Then when I graduated, I proudly put that _real world_ experience on my resume. And found out that the only people who would talk to me were the people who were looking for COBOL programmers, and were paying half what they were paying C++ programmers. So you may have missed out on a summer of slightly-above-minimum-wage employment, b
  • And everyone says it's impossible for programmers to find jobs after 40...
  • Why not use a program from the 50s and 60s? Don 't you want to make America great again?
    • by creimer ( 824291 )

      Why not use a program from the 50s and 60s?

      The mainframe are probably from the 50's or 60's.

      Don 't you want to make America great again?

      Scrape the Old Iron and buy New Iron from IBM! No one ever got fired for buying IBM.

      • About IBM...well, that's only IF you didn't buy anything from a division that got spun off to China. This question, concerning the Missile Defense Agency supply chain came in late last year:

        Does your supply chain utilize Lenovo Group Ltd (To include its subsidiaries: LenovoEMC, Medion AG, Stoneware Software, Motorola Mobility, NEC, Nok Nok Labs, and IBM PC Division) manufactured or produced Information and Communications Technology (ICT) products, including Hardware, Software, and/or Firmware components
        • by creimer ( 824291 )

          About IBM...well, that's only IF you didn't buy anything from a division that got spun off to China. This question, concerning the Missile Defense Agency supply chain came in late last year:

          I was thinking of IBM of yesteryear. That particular division, IIRC, was the PC/laptop division that went to China.

          My assumption is that it's a recognized fact that PLA Unit 61398 and others have infiltrated the above companies. This is coming straight from General Dynamics, and imposed by the DoD.

          Doesn't surprised me. When I worked at Google in 2008, they found backdoors in the BIOS for the newer Lenovo laptops and were planning to move away from Lenovo. I didn't see any Lenovo laptops when I worked there on contract in 2011.

  • by Lumpy ( 12016 ) on Monday April 10, 2017 @12:53PM (#54207781) Homepage

    They are having trouble finding people AT THE REQUESTED PAY, they are looking to pay chump change of $30K

    Multiply the pay you are asking by at least 6 and you will get a Cobol programmer within hours. If you use something outdated and rely on it, then be ready to pay extremely well to get someone that is an expert in it. Most anyone I know that is a Cobol guru wont even bother to apply for something under $150K a year.

    So if they really wanted someone, they will increase the pay and benefits to entice a person to actually apply. Sadly this basic element of business is lost on todays morons that are "leaders" and "managers"

  • by SuperKendall ( 25149 ) on Monday April 10, 2017 @12:59PM (#54207859)

    For the specialization and demand that the COBOL work offers (not to mention the familiarity with how to use the tooling and platforms that surround those systems!) the people should be asking for a minimum of $500/hour.

    After all it's all large financial institutions that are brimming with money, and like the said literally billions of dollars flow through these things every day.

    So if you are out there and you know COBOL I would double your rate today. If anyone asks just say that a number of people you knew who did COBOL contracting all just retired and so demand is through the roof.

  • by nitehawk214 ( 222219 ) on Monday April 10, 2017 @01:38PM (#54208203)

    People would be happy to learn COBOL in school if it did not suck the life out of people that touch it. And now that the only remaining jobs are maintenance ones, there is even less incentive.

  • I worked for a software company who's flagship application, which was medical related, was written entirely in Logo. Apparently, early on someone slapped together some prototyping to show management. Management being management proceeded to dictate that the entire application actually be written in Logo. I could not believe it, yet there it was.
  • by computational super ( 740265 ) on Monday April 10, 2017 @01:59PM (#54208389)
    Nobody's willing to pay experienced COBOL programmers all that much, even though they're demonstrably scarce.
  • My college offered 4 semesters of COBOL. It was the worst experience of my time there, and one of the biggest reasons why I dropped out. Fuck COBOL. Sure there's the whole "if it ain't broke, don't fix it" mentality, but I mean, a screen door "ain't broke" but it's also not the best idea to fit your front door with. A Speedo "ain't broke" but it's also not best for winterwear... Time for the dinosaurs to upgrade. The money spent now would be cheaper than the ever-increasing maintenance fees over time.
  • I'd like to begin by adding that an experienced programmer (let's say somebody with over a decade of experience) should be able to pick up any language. If you have been exclusively using one programming language for your entire career including college, then you must be one in a million. Most programmers that I encounter have picked up dozens of languages and syntaxes over the years. When I received my first royalty check for programming in 1987, I was programming a Commodore 64 in BASIC with as little mac

  • These institutions screwed loads of us after Y2K so I'm highly amused to see them panicking. They'd have to offer me vast sums of money to go anywhere near them now.

"Consequences, Schmonsequences, as long as I'm rich." -- Looney Tunes, Ali Baba Bunny (1957, Chuck Jones)

Working...