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/
Related Stories
The Enterprises Project writes about how the demand for several very specific, established skills, including COBOL, is increasing as boomers retire, taking their knowledge with them. Part of the skill gap between the old and the new is familiarity with the work flow and business processes.
Baby Boomers are retiring and taking with them the skills to run legacy technologies upon which organizations still (amazingly) rely – from AS/400 wrangling to COBOL development. That leaves many CIOs in a tight spot, trying to fill roles that not only require specialized knowledge no longer being taught but that most IT professionals agree also have limited long-term prospects. "Specific skill sets associated with mainframes, DB2 and Oracle, for example, are complex and require years of training, and can be challenging to find in young talent," says Graig Paglieri, president of Randstad Technologies.
Apparently, COBOL is still in use in 9 percent of businesses, mainly in finance and government. And so the demand for COBOL is gradually growing. If one has interest to pick up that plus one or more of the other legacy technologies, on top of something newer and trendier, there should be a possibility to clean up before the last of these jobs moves to India.
Earlier on SN:
Jean Sammet, Co-Designer of a Pioneering Computer Language, Dies at 89 (2017)
Banks Should Let Ancient Programming Language COBOL Die (2017)
Honesty in Employment Ads (2016)
3 Open Source Projects for Modern COBOL Development
(2015)
(Score: 5, Insightful) by maxwell demon on Saturday April 29 2017, @10:16AM (8 children)
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.
(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.
(Score: 0) by Anonymous Coward on Saturday April 29 2017, @12:14PM (3 children)
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)
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)
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
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.
(Score: 5, Insightful) by Aiwendil on Saturday April 29 2017, @10:17AM (4 children)
Another solution would be the groundbreaking notion of actually training people in the skills needed.
Over here (sweden) a bunch of banks and other companies joined together and simply paid a school to have COBOL-courses. (Also had the sideeffects of ither schools starting to offer it).
(Score: 5, Interesting) by jmoschner on Saturday April 29 2017, @11:23AM (2 children)
American businesses are not going to spend money to train people. It would require thinking beyond the Quarterly profits. They also don't want to risk training people who are just going to jump ship for a better offer. This is yet another side effect of the erosion of company loyalty (companies are not loyal to employees who in turn have no loyalty to the companies...a vicious cycle).
(Score: 2) by bzipitidoo on Saturday April 29 2017, @12:47PM (1 child)
Companies will complain that schools aren't giving students the correct education, and they should offer classes on COBOL.
But come on, this is COBOL. It has the reputation of being an easy language, good for those who find BASIC too hard. Good programmers find it tiresomely redundant and verbose. The real difficulty isn't COBOL, it may be knowledge of the ancient computing environments of the 1960s. Maybe they still use punch cards, tapes, and actual IBM mainframes from that era, though I'd guess they emulate all they can. Even if it's all emulated, probably someone still needs to know arcane stuff like Job Control Language.
(Score: 2) by fyngyrz on Sunday April 30 2017, @04:22PM
Again, learning JCL does not require deep intellectual resources from a generally skilled programmer. Been there, done that, meh.
This problem is entirely self-inflicted on the part of the banks, and every entity that thinks college degrees constitute a sane pre-filter for employment on these kind of isolated technical issues, which by definition are extremely vertical and require only someone with those vertical skills. Not to mention requiring documented work experience for gratuitously simple skillsets. "What, you've never been employed as a pencil sharpener? I'm sorry, you don't qualify for our office work." Yes, I am comparing COBAL and JCL to pencil sharpening for any competent programmer.
I recommend getting some marshmallows, sitting back, and enjoying watching them burn consequent to their own stupidity.
(Score: 2) by looorg on Saturday April 29 2017, @01:14PM
Not sure if more, or which, schools have done it so far but I know that KTH (Royal Institute of Technology, Stockholm, Sweden) offered courses where staff came from IBM (and from pulsen.se ) to teach Z\OS, JCL, COBOL and more or less everything mainframe related. Not sure if or how it turned out in the long run, it was a few years ago now. They where offered as evening classes. I took the once on Mainframe, Z\OS and Linux when I lived in Stockholm. They didn't offer COBOL at the time, it was a later edition. It was very interesting. But then I moved away from Stockholm and that is where the bulk of the jobs are unless you want to go to one of other big cities (or down to Bromölla).
(Score: 2, Insightful) by Anonymous Coward on Saturday April 29 2017, @11:02AM (6 children)
How about these trillion dollar buisnesses TRAIN THE REPLACEMENTS.
(Score: 2) by turgid on Saturday April 29 2017, @04:09PM (4 children)
If you can convince the shareholders they'll see a return on their investment in the next four quarters, by all means run it by them.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Sunday April 30 2017, @12:11AM (2 children)
Then on top of that. These are the sort of systems that *MUST* run. I mean if they fuck up entire large multi national companies will go under in 1-2 weeks due to the fact they would not be able to pay anyone or transact business. When they said to big to fail. They meant it.
The technical people are keenly aware of the monster. They *DO* *NOT* *FUCK* with it. Tech debt is a mountain that will never be undone.
Money is not really the problem. These large banks have thousands of competent programmers. The problem is how do you replace the engine of a car that is driving 200 MPH. There is decades of tech debt in there. Some of these banks have been chewing on their tech stacks since the 60s.
(Score: 3, Insightful) by kaszz on Sunday April 30 2017, @04:09PM (1 child)
Build a new engine that traffic is redirected to bit by bit. After extensive testing of course, like sitting in parallel and comparing results for 2 years.
(Score: 2) by Justin Case on Sunday April 30 2017, @08:11PM
The COBOL environments I worked in didn't have "traffic" to "redirect". Those barfwords showed up when the marketdroids figured out the web could be used for advertising*.
However I can imagine someone cobbling together a web front end with an interface to a COBOL back end, which I would expect to be an abomination you couldn't pay me enough to touch.
* Also known as "the end of modern civilization".
(Score: 0) by Anonymous Coward on Sunday April 30 2017, @04:22PM
If your looking 4 quarters ahead, you are far, far too visionary for American business.
(Score: 4, Interesting) by tibman on Saturday April 29 2017, @05:02PM
The difficulty is in explaining to HR and your superiors that you are hiring someone who literally cannot do the job (yet). They cannot comprehend it.
I was recently promoted into a position where i can hire. Last month i hired a green guy who has been teaching himself (and attending a "code school"). Probably won't be very productive for several months. Also hired a lady who had a kid and took a few years off work. She said nobody would give her the time of day. Both have a real passion for programming. I'd rather hire someone who isn't burnt out and needs some training than someone who doesn't give a shit about their work but is technically very experienced. So far the company is cool with us training/teaching greener people. I think they're cool with it because greener people are cheaper, hah.
SN won't survive on lurkers alone. Write comments.
(Score: 1, Funny) by Anonymous Coward on Saturday April 29 2017, @12:06PM (4 children)
"COBOL: The language that will happily compile an office memo, and not report any errors."
I was taught COBOL in college. I got extra marks for creating a ANSI text graphical menu system with it.
Never had any use for the language since.
Happy to say I'm neither retired nor dying yet. Now get off my lawn.
(Score: 2) by c0lo on Saturday April 29 2017, @12:39PM
By the way you are describing it, you neither have the wage of a COBOL programmer is offered.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 4, Funny) by deadstick on Saturday April 29 2017, @01:29PM (1 child)
Once read a post by a guy who had turned down a COBOL programming offer. The interviewer replied, "So you don't like to learn new things?"
(Score: 1) by purple_cobra on Sunday April 30 2017, @07:43PM
Everything old is new again, perhaps?
During the first year of my degree, a classmate asked the lecturer if he'd be teaching us COBOL the following year; he said that all he knew about COBOL was that it was an anagram of bollock, and even that was spelled incorrectly. I don't think he liked it!
(Score: 1) by DeKO on Saturday April 29 2017, @03:52PM
I've got some bad news for you, about the "dying" part...
(Score: 3, Insightful) by kaszz on Saturday April 29 2017, @02:37PM (8 children)
The COBOL language also has some serious problems that make programmers balk. One is called COBOL-FINGERS and the rest is generally not a pretty thing. Lack of structure, compatibility issues, verbose syntax supposed to be easily documented and recognized for business people but will do no good for the professional programmer, designed by an incompetent committee from commerce and government (think MBA-PHB) and disdained by the computer science community as a trade school language.
So they want code grinders for cheap while they themselves make big money from that work. While the former is supposed to mindlessly hammer away on virtual dinosaur mainframes? At the same time there is plenty of more interesting and well paid tasks to accomplish. Considering the mentality and mindset of money commerce and government, that let a incompetent committee decide on design issues. Let them suffer the consequences of their own shortcomings.
Any idea for a better language that will solve the same tasks but also not have the crap that javascript or php harbours?
(Score: 2) by maxwell demon on Saturday April 29 2017, @04:02PM (1 child)
INTERCAL. Yes, it has a bad reputation as well, but that's surely just because most geeks don't like to say PLEASE. ;-)
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by kaszz on Saturday April 29 2017, @04:26PM
It can only be better .. :-)
(Score: 3, Insightful) by Uncle_Al on Saturday April 29 2017, @04:03PM (1 child)
"designed by an incompetent committee from commerce and government"
Including Grace Hopper
The big problem is legacy code isn't "Object Oriented" so kids think it's shit.
(Score: 2) by kaszz on Saturday April 29 2017, @04:29PM
It takes more than a person to have impact in a committee. The problem with COBOL seems to be that all the actors that should not decide on the matter has done just that. The consequence is felt now. System owners of such code should just endure the consequences as karma.
(Score: 2) by hendrikboom on Sunday April 30 2017, @01:46AM (3 children)
Any idea for a better language that will solve the same tasks but also not have the crap that javascript or php harbours?
Try OCaml.
(Score: 2) by kaszz on Sunday April 30 2017, @02:19AM (2 children)
Perl or Python seems on a quick look to be less convoluted.
Does COBOL give the programmer any edge at all? Like some languages that protects against memory trashing by preventing array index references to go to far. Or preventing bad variable interpretation by typing them. Or efficiency by handling pointers instead of data. etc..
(Score: 2) by hendrikboom on Wednesday May 03 2017, @02:46AM
Cobol does a lot of automatic type conversions. It has types like ten-digit decimal number with two digits after the decimal point. Or three digits. Or whatever the programmer specifies. And it does all the necessary conversions. Might it even do them correctly?
(Score: 2) by hendrikboom on Wednesday May 03 2017, @02:52AM
OCaml is preferred by a number of financial institutions. Perhaps because OCaml programs have more of a tendency to run correctly if they run at all than programs in some other commonly used languages. Not that you can't write incorrect programs in it, of course.
But it won't be a drop-in replacement for COBOL.
(Score: 5, Insightful) by bradley13 on Saturday April 29 2017, @02:45PM (2 children)
Cobol may not be an exciting or sexy programming language, but its...a programming language. I've used more than 20 programming lnaguages by now. Coming up to speed on a new one is a matter of weeks - the biggest challenge is learning all the supporting libraries.
Far more important are (a) domain knowledge, specifically of the intricacies of back-end banking systems, and (b) anal-retentive carefulness, because a mistake could literally cost $billions. If Cobol offends your super-cowboy programmers, that's all to the good, because they fail point (b) anyway, and would surely screw something up.
Frankly, I expect the real problem is the domain knowledge. Anyone here work in the field, and able to say more?
Everyone is somebody else's weirdo.
(Score: 2) by kaszz on Saturday April 29 2017, @04:31PM
Is the salary anywhere near $billions ? ;-)
(Score: 2) by Justin Case on Sunday April 30 2017, @08:30PM
anal-retentive carefulness
This, absolutely this, is the lost art, not the ability to learn a fairly simple programming language.
Prior to changing a single line of code, can you tie the change to a written, approved requirement that has positive and negative test cases?
Can you automatically repeat all the tests that were performed against the previous generation of the code to show that the change did not introduce any new outcomes other than the new outcome that was specified in the requirement?
Drag-and-drop GUI jockeys who call themselves "developers" are deeply offended when you don't let them experiment on the production server. They'd be shot before getting close enough to the keyboard to start entering COBOL code.
(Score: 4, Interesting) by turgid on Saturday April 29 2017, @03:25PM (7 children)
Has anyone tried writing a compiler/translator that translates COBOL source into source for another high-level language?
The original C++ compiler was a pre-processor for C. Many years ago, Linux (Slackware) used to come with f2c and p2c which were for translating FORTRAN and Pascal source respectively to C.
One of my colleagues who likes closed-source software loves a thing called Enterprise Architect which he says can reverse engineer programs written in several high-level languages, translate them to others, make UML diarams etc. Allegedly you can configure it to understand most languages if you are so inclined.
In these days of Test Driven Development, test automation etc, it should be becoming feasible to reverse-engineer and reimplement these legacy systems with some sort of accuracy.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by turgid on Saturday April 29 2017, @03:29PM (1 child)
Seek and ye shall find: RES - An Open Cobol to Java Translator (alpha) [sourceforge.net].
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 1, Funny) by Anonymous Coward on Saturday April 29 2017, @10:11PM
Good thing Java has a goto statement. Plenty of that can exist in COBOL code.
(Score: 2, Interesting) by DeKO on Saturday April 29 2017, @04:16PM
Cfront was actually a proper compiler. Its predecessor (for the "C with classes" dialect) was actually a dumb preprocessor, according to Stroustrup: [stroustrup.com].
The GnuCOBOL compiler [wikipedia.org] does exactly that, it compiles to C. Of course, those kinds of outputs can't really be consumed by a human, they're only good for another tool to handle it further (you can try though, it'll be as useful as asking GCC to keep the assembly output after compilation). You definitely don't want a code base translated to another language by a machine, because maintenance will be much more costly, as any resemblance of structure and readability gets thrown away.
(Score: 5, Insightful) by jmorris on Saturday April 29 2017, @07:23PM (3 children)
reimplement these legacy systems with some sort of accuracy.
That is why you wouldn't be considered. And why your plan is a fail before it starts. When you are processing trillions yet keeping only fractions of pennies on most transactions you do not want to hear about "some sort of accuracy" at all. You do not want to translate into a 'modern' language either. Show me ONE real world program written in the 'modern' languages which is not a bloat hog of security exploits waiting to be found? Combine exploitable code that communicates as a primary function and Sagan's of cash and it would be a virtual batsignal for the underworld. Pretty much the only known way to get modern code that is provably safe is to get DJB to write it, but DJB doesn't scale well.
The other unspoken problem replacing the aging cobol coders is the hard one. The original bunch slowly built these systems and the banks had little choice as there were no old stable coders. There was only a few problems, at least that became known. But now they do not want some young hipster rock star programmer coming in and becoming disgruntled, implanting a nasty and retiring to Aruba with a few million skimmed out of the system. The background checks to get into that elite club of programmers trusted to touch systems and code processing trillions have to be far worse than the President's Secret Service detail.
(Score: 2) by turgid on Saturday April 29 2017, @07:28PM (2 children)
Hmmm.. sounds like religious reverence for mysterious old code... the Wisdom of the Ancients. Things have moved on in the last 50 years. And when I say "modern languages" I don't mean C++, Javascript and PHP.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Insightful) by kaszz on Sunday April 30 2017, @02:24AM (1 child)
Modern, well sometimes time gives us more backwards languages. Not progress.. ;-)
Languages should be put to a test where they have to be self hosted on a really small system. That way messy programmers won't pass.
8-bit 16 kB RAM ? ;)
(Score: 2) by turgid on Sunday April 30 2017, @08:49AM
FORTH
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by CoolHand on Monday May 01 2017, @01:44PM (1 child)
Anyone who is capable of getting themselves made President should on no account be allowed to do the job-Douglas Adams
(Score: 2) by Justin Case on Monday May 01 2017, @06:41PM
I've been using PeopleSoft for years and it has always had an incredibly clunky feel to it. I've suspected it was a COBOL back-end screen scraper written by people who had no exposure to the most basic fundamentals of the web. You know, like URLs and the back button?
Oh yeah and the lead of our PeopleSoft development team told me PeopleSoft (including their in house developed mods) would never have any security flaws because flaws were "inherently impossible in the design". After that I had to bust it wide open just to show the idiocy of that blithe assertion.