Slashdot Mirror
Should Banks Let Ancient Programming Language COBOL Die? (thenextweb.com)
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.
Java is getting long in the tooth. Time for it to become the new COBOL.
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.
>> 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.
Anyone worried about getting outsourced, here's a opportunity - learn COBOL.
"National Security is the chief cause of national insecurity." - Celine's First Law
Why don't new programmers just learn COBAL? Once you learned one programing language you pretty much learned them all. The difference is just syntax which is easy to learn.
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.
1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
Too big to fail?
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.
Learn to love Alaska
..is 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
The lie being that money isn't being lost/stolen with existing code.
Inheritance is the sincerest form of nepotism.
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.
While many (most?) of us know who Grace Hopper is, why wouldn't we include her full name? I realize this is Slashdot but do we really have to act like a bunch of elitists who don't care about someone who doesn't know everything we think they should know, or should we instead strive to educate the younger generations and the less informed? Or is this just a case of lazy editing?
Captcha: Scorning
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.
They sentenced me to twenty years of boredom
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.
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.
Any currently competent coder could learn COBOL in a week. Except for learning about BCD and some unusual quirks like the fact that a structure move copies like named fields into like named fields allowing layouts to be rearranged easily. And COBOL always had an interface to other lamguages, FORTRAN if mathematical libraries were needed or assembler if you wanted to implement inter-process locking of common data and such.
What would be harder is to get their heads around the COBOL environment which was originally based on punched cards to COBOL program to magnetic tape to COBOL program to and so on; and a stand-offish approach to terminals and GUI developed when the cost of a vector graphics terminal could buy you a small house and a real nice car.
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.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
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...
If it ain't broke, don't fix it.
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): https://www.version2.dk/artike...
Only LUDDITES use LUDDITE COBOL! Modern app appers use AppScript and AppApp to app apps!
Apps!
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 when it does stop working, is power-cycle it, cross their fingers, and hope it starts working again. Is this what's going on with the banking industry and their COBOL mainframe systems? Never mind the world being put back into the Stone Age by another subprime lending disaster, how about some ancient mainframe system running COBOL blowing up and taking the worlds' finances with it?
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 today. It is not about how good the language it is compared to other, it is about the market.
And by the way, to everybody that loves COBOL, please upload everything you can on Archive.org to preserve the language.
COBOL is not hard to learn. What is hard to learn is the incredibly diverse (read asinine) state of the systems that employ it. The All Star coders that put together these systems are not just retired, they're dead. The people maintaining them are not experts (and this is found out by asking them simple questions about compilation)
It also neglects to mention what a lot of people fail to mention about learning Java. Java SE is NOT difficult to learn. What is difficult to learn is the myrid array of frameworks that corrospond to it EJB/JPA/Hibernate/JAX-WS etc ... not counting the client side code that needs to communicate with that under the constraints of "system architects" who are usually people preparing to retire with a handful of certs and a belly full of vendor lunch.
See, the original way these systems were put together are actually quite genius but in the hands of an aging and apathetic and stressed staff who had little to do with it in the first place, the entirety of the environment is completely unknowable as it has been arranged in ways by people who didn't understand what they were doing and even write in the documentation things like (Everything seems to work if you let it be a PIC 90. Bill told me to always do this, and I've kept on doing it since he died last year) [I shit you not ... actual documentation quote]
See, then there's more ... because there's a variety of things like CICS and Z\OS and system 360 that you have to understand to figure out how to even get to the compiler. There's no IDE for COBOL in actual systems, you have to log in via a PCOM terminal and go through CICS. Then, there's the mountain of access the angry ladies sitting in your old area have to give you and only two of them now how to do it and they know one way to do it that they've done for the past 30 years. It doesn't help if you're a web programmer that makes them have to leave their familiar greenscreen by facilitating the creation of web apps when they don't even have a computer at home nor a smart phone.
Oh but I'm not done .... then there's the Mainframe assembler routines that have been there for 30 years that no one touches or can understand. There's also something called "high level assembler" which is done using variable names and codes for which no one can remember what they mean.
Of course then ... then we get to JCL ... If you don't know what that is, imagine a scripting language in which spaces matter ...
Oh but wait! OBM comes along and says "well you can host WebSphere on Z\OS and make CICS calls to all your lagacy code and still have a web application!" "No need to drop those multi million dollar contracts." "We love you ... You love us ... we're like family!"
Well let me tell you the fun it is making an AJAX call on a setInterval that has to update data from CICS ... Oh boy! So if you like 4 hour meetings with people literally looking at their watch to retire, with stressed management, and frazzled newbie coders just grappling with HTML and JavaScript ... well you're in for a treat! And by treat I mean an abysmal hell of course =D
Oh but then there's a wonderful product called TOP Secret ... that according to the old ladies that hate your fucking guts ... you have to verify all security tokens with!
Oh and wait! There's more! We're Agile with mainframe now!!!
Fucking Kill COBOL or Fucking Kill Me .... one of the two please!
Pay them well, and they will come. Isn't that the way it is supposed to work?
It would be a mistake to forget it ever happened, because then we would be likely to repeat it..
File under 'M' for 'Manic ranting'
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.
If the universe is someone's simulation -- does that mean the stars are just stuck pixels?
...there's JCL.
A 5 second search on a single, non-Mainframe specific job site disproves your assertion that there are "no COBOL jobs". Might be wise to learn the difference between your reality and objective reality before commenting.
> I've had to resort to using FORTRAN to C converters several times, mainly to turn code written by scientists into something useful in a product. It was ALWAYS worth the effort!
Really ? Do you not understand the largest difference in FORTAN and all other current languages ?
In many applications, the difference may not be noticable, but in many mathematical cores, the transformation is fatal !
FORTRAN stores arrays in Column major order, whereas nearly everyone else stores them in Row major order.
This difference can be the difference betwixt high order page/cache/tlb misses, and running/scaling smoothly
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 interpretation) for one reason only: Citibank, Federated Insurance, Wells Fargo, FIS, Bank of America all were extremely heavy players in that degree path at that university. Hell, our professors who taught those banks of classes were soon-to-be-retired Citibank senior developer vets teaching us their standards, techniques, and tons of this-is-the-difference-between-academic-code-and-real-world-code lessons. So as much as everyone makes this baseless argument about how it's dying --- even back in early 2000, after the Y2K scare, it seems like the big banking brains were setting themselves up for long-term rollover of fresh meat to take on the mainframes.
I actually went on to work at Citibank for a few years, but I worked on the front-end and middle-ware vs. the back-end mainframe, even with all my newly fresh COBOL skills. All I can tell you is: that shit isn't going anywhere. I know plenty of people who still hack COBOL for a living. And as long as banks still push the agenda at universities and kids who are intimidated by computer science take these courses, not only will it still be taught to a fresh crop of students, it means that bankers know money and also know how much fucking money they'd lose migrating away from it in any sort of planned manner.
Has IBM stopped making AS/400 iterations past it like the System I and such? Hell no. All the answers are there. COBOL is here to stay.
COBOL programs are really just giant program comments that have delusions of actually running.
File under 'M' for 'Manic ranting'
... 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
maybe if you put the right cover sheets on the TPS reports there wouldn't be a problem?
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, learning a language is very minor to that in comparison. Once you learn each of the major common categories of languages, mainly procedural, relational, parsing, markup, learning new languages is easy, its not like learning a human language, since using programming languages you have the benefit of using language documentation as you go, rote memorization is unnecessary and actually a waste of time. No one memorizes every API, not unless one has savant capabilities. Learning a new computer language can take, a week or two, if that. I learned C# in a few days (as far as being able to read and write the core language). You use references for all of the APIs. People can be up and running with new languages in no time.
This idea "we cant find workers who have 5 years of experience with language X" is the line of middle managers who don't program themselves and dont understand any of this, and think its like a human language. Its a nonsense argument. We can train programmer for COBOL in a very short period of time.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!
There are massive problems with Doderlein's suggestions:
1). His third option, clearly the one he's selling as "the cheapest and probably easiest", is fatally flawed. This suggests that you can 'plug-in' modern modules to a COBOL core. This is a services oriented view of a systems architecture, and guess what? None of the COBOL legacy uses a services architecture. It is routinely monolithic code blocks. One program (or a very few programs) do all the work. There are multiple steps to be performed and long ago, those multiple steps were all integrated into one logic block. Integration is good, right? Don't you want efficient code (and efficient code back in the day was much more important than today)?
2). As others here have noted, option 1 is also poorly worded. Since when is "do nothing" a plan? That's not realistic nor is it a plan. The real plan is to start training new COBOL programmers as a long-term play to keep COBOL relevant and your workforce alive and available. Also, increase their wages as an incentive because you need an incentive to keep IT people interested in old technology.
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.
deleting the extra space after periods so i can stay relevant, yeah.
The fundamental problem with auto-translating COBOL into something like C(++) or Java is the fact that the resulting code might be semantically-valid C(++) or Java that successfully compiles & runs, but it would probably be almost impossible for humans to make sense of, let alone safely modify in the future.
When COBOL programmers start retiring, they will train their H1B replacements. What, did you think the banks would hire American programmers? LOL.
"The only good windmill is a tilted windmill."
Is it possible to do CSS in COBOL?
I think someone might have tried.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
If Java, Python, and C support decimal operations, then why are a class, a module, or a library required? COBOL, on the other hand, directly supports decimal numbers. Two fixed point numbers can be read in, then operated on directly, then written out with no conversions. And the operations (add, subtract, multiply, divide, format, etc) are done with a single machine instruction (on a mainframe).
To do anything in C you need to link to a library. Modules are also standard in Python. The BigDecimal class is part of the standard JDK.
File under 'M' for 'Manic ranting'
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.
"How to Do Nothing," kids activities, back in print!
Huh? You can do binary integer and floating point arithmetic in any of those languages without any libraries, classes, or modules. You can only do decimal operations in those languages by either converting the decimal numbers to binary, operating on them, and converting back or by calling something written in a different language. Hiding those things elsewhere does not magically mean that the language supports decimal.
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.
Have gnu, will travel.
that banks are allowing the users of Slashdot to decide whether or not some programming language dies. Even more surprising is that everyone who is not a bank would go along with the decision, which would be required to kill off said language.
And of course there is Betteridge.
What a stupid topic.
PlanetVulkan.com
The process you describe for those other systems is exactly what is done with COBOL when it is run on a microcomputer that does not have those native decimal instructions. For what it's worth, intel's binary decimal128 has 34 digits of (exact) precision, which is pretty close, but also has the advantage over COBOL's mechanism of also being able to store an exponent on the number. allowing the same variable to hold values of different orders of magnitude without the application needing to know what those magnitudes are.
File under 'M' for 'Manic ranting'
Because it's cheaper.
That depends on what you count. It might be cheaper in the short term to keep patching together an increasingly obsolete and aging system than to develop a new modern one but if you look at the longer term the higher maintenance costs add up. On top of this there is a lost opportunity cost: you could miss out on new, profitable technologies and methods if you have an older, less flexible system which is why banking innovation seems to be increasingly happening in companies outside the sector e.g. things like Apple pay.
If they can find Cobol programmers, more power to them! If they can't, let the survival of the fittest weed out the banks that won't do what it takes to survive.
Wasn't this or a related reason as to why John Titor came back in time? If we get rid of COBOL wouldn't that mean he would not have a reason to come back... or wait does he come back because we get rid of it?
How about instead writing something that correlated inputs and internal state or outputs to auto-generate test cases. That would be a useful basis for maintaining the current system and developing future systems.
Nullius in verba
We have this discussion every single year.
The fact that we have this same discussion every single year should tell you that COBOL is probably going to be around for another year.
See you next year.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Given that they threw a load of us COBOL programmers on the scrapheap for being "too expensive" after Y2K. Not as expensive as not having us available is it you bunch of pricks. Have fun spending billions rewriting it all.
Any LOB (Line Of Business) application will require periodic tweaks and refreshes to remain relevant to operations. Depending on the business, the amount of time between required changes could be measured in days, months or years. Regardless, when the time comes, a choice must be made. The decision is between either improving (in the "remodel" sense) upon an existing application, developing an entirely new one, or adopting/adapting a COTS (Commercial Off The Shelf) solution.
For incremental changes, improving on an existing application is likely the least negatively impactful solution. The procedures associated with the software upgrade process should already be fully baked within the organization. Retraining costs--both time and money--will be limited to application changes only. There won't be a need to maintain side by side systems like there is while proving out an entirely new technology. TCO (Total Cost of Ownership) is understood.
However, it's always worth considering what positively impactful changes a new, custom LOB application or COTS solution could provide. It could be that the hardware required to run it would be cheaper or more readily available. It could be that the programming talent required to maintain it would be cheaper or more readily available. It could be (in the case of COTS software) that hiring people familiar with using and supporting it would be cheaper than training them to use and support a proprietary solution. And, of course, it could be that it offers desirable features that are cost prohibitive or technologically infeasible to implement in a legacy LOB application.
Which solution you choose depends on how risk averse you are, how much money you have to spend, and whether you need to gain a competitive advantage over (or catch up to) your peers.
COBOL is an old language, and it is still used in a lot of places. Just like a human language, it will continue to exist for as long as there are people who choose to use it. As to whether it should be abandoned in favor of newer languages, I submit that the same argument could be made for phasing out most of the world's time honored human languages. Why continue to use something that has bizarre syntax rooted in ancient history? Maybe because it continues to work, regardless its accumulated cruft. (I don't see much traction to adopt Esperanto as a world standard!) Unless we go out of our way to shun and discourage the use of COBOL, I suspect it will continue to be used where applicable for a long time to come. People who don't want to use COBOL are welcome to use something else. There is no shortage of languages.
Train developers.
One procedural language is much like the next. Once you learn the syntax, the basic ideas and concepts are transferable. Most of the COBOL developers who built these systems learned most of what they know on the job.
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.
The right criterium is not how old or old fashioned something is - if it does the job better than something newer, then it is the newer technology that isn't good enough. One of the things about COBOL is that it is in many ways such a simple language, compared to modern ones; the complexity is mostly the very heavy syntax and convoluted attempts at using language that would have been seen as solid, American and business like in the 50es. When you get down to the actual code that does something, it is surprisingly close to assembler in many ways:
ADD NUMBER TO ANOTHERNUMBER. ...
PERFORM PROCEDURE1 25 TIMES.
I think there is very little to optimise from the compiler side, and the lack of advanced syntax may well be a major advantage - business transactions are computationally very simple and mostly only require the things that COBOL does. I think, if one were to seriously replace the language, it should be with something equally simple - a kind of COBOL with a lighter and less convoluted syntax, and it would probably lose the identification and environment division. Things that actually make the code clearer to read would be added, like procedures with parameters, to avoid using global variables etc. Who knows, it may already exist - I haven't used COBOL for decades, and I think I have heard the term 'OBJECT COBOL'.
YES
Wrote this article with a big smile on his face, silently whispering "hahaha! I'm really going to piss off those stupid slashdotters today!"
I tend to rant.
If I was the cynical kind I might be tempted to think that this Dunderloon character is selling something.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Serisously: Where are these Cobol positions in desperate need of filling?
If they really are desperately needed, they should translate into 80 000€+/Year, 40 hour workweeks, 30 days of vacation, zero-fuss relocation support and some other niceties. Give me that and I'll drop my current hard-pressing hipster-induced TypeScript/JS/NodeJS ambitions instantly and dive into Cobol right away. I'll be the Cobol master in a year and enjoy it aswell. And as a guy with ERP/E-Commerce order processing experience, I get serial processing (which banks still do for transactional safety) and other old-school super-conservative ways of doing things.
But somehow something tells me they want people no older than 28 with 10+ years of Cobol experience and top-grade proficiency with Oracle 4.x and some obscure version of AIX. And offer a laughable 44 000€/Year and I have to move to Frankfurt, a town that is ugly as hell and has real-estate and living costs move off the charts big time, even more so since Brexit.
So, unless I get a call by a banking Ops manager telling me that he's in desperate need for Coders willing to move to Cobol and if I would care to give it a shot and offers me something along the lines stated in the first paragraph, I'm not really holding my breath or feeling to much pitty for the banks.
My 2 eurocents.
We suffer more in our imagination than in reality. - Seneca
Which is to train people in COBOL again. I learned it during my time at university. It isn't a difficult language to learn. I've just never used it since.
... if you can't learn COBOL in a week. It's all about syntax, and it's really not that difficult.
I've jumped from language to language my entire career, the first one was only the most difficult because I had to learn constructs like 'if .. then .. else' and looping and such. And recursion, which old COBOL didn't support anyway.
If someone can't translate their current skills into COBOL, they have no business being in computers at all. Languages change all the time, and if you can't learn a new one quickly, you have no future in the business at all. Hell, I once modified a program written in a language I had never seen before and had no manuals for.
A developer's goal should be to become proficient in many language, and at least knowledgeable in many more. Just last month, I had to read COBOL code in order to write a Java program because the files were created by a COBOL program and I had to know figure out to process EBCDIC files with COMP data into a class and what each field was for. No one on the team had a clue ... it took me about 2 hours.
But I'm old and have skills because I've never said that I don't know how or can't do something. Instead of whining like a little baby when given a small challenge.
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
Well yeah, it is the job of an optimizing compiler to produce the most efficient code for a particular architecture. Of course, the compiler can only do that if the language supports a particular type of data. If the language doesn't support a particular datatype, then you can't do anything at all with that type of data. Which is why the gmplib has all the important stuff written in assembler (not C) - because C does not support decimal operations.
The question is not whether or not you can do a certain operation in a given language. You can do damn near anything in any language. The question is can you do it efficiently. The 'C' implementation is probably the least inefficient, but it is still worse than native support. The Java and Python implementations are ridiculous wasters of cycles.
Also 'INTELS' decimal128???? Seriously?
This. Add to that a lack of documentation, or if you had documentation it would be thousands of pages, not all of it even relevant anymore.
I maintain a number of legacy systems, while not COBOL (I did take COBOL in school ages ago), it doesn't really matter a whole lot what it was developed it. The larger problem is that the system was likely designed to do something very specific, then over the years has been altered and re-altered by who knows how many people (some good, some not so good, none of which are around anymore), to try and keep up with changing business rules. In some cases due to technology limitations these alteration need to be "creative" in order to try and deliver on some requirement not easily done by the platform in use. In a lot of cases the underlying DB structure makes little to no sense anymore because the system does something a lot different than what it was intended for. Half the time you are left guessing why a certain thing was done a certain way at some point in the mists of time. Yes these systems would be extremely hard and expensive to replace, which is basically why they have hung around for so long.
I have one current project to try and modernize a particular system slightly and it has been a nightmare. Every time we change something it breaks 6 other things many of which seem totally unrelated on the surface, then we fix those things which breaks other things, repeat ad infinitum, and it just gets more and more complicated. In many cases part of the problem is that we're doing things from scratch (re-inventing the wheel so to speak), which if we were using other technology would basically be built in to start with. The system itself is almost 30 years old, and I think it is starting to reach it's development saturation point, meaning it is only going to become more difficult (and expensive) to continue to make any changes, at which point management will have to decide if they are finally willing to bite the bullet and migrate to something a bit more reasonable. That said I've literally been actively championing that for the last decade, yet here we are... On a more humorous note, the other day I was testing very deep (in an attempt to break the aforementioned infinite development loop) and found part of the application that I have no idea what it does, and so far as I can tell does nothing (though seemingly nothing to do with my project). Curious I went through old documentation from the late 90's and found that even then it's function was "unknown", anyway I had a bit of a laugh at that at least. Literally no one has known what that function does for the better part of 20 years, and yet it is still in there.
Another non-COBOL related, but similar issue is at one point I was complaining about the output of a particular system because it feeds into several systems I have to try and maintain. After a bit of investigation (and it took awhile to even find someone that has been around long enough with this bit of knowledge), I found that the system in question is even *older* than any of my other systems, written in FORTRAN, nobody knows how it works anymore (other than it does it's thing and presumably spits out seemingly correct numbers), and no one is willing to touch it with a 10 foot pole for fear of breaking it... So I am stuck dealing with that for the foreseeable future. Not sure if FORTRAN programmers are easier or harder to find than COBOL, but even back in the day I never took FORTRAN in school. I'm sure that will be an interesting project when someone has to eventually deal with it...
I'm not a mainframer but I do work in another industry highly dependent on them (airlines.) Some of the core components of major passenger processing systems like Sabre, Amadeus, etc. are still kicking along on mainframes. A lot of the COBOL has been refactored into something more modern but some things are much harder to replace. Also, a lot of the stuff that's non-core has been migrated to more open systems so it's cheaper to run and easier to change. But, the thing to remember about airline applications is that all the customer-facing stuff like kiosks, web booking, RFID baggage tracking, etc. rides on top of this ancient core. When you do something on an airline website or check in at a kiosk, the software running there is usually reaching down into the mainframe either directly or through an equally complex web of services, wrappers, etc.
I think one of the reasons mainframes refuse to die is because nothing has replaced the "uptime culture" surrounding them. For example, I love x86 virtualization and cloud computing because I can instantly start up any environment I want, use it, and rip it down whenever I'm done. Mainframes don't really have that -- the goal is 100% uptime which is why businesses like banks, insurance, airlines, etc. rely on them so heavily. To achieve that, the culture around the mainframe is to have expert systems programmers who know the ins and outs of the system, and to test everything to death before rolling it out to production. It's incredibly rare to see code updates severely break anything, and part of the reason is that the culture is to not touch things that are working "just because."
It's very easy to say "oh, just rewrite everything in Java and rip out the mainframe." It's much harder to instill the discipline required to maintain core systems that can't ever go down, can't corrupt data and are vital to a business. Replacing veteran system programmers with a bunch of 20-something bros refactoring in 18-hour code sessions while doing shots, or an offshore body shop of 1,000 Indians who took a COBOL course is a culture shift.
From what I see, companies are dealing with the COBOL shortage by going the body shop route rather than train new grads. I think that new grads would be perfect for this kind of work, because it exposes them to good change management practice. Then again, I'm a big believer in the apprenticeship/trade guild system for training software and IT pros. Right now, companies want drop-in replacements for new hires and anything other than the new hotness on your resume gets it trashed. I'm very lucky to have been able to work in environments with a healthy mix of new and ancient, and it's been very helpful career-wise to at least have an idea of what's going on in the legacy side of the house. Even if I really don't know what's going on under the hood, it's better than throwing your hands up and refusing to touch something, saying "I'm a Windows/Linux admin" or "I'm a Java developer"
A COBOL programmer, C++ programmer and Java programmer go to the bathroom at the same time. After using the facilities, the C++ programmer washes their hands and uses a tiny bit of paper towel to dry off, using every bit of the towel. The Java programmer grabs a giant wad of towels to dry their hands. The COBOL programmer walks out without washing their hands at all. "Whoa whoa!" the other programmers say. "Aren't you going to wash your hands?" The COBOL programmer responds "Kids, I learned a long time ago how not to piss on my hands."
(Originally, I heard this joke a long time ago using mainframe, Windows and Linux admins.)
The real problem isn't COBOL as a language. It is understanding huge highly customized systems that have evolved over decades of changes and being familiar with them enough to be effective. The problem is in many cases no one keeps IT staff on anymore. They are seen as a commodity. Everything is done by consultants now. In many cases it is the same old consultants, so it works for a time. However when they are gone, things get exponentially more difficult to try and maintain.
I had a laugh at your last sentence, pretty much the entire industry in a nutshell!
If It Ain't Broke Don't Fix It
They're probably too short-sighted and assume that this lack of talent will result in the only remaining talent asking obscene amounts of money (obscene to the bankers, that is).
You're right, though. That is the solution they need to use, it's just not obvious to people who don't do software. That problem isn't singular to banking either.
I tend to rant.
As a software developer, the language I use is largely irrelevant. Sure, each language offers its own advantages and quirks, and it might take from a few months to a year to get completely comfortable in it...but honestly, that's nothing. If COBOL developers really are in such ridiculously high demand as this and countless other articles claim, why aren't more developers flocking to the language? What is preventing this? I don't understand. I would certainly consider it myself if I found myself in need of work, and supposedly there are a lot of IT folks getting laid off left and right. This "problem" just seems odd to me.
Funding academic CS work on COBOL-to-C, or maybe even COBOL-to-C++, source transformations. They could start with any of the hits a "COBOL to C" Google search provides.
I loved COBOL in the 1960s, even though compiling it on a bank of magtapes could take all night. It was almost self documenting, and you could debug by reading your code across the tops of the 80-column source cards. More recently I saw a US software house trying to adapt their steaming pile of COBOL to a UK corporate: even the field-lengths were a disaster. But from a much more senior perch, I was never able to recommend a plain-language improvement (APL was fun but too quirky). Now that use-cases are routinely object-mapped, with parseable definitions, why can't the current generation design a problem-oriented upper layer for management to approve? And why can't inheritors of COBOL puzzles reverse engineer their sources (if they can be found) and map the stuff out properly for whatever gizmo is fashionable now, to error/ambiguity-check in an attractive GUI and then auto-code?
First ask yourself is Cobol good for what it's used for and is switching to another language "better". A lot of languages are created for a specific purpose and when something better comes along, that's when you should probably phase it out. Switching to another language so I can get a cheap / inexperienced programmer who will likely make a huge mess of it is not a good idea.
Second, anyone who calls themselves a reasonable programmer should be able to adopt another language. It might take them sometime to become efficient or skilled at it but the point is a good programmer should be able to pick it up. I remember in my final year of university we got exposure to some downright weird or difficult to program languages like LISP and we were still able to make do.
Third, ignoring the issue is the equivalent of saying "Screw it!" and kicking the bucket down the road making it someone else's problem. This is never a good solution, have a phase out plan, train some employees or a fallback. Don't just wait till your last skilled programmer retires and you're now up the creek without a paddle.
I have the raw energy to make the move into a language where businesses allowed old people but I'm making too much doing C#.
Then you'd be rich by suing companies that loose money in their business systems. But you aren't, money aren't lost/stolen by code and the lie is yours.
Financial rules are very strict. There's a reason why IBM spent a lot of effort supporting decimal floating point in hardware, it is more suited for financial rounding etc. Think they did it for fun? Think they did it to help javscript-class programmers that can't comprehend standard floating point arithmetics? Nope.
One thing you need to understand about programming languages, is that they're like comic book villains. They do die, but they're never completely dead. I learned COBOL for fun a few years ago, seeing it through the eyes of a modern programmer. It's unique among programming languages, I find the syntax remarkably straightforward, after you get used to some of the underlying concepts it's predicated against.
I think the language has possibilities. Especially in an age where the human computer interface has moved from keyboards to voice. It would be amazing if you could do the kinds of complex programming tasks by voice that you see in Star Trek, and I think we're only a few years off. Here, COBOL is really the only language that makes sense for the task. Well, for the most part, and barring some of the more recent additions to the language, that is. No such application exists for it, yet, but it certainly could. And something like that will certainly be both needed and wanted in the coming years.
As far as the banks go, you have to understand business. If a system works properly and needs very little maintenance, there is no business case for replacing it. It's not like anyone runs websites with COBOL these days. Typically, it's the language of big iron mainframes, that were designed to last forever. If the current group of COBOL programmers does die out, it makes sense to train new ones. There's still a fair amount of demand for it, which will appeal to the mercenary nature of modern programmers.
I don't think that's an outlandish suggestion. We pay people to learn new things all time, even programming languages. To pretend that banks are somehow different than any other big organization, anywhere else, in any other industry is silly. Let's just call this what it is, stop worrying about it, and move on.
This signature has Super Cow Powers
If it did, we should junk our running and serviceable cars and buy the latest new shiny thing being offered Who cares what that costs?
What drugs are these people on?
The term "technical debt" would seem to be especially helpful in explaining the need to phase out those COBOL programs as quickly as prudently possible.
If anyone ought to get the aptness of the metaphor, it should be people in the financial sector. How debts not paid keep growing until disaster inevitably occurs. And if a firm has a disaster, it goes out of business.
At least, that's what I would have thought before 2008.
There's no time like the present. Well, the past used to be.
Sorry to burst your bubble, but it would be seriously cost prohibitive to re-write all the COBOL applications banks use.
COBOL allows a kind of "hierarchical data dictionary" where parts of a "struct" can have their own name so that you can reference subsets (tree branches) to process as a group. Most languages we use today don't have anything equivalent directly in the language. It can be reinvented in API's, but it's probably harder to read and work with than COBOL's native structure. It's somewhat comparable to XML for custom data structures.
And C and Pascal are probably influenced by a common language, perhaps Algol, which is arguably a "cleaner" variation of Fortran. COBOL is a very different kind of animal from Algol-influenced languages, including its type system (if you can call it that).
Table-ized A.I.