SoylentNews is people
SoylentNews
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/
(Score: 2) by Lagg on Saturday April 29 2017, @11:03AM (3 children)
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)
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)
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
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.