Please create an account to participate in the Slashdot moderation system


Forgot your password?
Businesses Programming Government Operating Systems Software The Almighty Buck

Should Banks Let Ancient Programming Language COBOL Die? ( 383

COBOL is a programming language invented by Hopper from 1959 to 1961, and while it is several decades old, it's still largely used by the financial sector, major corporations and part of the federal government. Mar Masson Maack from The Next Web interviews Daniel Doderlein, CEO of Auka, who explains why banks don't have to actively kill COBOL and how they can modernize and "minimize the new platforms' connections to the old systems so that COBOL can be switched out in a safe and cheap manner." From the report: According to [Doderlein], COBOL-based systems still function properly but they're faced with a more human problem: "This extremely critical part of the economic infrastructure of the planet is run on a very old piece of technology -- which in itself is fine -- if it weren't for the fact that the people servicing that technology are a dying race." And Doderlein literally means dying. Despite the fact that three trillion dollars run through COBOL systems every single day they are mostly maintained by retired programming veterans. There are almost no new COBOL programmers available so as retirees start passing away, then so does the maintenance for software written in the ancient programming language. Doderlein says that banks have three options when it comes to deciding how to deal with this emerging crisis. First off, they can simply ignore the problem and hope for the best. Software written in COBOL is still good for some functions, but ignoring the problem won't fix how impractical it is for making new consumer-centric products. Option number two is replacing everything, creating completely new core banking platforms written in more recent programming languages. The downside is that it can cost hundreds of millions and it's highly risky changing the entire system all at once. The third option, however, is the cheapest and probably easiest. Instead of trying to completely revamp the entire system, Doderlein suggests that banks take a closer look at the current consumer problems. Basically, Doderlein suggests making light-weight add-ons in more current programming languages that only rely on COBOL for the core feature of the old systems.
This discussion has been archived. No new comments can be posted.

Should Banks Let Ancient Programming Language COBOL Die?

Comments Filter:
  • Why not? (Score:3, Insightful)

    by __aaclcg7560 ( 824291 ) on Thursday April 27, 2017 @06:04PM (#54315901)
    Java is getting long in the tooth. Time for it to become the new COBOL.
    • Re: (Score:3, Insightful)

      by Slicker ( 102588 )

      Java is far more likely to go the way of the dodo bird than is COBOL. COBOL is well-optimized for business data processing. It's a fine language. What does Java have over it? COBOL is many multitudes easier to learn, code with, read, and modify. Programming languages started getting more complex, harder to learn, and use starting with C++. And OO design and programming has failed in each and every goal for which it was originally proposed. I understand that most modern programmers have learned OO fr

      • Re: Why not? (Score:3, Insightful)

        by Anonymous Coward

        Cobol is a horrible business language. Unicode? No. Variable sized data fields! no.. Threads? No. Useful libraries? No. Integration with other components? No.

        Just because it can add and subtract doesn't make it great.

        It just makes it basic.

      • Re: Why not? (Score:5, Interesting)

        by slack_justyb ( 862874 ) on Friday April 28, 2017 @02:01AM (#54317765)

        Holy shit dude. I'm a vet C++ programmer and the last three years mobile developer for warehousing company. However about a year before my current job, I worked in an exclusive AS400 shop. RPGLE, COBOL, CL, you name, it was still using the stuff from back in the day.

        The system was incredibly fragile and had insanely complicated builds with the labyrinth of binding directories, dependencies, the constant service program signature violations. Customers demanded new functionality and the system just had trouble keeping up. Old programmers would code crap like RPG still lacked arrays with abusing subfiles. They'd swear by using numeric indicators versus the new fancy types. Yeah, because IN73 being on tells me that I totally need to refresh the data on the screen. Eventually the company fired all of the RPG/COBOL programmers because they could never keep up with demand. They were short order replaced by an off the shelf solution and any new work was contacted out. I stayed on a few months more because I understood EDI and they needed someone to get that all setup on the new solution. Oh and it was Java based.

        Point though, you sound exactly like those old guys. OO over complicates crap and you don't need all that fancy stuff, blah blah blah. I work and coded DDS, SQL, RPG, and COBOL with those people for five years and I knew their mentality was just setting them up for obsolescence.

        The tech industry is brutal man and you've got to be a person keenly adept to rapidly adapt or you'll find yourself quickly no longer employed and lacking serious skills to find your next job. Two, besides myself, out of our group of nine found another job. Those two for jobs doing AS400 maintenance, took a pay cut for it, and RPGLE programmer with the State Government, smaller hit to the paycheck than the first guy. The rest of the group have nothing but their retirement savings to dip into. We all lost touch over the years but last I heard two or three more for jobs finally but had to eat the cost of moving elsewhere.

        Seriously, the only thing that kept me above water was that I had skills in C++ and Java. And since then I've picked up containers with Linux and node.js plus Python and some big data (Hadoop and shit) just to what I assume is stay current.

        That thinking of yours isn't a good kind in this industry. But I get it, when I worked with the AS400 folk, I had just turned 30 and so I was seen as the young whipper snapper etc. I had just left my last job of several years doing C++ and every gray beard (literally) there thought I was there to "think outside the box" and "shift paradigms" and really I was just there to mostly get a paycheck. Learning RPGLE and COBOL was fun but man those old guys they scoffed at any suggestion to get off a green screen or to make their monolith more modular. They would literally say, "stupid hipster just trying to make everything harder than it needs to be." And let me tell you, I didn't dress like a hipster.

        Anyway, I know, way more memory lane than anyone asked for, but seriously, those guys' thinking ultimately led to their firing. I've worked in a few development teams but not a lot so can't say with a lot of experience, but my gut tells me that had they been just a wee more open to change and newer technologies, they might still be working at that place.

      • by DrXym ( 126579 )
        COBOL is an arcane, baroque and verbose language which serves a very singular purpose in business - processing records. I fail to see how it's "easier to learn" unless all you ever wish to learn in computing is how to process records on mainframe computers.

        If you learn computing because you want to write a game, or a website, or an application, or manage a database. i.e. if you learn for the reasons that 99.99% of people learn for then COBOL is unsuitable. Any general purpose language would be more suitab

  • by Anonymous Coward on Thursday April 27, 2017 @06:05PM (#54315905)

    COBOL isn't hard to learn, and it can be understood/read/debugged a lot easier than many of the more contemporary languages. Banks that want to maintain COBOL systems need to just hire new CS graduates and give them time to come up to speed on the COBOL language.

    Whoever wrote this article unfortunately appears to subscribe to some bizarre employer-centric view that programmers and CS grads are not allowed to learn programming languages on-the-job. COBOL-coded systems are for back-end processing, not for customer-facing systems.

    • Indeed. If there is a market for COBOL programmers (and it's clear there is), then the obvious solution is for unis and colleges to spit out more COBOL-literate CS graduates. Honestly, if I was ten years younger, I'd probably delve into it myself. It is, after all, just a programming language, and hardly on the same level of trying to learn Sanskrit.

      • by Kjella ( 173770 ) on Thursday April 27, 2017 @06:39PM (#54316121) Homepage

        Indeed. If there is a market for COBOL programmers (and it's clear there is), then the obvious solution is for unis and colleges to spit out more COBOL-literate CS graduates. Honestly, if I was ten years younger, I'd probably delve into it myself. It is, after all, just a programming language, and hardly on the same level of trying to learn Sanskrit.

        As long as you have a real fall-back so your career doesn't dead end. What can easily happen is that you do X then more of X because it's the only place you get a salary/career development until you've done X so long nobody will really hire you for anything else. I see this with for example some SAP consultants, essentially SAP customers want to hire you for your SAP experience and the rest of the world doesn't care that you have a general IT degree 5 or 10 years ago because your experience is all SAP-specific and they don't run SAP.

        Now they're probably safe since that ERP is burrowed so deep into many companies they'll never get out, but for something like COBOL you could end up doing it for some years and then the legacy system is shut down and nobody wants to give you anything but a junior non-COBOL position. That is if they'll even hire you or if they'd rather have a recent college graduate. Or you might have to relocate to find one of those increasingly rare positions that actually value your COBOL experience, which of course only makes it harder at the next crossroads.

        If you write cell phone apps as a hobby and can show them a portfolio or something, maybe you'll get away with it. No, you're not a dinosaur who only knows an outdated language and best practices from 50 years ago. Or some other way to be able to transition away from that COBOL career more smoothly. Some of my older colleagues noted that the parking inspector at work used to be COBOL programmer some 20 years ago, they updated their skillset and apparently he didn't.

        • by rickb928 ( 945187 ) on Thursday April 27, 2017 @08:01PM (#54316547) Homepage Journal

          COBOL was ubiquitous in the financial industry before SAP's predecessor was someone's dream. COBOL will take 10 years to get rid of *if* all users begin concerted efforts to do so, these transaction processing systems are too important to just 'replace' without careful planning, development, and most importantly defend against feature creep and being engineered into failure.

          SAP is a baby. COBOL is grand dad. And grand dad still gets out of bed, does his work, and does it well. There is indeed a market for fresh COBOL programmers, and a decade before they need to move on to a new platform.

          In a world where we are cautioned that we will have multiple careers as the job markets change and adapt, it's ludicrous to pretend that programmers can't move on to new languages, new platforms, new challenges. What is being said is "it's cheaper to hire new grads than to hire retrained experienced workers". That is sharp practice. Not nice, but profitable. And not new.

        • by Z00L00K ( 682162 ) on Friday April 28, 2017 @03:45AM (#54317987) Homepage

          SAP is more likely to go the way of the dinosaurs than Cobol.

          Which reminds me of this joke:

          In 1998, a programmer who had been working on Y2K fixes started to get anxious because he couldn't believe how pervasive the problem was. He switched from company to company trying to get away from it, but everywhere he went he became regarded as the Y2K expert and immediately became the team lead for that company's Y2K contingencies. He finally had a nervous breakdown, quit his job, and decided he wanted to be knocked unconscious when the Y2K actually came about.

          A month before Y2K he was put into an artificial coma and cooled down to a near cryogenic easily sustained long term life support.

          Unfortunately the life support notification system had a Y2K bug, and no one revived him for 8000 years.

          Finally he was found and revived. He woke up, and saw himself surrounded by lots of glass, light, stainless steel, and tall beautiful people in white robes. He asked if he was in Heaven.

          They replied, "No, this is Chicago. Actually but it's a lot like Heaven to someone like you."

          "Someone like me?"

          "You are from the 20th century. Many of the problems that existed in your lifetime have been solved for thousands of years. There is no hunger and no disease. There is no scarcity, or strife between races and creeds."

          "What year is it now?"

          "Yeah, about that - it's the year 9,998. You see, the year 10,000 is coming up, and we understand you know something called COBOL?"

        • by goose-incarnated ( 1145029 ) on Friday April 28, 2017 @04:11AM (#54318045) Journal

          but for something like COBOL you could end up doing it for some years and then the legacy system is shut down and nobody wants to give you anything but a junior non-COBOL position.

          You think that a systems migration won't need your legacy skills? You think that you won't pick up the skills for the new system during the migration?

          Here's a more likely scenario: you do COBOL for 5 years and learn the entire problem domain that the COBOL system services. When the migration occurs with Java your knowledge will be indispensable, and you'll no doubt learn Java in the two years the migration takes to complete. At the end of the migration, you are still the expert in the problem and have new Java skills to apply your expertise.

          It's exceptionally unlikely that the migration from COBOL will be so fast that you won't be able to learn the new implementation technology.

      • by Strider- ( 39683 ) on Thursday April 27, 2017 @07:01PM (#54316243)

        Indeed. If there is a market for COBOL programmers (and it's clear there is), then the obvious solution is for unis and colleges to spit out more COBOL-literate CS graduates.

        Oh, hell no. Universities and computer science departments are not trade schools, and we shouldn't be expecting them to teach any specific technology or language. That is not what the discipline is about. What they should be doing is producing graduates that grok and push the concepts that underlie computing in general. They should have a good grasp of algorithms, object oriented design, logic, and so forth. The language is incidental. A well educated grad should be able to pretty much pick up any language, and view it as simply another syntax, potentially with slightly different grammar. In practical terms, a good CS program is far closer to being an applied discrete mathematics degree, rather than a programming degree.

        • by Anonymous Coward on Thursday April 27, 2017 @07:23PM (#54316355)

          I went to community college and we had an Associate's track in, basically, mainframe computing. AS/400, JCL, COBOL because we had several local firms that still maintained and ran mainframes (and last I checked, still do. I believe one tried to move to commodity hardware and rewriting the whole stack in Java, but I don't know if they finished that transition).

          The problem with "just picking up COBOL" isn't necessarily the language, it's the whole system it's deployed on. There's no CLI that a Linux user would readily recognize (I found it easier to think of it like a BBS), the whole Jobs system is utterly alien to someone used to VAX/UNIX, etc etc. My local college also did a lot of that, but in the MIS department. The EE department started everyone out on VAX/VMS and Pascal, the CS department on C and qedit. :D They moved to Visual Studio not long after, though.

        • by Anonymous Coward on Thursday April 27, 2017 @08:49PM (#54316745)

          Even if students coming out of a course should grok code in general, that doesn't mean they have discipline-specific skills in COBOL necessary to allow them to deal with this kind of code. Some of that stuff is learned over decades.

          It's entirely the bank's fault for not taking on young employees and teaching them these new skills, and putting them with the veteran programmers and guaranteeing their jobs for life, with good pay and conditions. They have no one else to blame.

          Had they done this, it wouldn't be a problem. COBOL would just be the language that banks use - nothing else. Banks seem to feel it's the universities responsibility to churn out skills that they might want some day, but without paying either the universities or the graduates ( through employment ) for their services.

          They still have time for this - all they need to do is pay enormous amounts to programmers willing to sit with and replace aging veterans. Good luck to them. I hope the banks choke on this.

          When I studied, we were forced to learn COBOL for precisely this reason. No one was ever hired, or taken on, or otherwise employed out of it - It was just one of those "Industry want this, so we're teaching this" situations, but the truth is that industry only ever want experienced programmers, but they want them to gain that experience somewhere else.

          When we see COBOL programmers paid 1 million per year, like high-flying executives, we'll know they finally realized their value. In the mean time, maybe a few more executives should be prosecuted when they have losses due to COBOL bugs and failures, for running systems they refused to maintain, with foreseeable outcomes.

        • by Slicker ( 102588 )

          An academic degree is about the concepts and pushing the envelope--not specific job training like a vocational school. However, you do need to learn specific programming languages in order to not be detached from reality when dealing with them in theory. Theory gave us OO languages that are many multitudes more complex and harder to maintain than COBOL for the same data processing tasks. That's huge problem for which some background in COBOL might alleviate.

        • Oh, hell no. Universities and computer science departments are not trade schools, and we shouldn't be expecting them to teach any specific technology or language.

          They should, OTOH, at least make some sort of attempt to teach some vaguely relevant language rather than going out of their way to teach to must useless academic wank they can come up with. The local Uni has taught, over the years, Apple Pascal, Eiffel, Prolog, Haskell, and other similar ones. It's like going through a catalogue of "languages you'll never be able to use in real life and that you'll never be able to get a job with" and drilling them into students. It's no wonder that a local software com

          • by harperska ( 1376103 ) on Friday April 28, 2017 @01:02AM (#54317649)

            At my college the low level CS classes were taught using Scheme. The idea was to use a language that nobody would ever in their right mind use in the "real world" to teach basic concepts like recursion without the student getting bogged down by implementation details specific to a language. Higher level classes were taught in Java so that we would have experience with a 'real' language. Also, there are some concepts that are nicer to work with in a powerful modern language, rather than shoehorning them in to an obsolete language not designed to support them.

      • by arglebargle_xiv ( 2212710 ) on Thursday April 27, 2017 @10:36PM (#54317201)

        Exactly, if there's a demand for it, it'll be fulfilled. The article reads like something written by some recent CS grad, lets throw out this horribly uncool, unhip code that nevertheless can handle three trillion dollars of transactions a day and has been going for forty years and replace it with something that some Indian subcontractors slapped together using Ruby and MongoDB.

        In a past life I worked for a bank. They decided to replace their existing Cobol on IBM big iron with Java on... something that wasn't big iron. After several years work and tens of millions of dollars spent and even more than that lost due to problems with the new, modern replacement systems, they threw in the towel and made their modern system screen-scraped 3270s because that shit just works, and keeps on working. It's now all Windows-based at the front end, but everything in the backend is still Cobol on mainframes.

    • by mark-t ( 151149 )

      COBOL isn't hard to learn...

      That much is true, but it is tedious as fuck to use as a programming language.

      • Re: (Score:2, Insightful)

        All programming languages are tedious as fuck to use. In fact, work itself is tedious as fuck when the alternative is beer, sex and video games. Yet people still go to work because they get paid money for it.
        • by mark-t ( 151149 )

          All programming languages are tedious as fuck to use.

          Only when you try to apply them to problems that are too far removed from their own domain of interest. In my experience, COBOL development is tedious even in the very domain for which it is intended - business oriented programming. You can do everything that you can in COBOL in python, for instance, and the resulting work would be just as readable and far less verbose.

          COBOL programs lack elegance... they are the epitome of the saying "everything loo

          • by bored ( 40072 )

            But your python app wouldn't be doing millions of transactions a second on a system about as powerful as a mid range server... Nor would it run for the next 40 years given python's tendency to break the language every so often.

        • All programming languages are tedious as fuck to use.

          Cobol is more tedious than more fuck.

    • by Altrag ( 195300 ) on Thursday April 27, 2017 @07:26PM (#54316367)

      I agree the article's claim is dumb, but not for the reason you suggest. Finding programmers is easy (at least if you're willing to pay a reasonable wage,) and teaching them COBOL is easy as well (any decent programmer should be able to pick up a new language within a week or two.. especially if they're hitting the ground running and have no choice but to learn it.)

      The problem is the business logic. Banking isn't particularly simple at the best of times, and all of those ancient systems will have decades worth of hacks built on top of the base logic for whatever corner cases, hardware workarounds and other tweaks that have been needed over the years. A new programmer learning COBOL will have to be wary of those kind of hacks until they understand them. A programmer trying to port the system to another language/system on the other hand will have to understand those hacks all (nearly) at once in order to make sure they properly get replicated.

      I don't really see any reason beyond simply "new is better!" to do this. By the time they manage to fully port and test the new system, they'll be wanting to rewrite it again in the next fad-language-of-the-day. I mean name one "top" language today that's been around for more than about 5 years and doesn't already have people crowing about how its past its expiry date and everyone should be rewriting all their code in some other language. There's the occasional specific domain where that happens (C++ for performance-centric applications like games, Fortran for sciency things, Matlab for mathy things and the such) but anything even close to general purpose? Few if any.

      • Honest question-- are the back-end systems functioning in a scalable way for today, rather than just functioning for all other middleware to work around the limitations?

        The first question is if the system meets the needs as it exists, and what changes are ultimately needed.

        I can see many things with banking today that don't work well in batch mode, but I have no idea how the banks work around that fact. I'm sure there are other examples as well.
        • by Altrag ( 195300 )

          I don't know specifics about what they do, and I'm guessing that would differ from one organization to the next anyway depending on their specific criteria and how clever their designers and programmers are.

          But in terms of the COBOL language specifically, keep in mind that its still maintained. The last COBOL spec was released in 2014. That is, new features and paradigms can likely be built on top of existing software by just porting forward to a new compiler rather than switching languages all together.

    • by vtcodger ( 957785 ) on Thursday April 27, 2017 @07:32PM (#54316405)

      Once, many, many years ago, I had to look at some COBOL software to see how it was handling some data. Remarkably easy to read and I'd never seen the language before or since.

      I don't think I'd have the patience to program in COBOL

      But I have to say that if I were an IT manager responsible for hundreds of thousands of lines of that stuff that worked, I'd probably be REALLY reticent to scrap it in favor of something more "modern".

    • With all the newer (re: younger) programming kids out there that are quick to jump on the fad programming language of the day, why can't they learn COBOL? Is it just because it's old, so it's not hip like all the other languages that come into fashion and fade out to oblivion faster than anyone can actually become proficient in them?

      Or is it being driven from the employer, where they need someone experienced in an older language that isn't as popular, but are unwilling to PAY for the experienced person
  • No. (Score:5, Insightful)

    by xxxJonBoyxxx ( 565205 ) on Thursday April 27, 2017 @06:06PM (#54315911)
    >> Doderlein suggests making light-weight add-ons in more current programming languages that only rely on COBOL for the core feature of the old systems.

    Er...that's pretty much been the story since the 1990's (if not earlier) on.

    >> mostly maintained by retired programming veterans

    Er...if they're "maintaining" then they aren't "retired". This whole article sounds companies that whine about not being able to find skilled welders, etc. Well, open your wallet and the talent will materialize - see "IT security" for an example.
    • If the average age of your engineers doing the maintaining is 64, then you might as well recognize that you have a problem with retiring programmers.

    • So... Betteridge strikes again. []
  • by msauve ( 701917 ) on Thursday April 27, 2017 @06:08PM (#54315917)
    Anyone worried about getting outsourced, here's a opportunity - learn COBOL.
  • by psergiu ( 67614 ) on Thursday April 27, 2017 @06:10PM (#54315929)

    How about a 4th option ?

    Fscking pay to train people. If COBOL knowledge means means a good paycheck and job stability - lots of people will want to do that.

    I mean hydroponics and grow lights are all the rage now but i hear of no plans of migrating all the existing old-style dirt-based and sun-lighted vegetable gardens to that. Why ? Because people are still learning how to dig the dirt out in the sun.

  • BUGS (Score:4, Informative)

    by AK Marc ( 707885 ) on Thursday April 27, 2017 @06:11PM (#54315935)
    COBOL is simple. It is also relatively limited. This makes it easier to track, troubleshoot, and maintain. With Banks, accountability is more important than functionality.
    • Re:BUGS (Score:5, Interesting)

      by Anonymous Coward on Thursday April 27, 2017 @06:43PM (#54316141)

      COBOL is simple. It is also relatively limited. This makes it easier to track, troubleshoot, and maintain. With Banks, accountability is more important than functionality.

      Said the person with very little knowledge of modern COBOL environments !

      I'll grant that COBOL is not like PL/I, where 80% of the programmers know = 20% of the language.

      However, COBOL has one of the richest I/O layers (ok, on par with PL/I) around.

      Caveat Emptor - I intensely dislike the language (to damned verbose), but it and PL/I do pay fund my paycheck (just call me 'Dinosour Bob').
      But the COBOL I learned was circa 1970s, when even COMPUTE was frowned upon (in school) ... And Databases where not yet relational !

      Modern COBOL has OO patterns, JNI integration, XML/JSON tooling, ... All to deal with the option of:
          * Keep the business logic in COBOL
          * Provide the ability to work with newer toolchains (Java, XML, JSON, ...)
      So there is interoperability betwixt the green-screen and non-green-screen luser.

    • COBOL is simple. It is also relatively limited. This makes it easier to track, troubleshoot, and maintain.

      That is the theory. The fact is, because even trivial things are awkward to do in Cobol, every Cobol program that lives more than a year promptly turns into a gigantic mind sucking unmaintainable pile of toxic sludge.

  • a way to translate the old COBOL programs into a language-neutral specification that captures all of the business logic and edge cases that the old code handled

    Then, a way to translate that specification into an appropriate modern language

    Sounds like an interesting and lucrative research proposal

  • by El Cubano ( 631386 ) on Thursday April 27, 2017 @06:13PM (#54315945)

    Having spent quite a bit of time over the last two years to re-implement in Java a system developed by the government in COBOL, I can tell you that COBOL will probably never die. For example, keeping precise, penny-perfect calculations of dollar amounts in Java is actually quite a pain. This is especially true when the calculations involve dozens of hundreds of steps. My solution in Java has been based around BigDecimal, which makes the code very difficult to read. Aside from that, I have spent the vast majority of the time writing very extensive tests and chasing down really small numeric discrepancies. Guess what, if you decide to replace a COBOL system that does any appreciable amount of math, you would get to do the same thing. Plus, you will never be sure that you found all the bugs.

    The project actually considered the possibility of licensing a commercial Cobol runtime for PC-based platforms (e.g., Windows, Linux, etc.), but that was not feasible for several reasons.

    COBOL is still remarkably good at quite a few things and leaves out lots of the bells and whistles that tend to become distractions in the hands of undisciplined programmers. My only complaint about COBOL (especially old COBOL) is that the control flow is a real pain. Aside from that, it is definitely a workhorse of a language. No need to go killing it off yet.

  • by dwywit ( 1109409 ) on Thursday April 27, 2017 @06:16PM (#54315963)

    Sounds like it might be worth training some new programmers.

    You can re-write any or all of your legacy systems in modern languages (if you choose to undertake the cost and risk, of course), but one day they won't be modern any more, and there will be new modern languages, all with their advocates shouting about pieces of the sky falling.

    Or you can leave these highly reliable core systems in place and suck up the cost of training new maintainers, and deal with the cost and problems of interfacing them with a "customer-centric" model. Of course, you may have to offer incentives to induce young programmers to use something that's not hip and modern, i.e. $$$

    So customers can already do a lot of the work that used to employ bank tellers, billing/accounts staff, and travel agents. None of which changes the fact that "customer-centric" does not and never will have direct access to the core systems. Who cares if the back-end runs COBOL-sourced object code on a mainframe? Methinks people who advocate for C## and Java in core systems have no concept of core systems and their workflows.

  • by srstites ( 3421517 ) on Thursday April 27, 2017 @06:16PM (#54315965)
    The article does not mention what I consider to be the most obvious solution to the problem of old COBOL programmers dying off. Businesses with a COBOL maintenance problem should train young people how to program in COBOL. The businesses will need such people even if they plan to convert their code base to a different language as such a conversion would take years to implement.. --------- Steve Stites
  • I'm a graduating college student with no experience in Cobol, although I am familiar with half a dozen other languages. Honestly, if some bank were to email me right now with a job to maintain and upgrade their 50-year-old cobol code I'd be up for the challenge.
    • That's an awesome way to get your foot in the door, but you'll cringe when you first have to debug a piece of 50-year old code that is poorly documented and written by someone long since retired or dead. :-)

      This isn't a swipe at COBOL though; this could be true of any language.

  • by crow ( 16139 )

    It's been a while since I've touched COBOL, but it should be possible to develop a program that parses COBOL and outputs the equivalent in a modern language, even preserving the comments.

    Since financial institutions seem to be completely unaware that programmers can quickly adapt to different languages, it would seem like an automatic conversion program could be quite profitable.

  • There's a COBOL shop in my small town that contracts for corporations and the government. I know several COBOL specialists in their 30s. It's actually an extremely lucrative field to get into these days, with good pay and job security.

    Rewriting all that COBOL code in some other language would be bound to cause major problems.

  • They already are moving away from COBOL. That's the trouble. They can't get young guys to work on the old systems because it's basically a waste of 3-5 years of your career. COBOL et al are being killed as fast as they can. After that being a COBOL program is worthless.
  • by quarrel ( 194077 ) on Thursday April 27, 2017 @06:24PM (#54316023)

    Grace Hopper did not invent COBOL. Follow your own links - there is a whole list of who designed it, and none of them are Grace Hopper. She did lay lots of the foundations they worked upon of course.

    To the question of should they replace it? About the same time as any other language should be replaced - it is a very silly question...

    • by Tablizer ( 95088 )

      Grace Hopper did not invent COBOL

      COBOL was ultimately designed by a committee, but Grace's early compilers had a lot of influence on the language design.

      The military and other organizations found it difficult to build financial, logistics, and administrative software for multiple machines that each speak a different language, and thus formed a joint committee to create a common language. (Science and research institutions had FORTRAN for cross compatibility.)

      Basically the COBOL committee grew sour with disa

  • If it ain't broke, don't fix it.

  • by isj ( 453011 ) on Thursday April 27, 2017 @06:29PM (#54316053) Homepage

    2 years ago in one of the banking centers in Denmark 12 new IT-candidate were educated in ... COBOL, CICS, mainframes, etc. The older generation were anxious about how the younglings adapt, but it appears it turned out well. They were excited about the robustness and scalability of the mainframes, not so much about COBOL, but could see it didn't make business sense to rewrite old software. New software is being developed in more modern programming languages.

    source (Danish only): []

    • Why is that a surprise? If people could master COBOL 50 years ago, why would they not be able to master it today?

  • Banks tend to be rather conservative. If it's working now, I would think they wouldn't be too keen to replace it with anything.

    This reminds me of something I heard years ago, which I wouldn't at all be surprised is still true: that there are systems at 'the phone company' (I assume they meant AT&T?) that have been sitting there for decades, running the whole time, that nobody even knows what it actually does anymore, but they do know that Bad Things happen if it stops working -- but all they can do whe
  • The issue is that there a no new COBOL programmers, you can not get resources out the University that had learned COBOL. So it is a risk for banks to keep their systems on this programming language. It does not mean that COBOL is good or bad, it is just not a language with enough critical mass to reduce the risk of a bank. The owner of that language is not making any efforts to put COBOL everywhere, it is treated as a legacy platform so money investment and innovation it is not going to be put on COBOL toda
  • by OneHundredAndTen ( 1523865 ) on Thursday April 27, 2017 @06:58PM (#54316231)
    Pay them well, and they will come. Isn't that the way it is supposed to work?
  • by grep -v '.*' * ( 780312 ) on Thursday April 27, 2017 @07:01PM (#54316245)
    Why yes, of course -- OBVIOUSLY.

    Let's all jump on the current language of the week. It's of course preoptimized for Big Iron CPUs and IBM DB2 or Oracle databases. We'll write everything over again from scratch using the original business documentation (because who can read COBOL? -- that's the problem!) and this time Do It Exactly Right.

    Those losers from decades ago just didn't know what they were doing at all. Stupideos.

    And then: the month-after-next comes along.
  • COBOL is unbelievably ingrained into the fiber of banking, and the developers surrounding it are seriously seasoned veterans in the realm of batch code, deployment and support.

    Not only did I go to a university in the early 2000's that actually taught COBOL, JCL, VSAM generation and use, emulation mainframe 'green screen' interfaces (the actual language we used escapes me now 16 years later - ACS? ASC?), AS/400 exposure, even fucking assembler (and not for computer science C/C++ brats dumping out compiler in

  • COBOL programs are really just giant program comments that have delusions of actually running.
  • ... let COBOL retire. Come up with a strategy to replace COBOL, execute the strategy, then allow COBOL to retire.
  • Lets rewrite billions of lines of code and systems worldwide because we can not afford to hire COBOL devs (or make it attractive to other devs).
    Oh, wait...

  • Just pay COBOL programmers big enough salaries to attract younger talent Pay them, and they will come
  • I have every intention of spending the twilight years of my career working on ancient systems for a huge premium, so I say keep it around for the rest of us.

  • as others have said here, its not at all hard to learn the language and many of us have. With the unemployment problems we have with american tech workers and the unemployment problem we have in the country (unlike the official statistics, the real number is more like 10-15% because people who have given up are not counted), its hard to argue that you cannot develop and train workers to work on this technology.

    About 90% of learning the job is learning the *application specific* layout of the program, learni

  • Is this an ad for Citibank looking for an experienced COBOL programmer to fix the issue in the previous story about the woman who was 110 year old and the bank software couldn't handle an age that high?

    They need to fix it, but they can't find any COBOL programmers! Doh!
  • by rickb928 ( 945187 ) on Thursday April 27, 2017 @08:17PM (#54316611) Homepage Journal

    And he's a tedious pain in the A$$. Self-righteous, gloating over the shortcomings of the current crop of apps, reveling in the agony of the kids struggling to release even the most minimal upgrade without 3 fast followers and a deferred feature request until they get enough points banked to figure out something new. He loves their failures.

    And our COBOL systems do hum along.

    We spent $2 Billion over 7 years on a new core processing platform, written in something 'modern'. It was hell. And it is one of 7 core processes. We are now working on using 'Big Data' to replace another core platform, and I swear they feed it quarters to keep it running - yes, we abandoned Hadoop, but Cassandra isn't much better for my app, we never get the resources we need, and as they convert even these relatively simple apps, we go through a cycle of redesign/minimal deployment/discover massive problems/rewrite/deploy minimal features/add in necessary features/discover problems with all supporting systems/implement error handling and alerts/re-budget to accommodate the real cost/start a new feature cycle... Fortunately we measure most of these events in single-digit months instead of single-digit years. Good bye Websphere, we hardly loved ya.

    COBOL need not be replaced for core, transaction-bases systems, but the pressure is enormous. For financial institutions, being able to count on reconciling cash flows reliably cannot be overvalued. Some stuff just has to work. It doesn't have to be 'modern', whatever the hell that means, it just has to work.

  • Is it possible to do CSS in COBOL?

    I think someone might have tried.

  • Just pay enough. (Score:5, Interesting)

    by dpbsmith ( 263124 ) on Thursday April 27, 2017 @10:16PM (#54317141) Homepage

    I remember this coming came up during the Y2K flap. COBOL programmers are dying out because companies have decided, for whatever reason, that they aren't willing to pay them much. A quick Google search--I don't know how reliable--shows me:
    COBOL Sr. Software Engineer / Developer / Programmer $88,049
    Java Sr. Software Engineer / Developer / Programmer $103,239
    But that understates the difference because the various job titles shown for COBOL positions are predominantly lower-sounding and lower-paid positions.
    As several have said, COBOL isn't hard to learn--I don't know it but I crammed it once for a test. Like all languages it takes a while to get good at it, but it's not specially difficult, nor is it specially bad.

    The best strategy would be to render unto COBOL what is COBOL's--keep good legacy systems in COBOL--and pay enough to give people a reason to learn the language.

  • by PPH ( 736903 )

    Betteridge's law notwithstanding, the next question will be what to replace it with. And the attempts to answer that will devolve into a clusterfsck of trendy languages du jour. And by the time some poor bank has funded the effort to port to something, that something's advocates will have moved on and the replacements will claim that the choice was all wrong and divert the effort to their new favorite.

  • by ledow ( 319597 ) on Friday April 28, 2017 @04:34AM (#54318113) Homepage

    Why does the language matter?

    I have to learn all kinds of new, esoteric and niche languages all the time as part of my job.

    Surely what you want is to hire a business or banking programmer and make sure they are then made competent in COBOL (gosh, maybe you could utilise your ageing COBOL workforce to teach him?), no different to bringing in a guy trained on a competitor's system and training him on YOUR system.

    It worries me that a bank would be hiring a programmer who *can't* do several languages, especially languages that have been around for decades rather than languages utilising entirely different paradigms, or that can't pick up new ones as they appear.

    If you hire some - I don't know, whatever the language of the moment is, say Java or something - programmer to replace all this system, you'll have a system tied into Java. Which will, as Java is starting to show, start to get replaced itself by the time that guy has gone and you've only got rookies running the place on the old-guy's code.

    Massive expense, to be back to square one, after decades of dodgy code that was trying to stabilise.

    Advertise for programmers, teach them COBOL as the "in-house" language. Then, so long as your business systems have the tools for them to create and execute those programs, you're sorted for a long time yet. You don't even need to care that every other bank in the world has moved to Java or whatever if you do it right and have standardised interfaces or conversion tools.

    I think this is not related to "we can't find people who could program in COBOL" as much as "we already have a bunch of cheap outsourced programmers who only know Java and they can't learn anything else".

    The time taken to familiarise yourself with such a critical codebase to the point of confidence in pushing your production code should VASTLY outweigh the time required to actually learn something like COBOL from scratch, in this kind of industry.

Order and simplification are the first steps toward mastery of a subject -- the actual enemy is the unknown. -- Thomas Mann