Stories
Slash Boxes
Comments

SoylentNews is people

posted by on Saturday April 29 2017, @09:17AM   Printer-friendly
from the the-code-that-wouldn't-die dept.

Submitted via IRC for TheMightyBuzzard

We reached out to Daniel Döderlein, CEO of Auka, who has experience with working with banks on technological solutions such as mobile payments. According to him, 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 Döderlein 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.

And here I thought everyone knew banking software should be written in PHP, javascript, or a combination of the two.

Source: https://thenextweb.com/finance/2017/04/25/banks-should-let-ancient-programming-language-cobol-die/


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Insightful) by maxwell demon on Saturday April 29 2017, @10:16AM (8 children)

    by maxwell demon (1608) on Saturday April 29 2017, @10:16AM (#501501) Journal

    Another solution, not mentioned in the article: Pay the COBOL programmers enough that people are willing to learn and use it to get a job at the bank.

    --
    The Tao of math: The numbers you can count are not the real numbers.
    Starting Score:    1  point
    Moderation   +4  
       Insightful=3, Informative=1, Total=4
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 2) by Lagg on Saturday April 29 2017, @11:03AM (3 children)

    by Lagg (105) on Saturday April 29 2017, @11:03AM (#501510) Homepage Journal

    I couldn't decide if I should reply to this or the other post because they made the same reasonable point and have the same score D:

    In any case, yes. This. I write in whatever tools people need me to write in for the problem that needs solved. Learning is simply a matter of giving me sufficient hours to study. Be it COBOL or hell even Malbolge (no not rly, but if I learned 4 lisp dialects I can do a refresher on cobol). I've never seen a job post from a bank along these lines. Maybe that says something. However, if I were to be hired by them I would strongly push for the option of refactoring the cobol into more modular systems that speak to the core cobol via thin IPC. Not because of inexperience but because it's a practical option when you're dealing with financial data of any sort.

    There are issues with our modern shit, but when you look at something like Go or V8 and what they can do in terms of memory management, heap efficiency, concurrency and security it becomes very hard to justify continuing using COBOL at anything that may even slightly be user-facing. However, I think part of COBOL's advantage here is that it only does what it's meant to and is very fast at doing it. But it's a highly restricted way of programming if you want to utilize those. Hence me agreeing that it's a good idea to keep the core functions running with it.

    P.S. Go has a builtin thin RPC implementation. This gave me a raging hardon. Which surprised no one in the room of 18 people more than me. Because I even hate most of Boost let alone the kitchen sinks they put in this stuff in other languages/libs.

    --
    http://lagg.me [lagg.me] 🗿
    • (Score: 0) by Anonymous Coward on Saturday April 29 2017, @01:10PM (2 children)

      by Anonymous Coward on Saturday April 29 2017, @01:10PM (#501535)

      I thought only Grateful Dead followers were dead heads.

      "I M here to save you" is not working with or understanding what these systems do or how they work. Though in the early 80's when COBOL on big iron was able to address 16MB of storage were poor thought process programmers were already complaining about the limitations. Those same poor programs today create mega apps that do nothing but waste space and security issues because they do not study or understand the past.

      Gates was right 640KB is all you need. Actually 64KB is all you need and 10 can run at the same time. 1990 a small system that wrote process over 4B dollars for businesses around the world and it ran unchanged until 2005 10yrs after the hardware was discontinued.

      The most important thing to understand about these systems and the times they were built in was and is MODULES. No monithic objects like today. But small distric programs that. Ompole and run in less than 64KB or even 16KB. Understand how to write. Ode that processes millions or rows of Dara with out locking my table so you can 10 or 1000 jobs doing the same work over third parts of of the table to compress a run time into monuments instead of moving mutes or hours. Think simple.

      • (Score: 2) by sjames on Saturday April 29 2017, @06:52PM (1 child)

        by sjames (2882) on Saturday April 29 2017, @06:52PM (#501628) Journal

        There is a lot to this. Few business processes call for complex mathematics or manipulation. It is the same operations carried out on a large array of objects. Mainframes don't have super powerful CPUs, they have many fast I/O processors. In the older systems, the software isn't adapted to business practices, business practices are adapted to the needs of data processing. That's why they were able to do so much with machines that are positively anemic by today's standards.

        That's the mindset needed to work on these legacy systems.

        Somewhat newer but still old systems will use transaction processing, but will still present a green screen. No splat looking picture to dispense milk and cookies. Incidentally, also no need to take your hands off of the keyboard every few seconds. In some cases, you can just put one hand on the numeric pad and off you go. Data entry is designed to work with the software, not the other way around.

        • (Score: 2) by kaszz on Sunday April 30 2017, @04:01PM

          by kaszz (4211) on Sunday April 30 2017, @04:01PM (#501886) Journal

          Might explain why bank-2-bank transfers happens in a batch fashion and not in an instant. And why they are totally unable to deliver a transaction log in a encrypted format via email. Which would be great to ensure bills are paid and scams are thwarted.

  • (Score: 0) by Anonymous Coward on Saturday April 29 2017, @12:14PM (3 children)

    by Anonymous Coward on Saturday April 29 2017, @12:14PM (#501524)

    Another solution, not mentioned in the article: Pay the COBOL programmers enough that people are willing to learn and use it to get a job at the bank.

    Problem with this idea, fighting the N+ decades of hostility foisted on COBOL by every computer 'Scientist' I've ever come across, this has seriously poisoned that well.

    (For the record, almost signed up for a COBOL course once back in the late '70s, as there was the potential to make a fair amount of money locally, but saw that which was APL, and was that day deliv'rd..into a somewhat more esoteric and interesting hell of a career..not as well paid, admittedly, but a lot more fun.)

    • (Score: 4, Insightful) by fyngyrz on Saturday April 29 2017, @01:06PM (2 children)

      by fyngyrz (6567) on Saturday April 29 2017, @01:06PM (#501534) Journal

      Good grief. If a programmer is even moderately competent, they won't need a "course" in COBAL. Like almost any other computing language of its vintage, it can be learned on one's own in a very short amount of time. I'm not even sure how many computing languages I know at the "no problem" level at this point, I'd really have to work to list them all, and there are quite a few more at the "give me a day to refresh my memory" level I could get by in just fine. I'm hardly alone in this. Also, in point of fact, COBAL's not a very difficult language. Yes, I'm old enough to have written code in it.

      The problem here – if there even really is one – would be one of finding people with knowledge of the systems and techniques in question. Wading into a large corpus of code blind is no picnic, no matter what the language is. But again, there are many, many people who could do it, given enough time to look at the existing system.

      Put the job out on offer, attach enough money to it, and the people needed will come out of the woodwork.

      OTOH, don't advertise, or offer lowball salaries... or both... yep, that would cause a problem.

      <sarcasm>And we all know the banks just have no money to spare to properly maintain their systems.</sarcasm>

      • (Score: 5, Informative) by tibman on Saturday April 29 2017, @04:49PM (1 child)

        by tibman (134) Subscriber Badge on Saturday April 29 2017, @04:49PM (#501579)

        I applied to a government position for writing cobal. Didn't even come close. #1 reason, no college (and they ignore all non-cobal experience). #2 reason, i wasn't old. It's a good ol' boys club in there. That's why there aren't enough cobal programmers. They want it that way.

        --
        SN won't survive on lurkers alone. Write comments.
        • (Score: 2) by fyngyrz on Sunday April 30 2017, @04:08PM

          by fyngyrz (6567) on Sunday April 30 2017, @04:08PM (#501891) Journal

          Yep. Well, if they want to shoot themselves in the foot, by all means, we should learn to enjoy watching their feet bleed. I'm 100% there, myself.