How popular is COBOL?(techradar.com)
techradar.com
How popular is COBOL?
https://www.techradar.com/news/cobol-wants-to-find-out-just-how-popular-it-really-is
83 comments
I did a co-op semester at a large company doing work on mainframes with COBOL in the late 90s. They had brought some of us in along with some other new hires. The other hires were slightly older and come from other careers. For example, one guy wanted to get out construction and into technology and that's why he was there. The company did extensive in house training because none of this stuff is taught anywhere.
It's like an alien world where some of the ideas are similar but also everything is completely different. Linux/Mac/Windows are all different but they are not different like working with mainframes is different. So if you started without any PC background, it really doesn't matter.
Personally, it wasn't for me. The whole thing was basically frustrating. The technology was frustrating. The glacial pace of development was frustrating. One program I worked on was literally older than I was. The code quality was very high (given the technology) but that was accomplished by sheer effort rather than having smart tools.
It's like an alien world where some of the ideas are similar but also everything is completely different. Linux/Mac/Windows are all different but they are not different like working with mainframes is different. So if you started without any PC background, it really doesn't matter.
Personally, it wasn't for me. The whole thing was basically frustrating. The technology was frustrating. The glacial pace of development was frustrating. One program I worked on was literally older than I was. The code quality was very high (given the technology) but that was accomplished by sheer effort rather than having smart tools.
I worked at one of the big financial corps where we were built on top of IBM DB2 with plenty of Cobol and JCL. Almost every team had 1-3 Cobol or "Data" programmers as we said embedded in them. If you needed to get or store data, it involved writing Cobol store procedures, and calling them from Java. There was also a lot of mainframe code running batch jobs that did a lot of critical work. this was from 2016-2021 so its pretty recent.
Cobol devs were on average a bit older (on average id say 10-15 older than the rest of the devs), mainly because there weren't many college grads going in, and like your advisor had said there was a split between cobol and non-cobol devs with very little overlap.
The majority of the cobol devs seemed to fall into a few camps. There were people who graduated in the 80s or 90s and just kept doing the same thing. There was also a large amount of Eastern Europeans that had immigrated in the 90s / 2000s and were cobol devs. Then there were also a decent amount of Indian contracting companies (TCS and the like) which seem to also train people in Cobol even today to hire as contractors.
Cobol devs were on average a bit older (on average id say 10-15 older than the rest of the devs), mainly because there weren't many college grads going in, and like your advisor had said there was a split between cobol and non-cobol devs with very little overlap.
The majority of the cobol devs seemed to fall into a few camps. There were people who graduated in the 80s or 90s and just kept doing the same thing. There was also a large amount of Eastern Europeans that had immigrated in the 90s / 2000s and were cobol devs. Then there were also a decent amount of Indian contracting companies (TCS and the like) which seem to also train people in Cobol even today to hire as contractors.
At least where I live, most/all established banks have COBOL training programs for new hires. A friend of mine started one just a couple of months ago. As I understand it, it's not easy for them to find people who are both skilled programmers and willing to learn COBOL. If you really want to reskill into a COBOL developer, I believe that's very much an option still.
Thanks for the pointer! Do you (or your friend) happen to have a link to a sample job post that I may be able to use to identify these opportunities in the future?
Not job related but have a look at Xplore and get your hands on a Mainframe and Cobol:
https://www.ibm.com/it-infrastructure/z/education/zxplore
https://www.ibm.com/it-infrastructure/z/education/zxplore
Unfortunately I don't have any link to such a job post, but when I've seen them in the past they've clearly stated what they are about, so keywords like "COBOL" or "Mainframe" would certainly find them. Sorry I couldn't be any more help.
No worries at all, again thanks for the pointers!
There’s a Coursera course series for that, coincidentally found it today:
https://news.ycombinator.com/item?id=34012657
https://news.ycombinator.com/item?id=34012657
Amazing! Thank you so much for pointing this out to me. It's basically exactly what I hoped to find :-)
You can run COBOL at the edge, with cloudflare:
https://blog.cloudflare.com/cloudflare-workers-now-support-c...
https://blog.cloudflare.com/cloudflare-workers-now-support-c...
I've dived relatively deeply into mainframes as a small, intermittent hobby the last few years (https://www.jaymoseley.com/hercules/). Read (and organized!) a lot of IBM documentation, played with JCL more than just on the surface, explored corners of the OS, and dabbled with some s/360 assembly and PL/I. At some point I inspected hex dumps of the disk ("DASD") images to prove a theory I had.
What attracted me to it is just how different it is from the UNIX/PC world I'm coming from, it's endlessly interesting, it challenges what you assumed were ground truths. So is AS/400 (or IBM i as it is now called), which is also completely different but in some ways opposite to how the mainframe world is different.
Those two rewired my understanding of OS reality like Haskell rewired my understanding of programming language reality.
At this point I could probably dive into COBOL and pivot my job into maintaining mainframe stuff, and some part of me thinks it's fun, but I have a fun low level programming job, so I don't know if I'd ever really do that. Maybe to fill time during retirement?
What attracted me to it is just how different it is from the UNIX/PC world I'm coming from, it's endlessly interesting, it challenges what you assumed were ground truths. So is AS/400 (or IBM i as it is now called), which is also completely different but in some ways opposite to how the mainframe world is different.
Those two rewired my understanding of OS reality like Haskell rewired my understanding of programming language reality.
At this point I could probably dive into COBOL and pivot my job into maintaining mainframe stuff, and some part of me thinks it's fun, but I have a fun low level programming job, so I don't know if I'd ever really do that. Maybe to fill time during retirement?
Okay, I uncharacteristically have to respond to my own post, because I happened to reread it in the "threads" tab and it jumped out to myself just how wrong it sounds, even though it was upvoted. I had edited it before hitting send, and apparently did not notice that I kind of damaged the meaning.
So to be clear, what I meant to say was that for a small hobby I dived relatively deeply into it (i.e. I see others messing with it for fun not caring that much about e.g. JCL), and that I wet my feet enough that if I put the serious work in, I could see myself eventually becoming productive in the COBOL and mainframe world.
Just because rereading it, it sounded like I said I became mainframe proficient to a commercial level by playing around with a many decades old MVS version on Hercules, which is hilarious.
So to be clear, what I meant to say was that for a small hobby I dived relatively deeply into it (i.e. I see others messing with it for fun not caring that much about e.g. JCL), and that I wet my feet enough that if I put the serious work in, I could see myself eventually becoming productive in the COBOL and mainframe world.
Just because rereading it, it sounded like I said I became mainframe proficient to a commercial level by playing around with a many decades old MVS version on Hercules, which is hilarious.
I had not worked with cobol until recently.
If you have a solid background in C, it is not very hard to learn. It seems to show up at older companies, and is fairly good at moving and reformatting records where you want to address each field on a character by character basis.
Unlike more modern languages, there's no encapsulation, polymorphism, local variables, etc., so you can write tangled code quite easily, though the code I've seen has been very well written. Everything is in capital letters, and the character set is often ebcdic. Most numbers are fixed decimals, which leads to some unusual math results.
As a result, it can be maddeningly verbose -- I've seen 100+ lines of code that would just be a single printf statement in most other languages.
If you have a solid background in C, it is not very hard to learn. It seems to show up at older companies, and is fairly good at moving and reformatting records where you want to address each field on a character by character basis.
Unlike more modern languages, there's no encapsulation, polymorphism, local variables, etc., so you can write tangled code quite easily, though the code I've seen has been very well written. Everything is in capital letters, and the character set is often ebcdic. Most numbers are fixed decimals, which leads to some unusual math results.
As a result, it can be maddeningly verbose -- I've seen 100+ lines of code that would just be a single printf statement in most other languages.
Frankly, I was shocked at how low COBOL salaries tend to be.
I want extra money to code in a terrible language maintaining your bloating, ancient codebase. They believe that all of this should mean LESS salary.
Meanwhile, old COBOL devs are retiring in droves and the businesses stuck on COBOL have countless billions riding on those systems.
Why hasn't supply/demand kicked in yet?
I want extra money to code in a terrible language maintaining your bloating, ancient codebase. They believe that all of this should mean LESS salary.
Meanwhile, old COBOL devs are retiring in droves and the businesses stuck on COBOL have countless billions riding on those systems.
Why hasn't supply/demand kicked in yet?
Because COBOL is not difficult to learn, in fact it was designed so that 'businesspeople' could easily learn it (Which didn't happen).
COBOL is merely undesirable from a long term career perspective.
The aggregate demand is also very small.
Therefore India's big IT shops can simply train some fresh grads to learn COBOL. Those grads don't care about working on the latest tech, they just want a well paid and stable job. This puts a hard ceiling on the wages of COBOL programmers.
Therefore India's big IT shops can simply train some fresh grads to learn COBOL. Those grads don't care about working on the latest tech, they just want a well paid and stable job. This puts a hard ceiling on the wages of COBOL programmers.
COBOL may not be all that difficult to learn, but the proprietary systems and environments that a legacy COBOL program will be designed to interact with are a different story. These are often extremely obscure.
Yeah. One of the biggest "myths" around computing is that non-technical people will want to do any form of coding (and yes, I'm talking about BDD as well)
The only development environment they know (barely) is Excel
The only development environment they know (barely) is Excel
From what I see on the Internet usage of COBOL correlates with under-investment. It may happen even in a multi-billion company which considers software a cost center and tries to minimize 'waste' of money by not paying developers market rate salaries.
those same businesses are run by tech executives who haven’t written a line of code in 20 years
it’s all about saying no to raises, controlling people to work with their butts in a chair in an office, 8am meetings, 10 different teams to do basic things, 5 people per project whose sole job is to say “no we can’t do that”, lots of 2am batch processing on call
not sure if supply/demand works for 40k employee companies
it’s all about saying no to raises, controlling people to work with their butts in a chair in an office, 8am meetings, 10 different teams to do basic things, 5 people per project whose sole job is to say “no we can’t do that”, lots of 2am batch processing on call
not sure if supply/demand works for 40k employee companies
I've been working in environments that use mainframe systems for a long time. I've read COBOL code to get an idea of what's happening downstream, but never actually written a line of COBOL myself. I've always wanted to know: In a modern context, does COBOL have any advantages for applications like transaction processing?
I understand that it's not ideal from a language point of view, but does it have any properties that make it a great fit for the job? Does COBOL on a mainframe have particular properties that make it good for concurrency, validation, etc?
I understand that it's not ideal from a language point of view, but does it have any properties that make it a great fit for the job? Does COBOL on a mainframe have particular properties that make it good for concurrency, validation, etc?
It basically is extremely reliable and deterministic. Mainframes just work and stay up indefinitely. If you want to do a tax report or send out scheduled mails on 5 000 000 accounts, cobol is the right tool for that sort of job. Just shuffling data in let's call it a DAG of batch jobs with sql and restart checkpoints sprinkled in. It fails due to human error in the code or a relied upon system, because bugs in the language itself are nonexistent. Updates to the code is mostly due to regulation and compliance and keeping the business running.
But mostly, it's just impossibly expensive to rewrite a humongous spaghetti of societally critical systems from cobol to something modern such as java or .NET.
But mostly, it's just impossibly expensive to rewrite a humongous spaghetti of societally critical systems from cobol to something modern such as java or .NET.
I am curious, and I don't have the insights into these systems. But you first mention DAGs. And then you say rewrite to java or .NET.
When I think about DAGs today, i think about Airflow. And SQL.
Would it be a better match to rewrite these systems in SQL and Airflow? SQL for the logic and Airflow for the batch processing.
I know for many (particularly those who mention java and .NET) SQL is just a place where you fetch and store your data. But once you start building systems with it, you will soon realize it contains nothing more and - at the same time - nothing less than what you actually need for mangling your data in a terse way.
I know there are many reasons to frown on SQL for this, and I am fine with any comments about it. I think it can be a start of a good discussion. Nothing is black or white.
When I think about DAGs today, i think about Airflow. And SQL.
Would it be a better match to rewrite these systems in SQL and Airflow? SQL for the logic and Airflow for the batch processing.
I know for many (particularly those who mention java and .NET) SQL is just a place where you fetch and store your data. But once you start building systems with it, you will soon realize it contains nothing more and - at the same time - nothing less than what you actually need for mangling your data in a terse way.
I know there are many reasons to frown on SQL for this, and I am fine with any comments about it. I think it can be a start of a good discussion. Nothing is black or white.
So what I mean when I say DAG is just a shorthand of describing the architecture of the data flows. Like that's how it looks like when you draw up the jobs and how they depend on eachother. So I just took a linguistic shortcut, mainframes don't support objects such as graph datastructures anyway in an accessible and efficient way.
All the actual customer data is stored in databases so that's why SQL is needed. And then to access those databases you call various in-house cobol systems with the right parameters. SQL is good for the type of business logic that these systems do, for example niche cases like FATCA and CRS tax reporting and tons of legal details like that, to organize the business requirements it's embedded in the cobol programs as DB2. When you want to send out mails daily, monthly, quarterly, yearly, and so on, in ten different modes depending on a parameter, with different variants depending on user and organization data that's an orchestration done in mainframe OPC scheduler with various applications with jcl and proclib, and I think SQL is too strictly logical and can't do the fuzzy parts with strings and files and system communications to be economical as a full replacement. I'm pretty new so I don't understand most of the stuff honestly which is why I'm throwing out a word salad here.
We do have java and .NET parts that we communicate with, built around bought solutions that needed integration. Airflow would have to be integrated in the same way but can't be a full replacement
All the actual customer data is stored in databases so that's why SQL is needed. And then to access those databases you call various in-house cobol systems with the right parameters. SQL is good for the type of business logic that these systems do, for example niche cases like FATCA and CRS tax reporting and tons of legal details like that, to organize the business requirements it's embedded in the cobol programs as DB2. When you want to send out mails daily, monthly, quarterly, yearly, and so on, in ten different modes depending on a parameter, with different variants depending on user and organization data that's an orchestration done in mainframe OPC scheduler with various applications with jcl and proclib, and I think SQL is too strictly logical and can't do the fuzzy parts with strings and files and system communications to be economical as a full replacement. I'm pretty new so I don't understand most of the stuff honestly which is why I'm throwing out a word salad here.
We do have java and .NET parts that we communicate with, built around bought solutions that needed integration. Airflow would have to be integrated in the same way but can't be a full replacement
Thank you for your comment!
Handling the DAG architecture in a batched system is exactly what airflow does. Do this, wait here, when it is done do that. So the DAG acronym is entirely appropriate for this discussion.
And you can have tasks in Airflow that send out mails, quarterly that depends on the quarterly summary to be executed.
So my idea here is to
- Ingest all raw data into e.g. BigQuery. - Combine it the way you want with SQL - Add tables with email addresses etc for customer adaptations along with parameters - Join with those table to create custom adaptations. - Add output layer stuff (email, upload to custom file system etc).
Now you have one place and one language for your logic. Given that this part of the system is inherently batched that is. If it is real time/streaming it will not work.
The "can't do the fuzzy parts with strings and files and system communications" needs to be defined. This is the rot in the system, the ghost in the closet that everyone is afraid of approaching.
Handling the DAG architecture in a batched system is exactly what airflow does. Do this, wait here, when it is done do that. So the DAG acronym is entirely appropriate for this discussion.
And you can have tasks in Airflow that send out mails, quarterly that depends on the quarterly summary to be executed.
So my idea here is to
- Ingest all raw data into e.g. BigQuery. - Combine it the way you want with SQL - Add tables with email addresses etc for customer adaptations along with parameters - Join with those table to create custom adaptations. - Add output layer stuff (email, upload to custom file system etc).
Now you have one place and one language for your logic. Given that this part of the system is inherently batched that is. If it is real time/streaming it will not work.
The "can't do the fuzzy parts with strings and files and system communications" needs to be defined. This is the rot in the system, the ghost in the closet that everyone is afraid of approaching.
There's a good discussion of this at https://medium.com/the-technical-archaeologist/is-cobol-hold....
It starts off by suggesting that it's all about how COBOL's superiority stems from having support for Binary Code Decimal as a language-level element, rather than having to be imported via a library (the overhead of which really starts to matter at the volume of transactions which COBOL is typically required to handle). But then broadens the discussion out to argue that the intrinsic shape of the COBOL environment "stack allocation, pointers, unions with no run-time cost of conversion between types, and no run-time dispatching or type inference" is fundamentally different from languages like Java or C#, and those differences provide provide performance benefits which cannot be easily obtained in those other languages.
It starts off by suggesting that it's all about how COBOL's superiority stems from having support for Binary Code Decimal as a language-level element, rather than having to be imported via a library (the overhead of which really starts to matter at the volume of transactions which COBOL is typically required to handle). But then broadens the discussion out to argue that the intrinsic shape of the COBOL environment "stack allocation, pointers, unions with no run-time cost of conversion between types, and no run-time dispatching or type inference" is fundamentally different from languages like Java or C#, and those differences provide provide performance benefits which cannot be easily obtained in those other languages.
I ported gnucobol to webasm to inflict pain on future generations of programmers.
https://github.com/wmealing/cob-webber
Ncurses with vt100 emulation kinda works. But it's timing is garbage and text input is funny.
https://github.com/wmealing/cob-webber
Ncurses with vt100 emulation kinda works. But it's timing is garbage and text input is funny.
I used to work in a bank with people that came from mainframes. They use to talk about Cobol and how it was a well paid job, cause of the lack of programmers.
As a way of learning the language I end up writing a perceptron in it [1]. It was a fun exercise.
1 - https://github.com/victorqribeiro/perceptronCobol
As a way of learning the language I end up writing a perceptron in it [1]. It was a fun exercise.
1 - https://github.com/victorqribeiro/perceptronCobol
I haven't touched mainframes yet but been doing a bit of COBOL.
Telcos, healthcare providers, insurance companies, anything that was early to get a billing system.
Don't get into COBOL if you get annoyed at bad code :D
Telcos, healthcare providers, insurance companies, anything that was early to get a billing system.
Don't get into COBOL if you get annoyed at bad code :D
"How popular is COBOL?" proceeds with giant image of javascript
It is what they call "hero image" these days. Who even comes up with these terms? I dislike it. An unrelated "hero image" of Javascript code plugged into a COBOL article (and the article is pretty good, to be fair) is why I don't like these trends. These trends contribute anything to the article but add distractions.
The amount of credence that this website appears to give to TIOBE (read: any at all) causes me to immediately dismiss their judgment. TIOBE is a nonsensical, wildly-fudged, deeply-flawed ranking made by people who have no idea what they're doing and seemingly no idea what industry they're in (which, if it's not self-evident from the way the ranking is designed, their methodology, and their presentation, should be obvious from the hilariously clueless summaries that accompany the rankings).
By all means, believe whatever you like about Cobol's popularity. But if you think TIOBE has any weight, reconsider your sources.
By all means, believe whatever you like about Cobol's popularity. But if you think TIOBE has any weight, reconsider your sources.
Can you mention any specific problem with TIOBE or a better alternative?
TIOBE's methodology is opaque, and even their own description of their methodology is completely nuts. Their historic trend lines suffer such massive random swings that it's obvious that they go in and manually fudge the numbers whenever it doesn't look "correct" (or are we to believe that C truly became half as popular between 2015-2016, and then gained it all back from 2016-2017? Remember that time that half of all C programmers were laid off, and then rehired eighteen months later? No? Remember that time that half of all C software stopped being used, and then started being used again eighteen months later? No? Then what in blazes is it supposed to have been measuring?). The prose summaries that they attempt to produce each month are technological gobbledygook, too poor to even publish in the sort of magazine that gives free subscriptions to middle managers. The "language of the year" ranking fails to even measure growth! Instead, it just measures the increase in ranking from the previous December, which means that a language whose popularity crashes through the floor for exactly one month out of the year due to their batshit methodology can be awarded "language of the year" for absolutely no reason, and this has happened!
Rather than asking for a better alternative for gauging "popularity", stop looking to aggregators and instead look at actual numbers. For example, if you want to know which languages have the most job openings available, don't trust a measure of popularity, go to a job board and search by language.
Rather than asking for a better alternative for gauging "popularity", stop looking to aggregators and instead look at actual numbers. For example, if you want to know which languages have the most job openings available, don't trust a measure of popularity, go to a job board and search by language.
They rely on easily accessible sources. In a previous job, I've written copious amounts of C# and Java, which will never ever show up in their search. Everybody knows there's a huge bias when you want to conduct a survey and only ask people in the square in front of your house. But when it comes to estimating tech-related things, all caution is thrown out of the window, because "there's so much data."
I had a, which now seems quaint, habit of keeping compile listings (which have all sorts of neat information) for my applications.
However I have a deep distaste for writing in COBOL. That said, my favorite resource for dealing with COBOL problems was AMBLIST which shows the compile date and other attributes of each object module,whether COBOL, FORTRAN, Assembler or PL/I.
There's a number of mainframe source management tools. In VM, XEDIT would automatically generate change records for source files as they were modified.
It made a lot of sense to develop under VM and deploy to MVS, z/OS just to have good source control without having to buy source management tools and enforce their use. I strongly suspect IBM does pretty much the same for their mainframe operating system and utility code.
The dirty secret is that the code that runs logical partitions is a flavor of VM.
COBOL and FORTRAN in the early days had minimal subroutine libraries. Direct calls to the supervisor were made in the compiled code along with building the parameters and handling the results. This does make it more straightforward to see what the object code is doing.
PL/I had a comprehensive subroutine library.
Later on the subroutine libraries for the various compiler languages were consolidated into Language Environment.
However I have a deep distaste for writing in COBOL. That said, my favorite resource for dealing with COBOL problems was AMBLIST which shows the compile date and other attributes of each object module,whether COBOL, FORTRAN, Assembler or PL/I.
There's a number of mainframe source management tools. In VM, XEDIT would automatically generate change records for source files as they were modified.
It made a lot of sense to develop under VM and deploy to MVS, z/OS just to have good source control without having to buy source management tools and enforce their use. I strongly suspect IBM does pretty much the same for their mainframe operating system and utility code.
The dirty secret is that the code that runs logical partitions is a flavor of VM.
COBOL and FORTRAN in the early days had minimal subroutine libraries. Direct calls to the supervisor were made in the compiled code along with building the parameters and handling the results. This does make it more straightforward to see what the object code is doing.
PL/I had a comprehensive subroutine library.
Later on the subroutine libraries for the various compiler languages were consolidated into Language Environment.
Maybe it's the type of companies I've worked for but I have never seen cobol. Anyone know where it's used most?
Any company that knows better has done a modernization to get to get off it asap. The legacy nature of the products means that the few outlets that still support them or their mainframes are charging exorbitant rates. How much? I had a customer (non-gov) that paid a million$ a month to keep their product leased and up on their support agreement, that $12m a year without even talking about the costs of finding Cobol devs. Whos still using them? Any bureaucracy terrible enough to have not transitioned years (decades) ago.
Many places where COBOL survives, it survives because of at least one (sometimes more than one) mega-failure in which management spends tens of millions on replacing it with a new system written in Java/.NET/whatever, only for that replacement to turn into such a complete disaster that it ends up completely abandoned and the whole development cost written-off
This tends to be the case when you need a bug-for-bug re-implementation of the old program, but it isn't stated up front.
Sometimes implementations fail for essentially the opposite reason – the new system is too generic and insufficiently close to the original program. One place I worked (a university), they tried to replace their mainframe COBOL system (Fujitsu FACOM GS8400 mainframe [0] [1], along with Software AG's ADABAS database and some use of their Natural 4GL as well) with PeopleSoft Campus. However, PeopleSoft Campus was designed for the US market, and many of its features were rather irrelevant in Australia; conversely, key features needed to cope with Australia's rather different regulatory environment were lacking, forcing the project to reimplement large parts of the original COBOL system as add-on code. PeopleSoft sales (this was in the mid-to-late 1990s, so before Oracle bought them) had painted (whether by intention or ignorance) a fundamentally misleading picture of how suitable the product was for the Australian market. Eventually the whole project was written off as an expensive multi-million dollar failure, and the mainframe COBOL system got a reprieve on its execution. I was still in high school when it happened, but when I worked there several years later, the "PeopleSoft disaster" was a frequently repeated part of local institutional lore.
Then, they tried again with a competing system from a local Australian ERP firm (TechnologyOne), running on a Microsoft application stack and Oracle RDBMS; and this time they succeeded in replacing the mainframe COBOL system, in part because (unlike PeopleSoft) it was actually designed for the Australian market.
[0] https://www.fujitsu.com/au/about/corporate/history/products/...
[1] http://museum.ipsj.or.jp/en/computer/main/0088.html
Then, they tried again with a competing system from a local Australian ERP firm (TechnologyOne), running on a Microsoft application stack and Oracle RDBMS; and this time they succeeded in replacing the mainframe COBOL system, in part because (unlike PeopleSoft) it was actually designed for the Australian market.
[0] https://www.fujitsu.com/au/about/corporate/history/products/...
[1] http://museum.ipsj.or.jp/en/computer/main/0088.html
> the new system is too generic and insufficiently close to the original program
I may have been unclear, but this was the scenario I was describing. The need for a bug-for-bug re-implementation is a special case where the acceptable deviation from the original program is quite low.
I may have been unclear, but this was the scenario I was describing. The need for a bug-for-bug re-implementation is a special case where the acceptable deviation from the original program is quite low.
They didn’t need a bug for bug reimplementation. Their problem was they tried to replace it with COTS software which wasn’t properly localised for their market. That’s more commonly a problem for smaller markets such as Australia, and also a bigger problem in highly regulated sectors such as education and health, where you are forced to deal with all sorts of government regulations which can be rather specific to the sector and jurisdiction you are operating in. The other problem, which is a more common problem with COTS software, is it is easy to be given one impression during the sales process, but then only once you’ve bought it and have started spending money to implement it that you realise how wrong that impression was. I think the people buying it on the customer side were senior university executives (who almost always come from an academic background) and they didn’t have a good enough appreciation for the nuts and bolts of student administration systems-and senior executives being sold on something where they don’t understand the details enough to see why it won’t work is yet another common cause for these kinds of projects to fail.
Adabas and natural … those were the days my friends. Still have nightmare when it failed and have to fly in expert who actually does not know. …
I know of an insurance company that has tried 3-4 times at a cost probably in the hundreds of millions to switch off COBOL.
The simple fact is that they've spent tons of time slowly coding in hundreds of thousands of little, undocumented edge cases all over the place. The rewrite gets 90% there then falls flat with all the little things and you can't switch these kinds of businesses until it is 100% there.
The simple fact is that they've spent tons of time slowly coding in hundreds of thousands of little, undocumented edge cases all over the place. The rewrite gets 90% there then falls flat with all the little things and you can't switch these kinds of businesses until it is 100% there.
It's often worth looking at the business problem itself and see if it's possible to simplify it as to reduce the amount of edge-cases that need to be migrated. If you look at a typical legacy bank you'll see dozens of different credit cards with minor differences such as one charging fees for foreign transactions, etc. All of those are edge-cases that must be kept in code.
They presumably do this for market segmentation reasons, however if you account for the cost of 1) maintaining the old COBOL/mainframe system (as it's the only thing that's proven to successfully run those products) or 2) successfully moving all that business logic & edge-cases to a modern system, it could emerge that maintaining those different products costs more to operate/maintain that what it brings in terms of revenue from the market segmentation approach, and they're better off simplifying their product line. This also translates to other areas of the business - less support overhead, etc.
The other problem with ordering (and delivering) a successful migration is that a lot of people's jobs in those legacy companies rely on the tech being ancient and would be obsoleted should the tech get better, so there's a lot of internal pushback against this. A lot of people may not actually want the migration to succeed, or at least not to anything actually good as that would put paper-pushers out of a job.
The only way IMO to successfully deliver this as a large company is if the top brass effectively sets up a brand new subsidiary, gives it a budget and a task to make a product competitive with what the parent company offers, and when it's ready they can just move off their customers to that new product operated by the subsidiary. Rinse and repeat until no more legacy tech remains. The fact that it's a completely separate company means it remains lean and doesn't have to be fighting against deadweight that sabotages any modernisation attempts to protect their own jobs.
They presumably do this for market segmentation reasons, however if you account for the cost of 1) maintaining the old COBOL/mainframe system (as it's the only thing that's proven to successfully run those products) or 2) successfully moving all that business logic & edge-cases to a modern system, it could emerge that maintaining those different products costs more to operate/maintain that what it brings in terms of revenue from the market segmentation approach, and they're better off simplifying their product line. This also translates to other areas of the business - less support overhead, etc.
The other problem with ordering (and delivering) a successful migration is that a lot of people's jobs in those legacy companies rely on the tech being ancient and would be obsoleted should the tech get better, so there's a lot of internal pushback against this. A lot of people may not actually want the migration to succeed, or at least not to anything actually good as that would put paper-pushers out of a job.
The only way IMO to successfully deliver this as a large company is if the top brass effectively sets up a brand new subsidiary, gives it a budget and a task to make a product competitive with what the parent company offers, and when it's ready they can just move off their customers to that new product operated by the subsidiary. Rinse and repeat until no more legacy tech remains. The fact that it's a completely separate company means it remains lean and doesn't have to be fighting against deadweight that sabotages any modernisation attempts to protect their own jobs.
A lot (most? all?) of these "edge cases" end up handling regulatory or other forms of compliance, which came into effect after the initial software design. There might have been 10 people across as many teams who discussed, designed and vetted a one-line code change.
It's not so easy to "simplify" out features which are legal requirements.
It's not so easy to "simplify" out features which are legal requirements.
It sounds like, rather than a ground-up rewrite, COBOL should be treated as an object-code language, and "hand-decompiled" (ala efforts like https://github.com/n64decomp/sm64) into an HLL that can, at every point, be losslessly transpiled back into the original COBOL.
I know the tooling for doing that doesn't currently exist... but paying someone to develop it would be cheaper than any one of these ground-up rewrite projects!
I know the tooling for doing that doesn't currently exist... but paying someone to develop it would be cheaper than any one of these ground-up rewrite projects!
I'm not sure this would help - COBOL itself is already fairly readable.
The problem is that a program doesn't actually contain a full description of the business problem - it only contains what's necessary for the machine to solve the business problem. For example, the system may never be designed to process check deposits on a Sunday (and a lot of date-related calculations will go wrong if you tried to), but guarding against that is accomplished by the "real world" - there's nobody there to file in check deposit requests on those days. Yet, there's nothing explicit in the code about preventing check deposits on a Sunday, so your hypothetical decompiler will have no way to infer that without outside knowledge.
What you need is a hypothetical magical decompiler that given a binary or source code as input, will spit out the actual business problem and all the edge-cases it's meant to solve. AI might eventually get us very close to that, but ultimately it'll still be a guessing game.
The problem is that a program doesn't actually contain a full description of the business problem - it only contains what's necessary for the machine to solve the business problem. For example, the system may never be designed to process check deposits on a Sunday (and a lot of date-related calculations will go wrong if you tried to), but guarding against that is accomplished by the "real world" - there's nobody there to file in check deposit requests on those days. Yet, there's nothing explicit in the code about preventing check deposits on a Sunday, so your hypothetical decompiler will have no way to infer that without outside knowledge.
What you need is a hypothetical magical decompiler that given a binary or source code as input, will spit out the actual business problem and all the edge-cases it's meant to solve. AI might eventually get us very close to that, but ultimately it'll still be a guessing game.
It sounds like you're increasing the scope of the problem relative to what it needs to be. (And you're not alone: that's seemingly what every bigcorp who tries to do this does, and that's why they all fail.)
AFAICT the goal of such a translation effort should just be to replace a COBOL codebase that does X, with a codebase in a more-maintainable language that also does exactly X, in a bug-for-bug-compatible way. You don't need to know the business requirements that led to the implementation; you just need to take the existing implementation, with its embodied institutional knowledge, and blindly preserve that knowledge by not making any top-down assumptions about the requirements that would accidentally design it out, but instead preserving the bottom-up structure.
If you like, you can re-do the requirements analysis and top-down refactor the program later on — after you've already "decompiled" it into a workable HLL.
An analogy. Say there was an unfinished manuscript of a novel written in Old English. You want to have this published as a modern novel. You have two choices: either you — someone who presumably can read Old English — try to do a top-down rewrite of the manuscript into a modern-English novel, figuring out the plot and characters from the manuscript and copying that "design" to a new modern-English novel; or, you just translate the manuscript itself into modern English, sentence by sentence, and then, after you have now acquired a modern-English manuscript, set about turning that manuscript into a finished novel through the normal prose editing tools of structural editing and copyediting.
I think you can see how the former approach is pretty silly; and yet is exactly what people do when they attempt to build a new system from the ground up to replace a legacy system. The former approach severely limits the number of people who can understand+reference the old design when working on the new design, while the latter approach does not. The latter approach allows the "turns of phrase" of the old work to be reused as-is in the new work, while the former approach does not.
AFAICT the goal of such a translation effort should just be to replace a COBOL codebase that does X, with a codebase in a more-maintainable language that also does exactly X, in a bug-for-bug-compatible way. You don't need to know the business requirements that led to the implementation; you just need to take the existing implementation, with its embodied institutional knowledge, and blindly preserve that knowledge by not making any top-down assumptions about the requirements that would accidentally design it out, but instead preserving the bottom-up structure.
If you like, you can re-do the requirements analysis and top-down refactor the program later on — after you've already "decompiled" it into a workable HLL.
An analogy. Say there was an unfinished manuscript of a novel written in Old English. You want to have this published as a modern novel. You have two choices: either you — someone who presumably can read Old English — try to do a top-down rewrite of the manuscript into a modern-English novel, figuring out the plot and characters from the manuscript and copying that "design" to a new modern-English novel; or, you just translate the manuscript itself into modern English, sentence by sentence, and then, after you have now acquired a modern-English manuscript, set about turning that manuscript into a finished novel through the normal prose editing tools of structural editing and copyediting.
I think you can see how the former approach is pretty silly; and yet is exactly what people do when they attempt to build a new system from the ground up to replace a legacy system. The former approach severely limits the number of people who can understand+reference the old design when working on the new design, while the latter approach does not. The latter approach allows the "turns of phrase" of the old work to be reused as-is in the new work, while the former approach does not.
>The rewrite gets 90% there then falls flat with all the little things and you can't switch these kinds of businesses until it is 100% there.
Is it not possible to find a safe subset of cases that can be handled by a new codebase. You use shadow testing to help prove the rewrite handles the cases the same as the old implementation and then grow that subset until it encompasses the whole thing. As the old implementation is used less and less you can run it on a smaller computer and have to maintain it less.
Is it not possible to find a safe subset of cases that can be handled by a new codebase. You use shadow testing to help prove the rewrite handles the cases the same as the old implementation and then grow that subset until it encompasses the whole thing. As the old implementation is used less and less you can run it on a smaller computer and have to maintain it less.
It takes years or decades to do the swap. You’ll have both teams working in parallel all that time which costs the company a TON of money.
This process also outlasts aging managers. Chances are that leadership will shift at least once and decide it’s taking too long So they kill the replacement, switch languages and/or teams, and try yet again.
This process also outlasts aging managers. Chances are that leadership will shift at least once and decide it’s taking too long So they kill the replacement, switch languages and/or teams, and try yet again.
I wonder if second system effect looms large in the minds of those who are maintaining those COBOL programs. At least with a legacy program, you probably know that it can keep running for another year for a predictable cost. On the other hand, spinning up a scratch build of its replacement is potentially a black hole.
I've witnessed second system effect.
I've witnessed second system effect.
Banks, insurance companies, big old companies that have to do transaction processing, have old applications that have been running since the 1960s/70s, and are dependent on those applications just working until the sun goes out.
From what I can see even banks are starting to modernise things. I’m seeing banks advertise Rust positions recently as well as various other modern tech.
Banks have tons of things going on, I wouldn't take one (or even a hundred) job postings as indicative of a firm-wide shift in strategy. They could be using Rust for their phone app or their real-time ML fraud-detection system, while he checks are still processed by a piece of software whose source code is COBOL whose only extant copy was written by typewriter in 1975.
This isn't serious is it?!
I find it hard to believe banks are running critical code they didn't at least back up somewhere.
I also don't understand why it would be hard to back up the code.
I find it hard to believe banks are running critical code they didn't at least back up somewhere.
I also don't understand why it would be hard to back up the code.
Those systems are usually boring things that never get modified. Ledgers, etc. The tasks required to process checks are the same as they were in 1975. The inputs and outputs just changed.
Sometimes the COBOL isn’t the problem, it’s the scaffolding built around it. As an example, I worked in a consulting role on stabilizing systems during COVID that were getting crushed. The COBOL stuff on the mainframe wasn’t a problem - tweak the job control stuff, give IBM more money to lease more cpu time, and you’re good to go.
The problem is the 1995-2005 legacy middleware dreck that isn’t engineered well like a mainframe app and doesn’t scale. That stuff is always hot garbage and makes it difficult to replace the backend mainframe. The middleware expects whatever comes out of the mainframe, you end him with a chicken and egg scenario.
Financial services tend to have good data management practices and regulators who know how to audit for them. As a result are successful in getting off mainframes. Governments, manufacturers, etc, often struggle with that.
Sometimes the COBOL isn’t the problem, it’s the scaffolding built around it. As an example, I worked in a consulting role on stabilizing systems during COVID that were getting crushed. The COBOL stuff on the mainframe wasn’t a problem - tweak the job control stuff, give IBM more money to lease more cpu time, and you’re good to go.
The problem is the 1995-2005 legacy middleware dreck that isn’t engineered well like a mainframe app and doesn’t scale. That stuff is always hot garbage and makes it difficult to replace the backend mainframe. The middleware expects whatever comes out of the mainframe, you end him with a chicken and egg scenario.
Financial services tend to have good data management practices and regulators who know how to audit for them. As a result are successful in getting off mainframes. Governments, manufacturers, etc, often struggle with that.
I can't tell you how common it was or is, but I can tell you that I worked with at least two banks in Europe in the early 2000s that were rewriting core transaction processing and routing systems that were originally written in COBOL, and for which they had lost the source code. They patched the systems when necessary by patching the object code in assembler. The systems were 30 odd years old at the time. Nobody seemed to be able to explain how the source code was lost, other than that it had something to do with corporate mergers and acquisitions. The fact that they were spending millions to rewrite them was an indication of unsatisfactory they found the situation to be.
> They patched the systems when necessary by patching the object code in assembler.
If that sort of development can't force a rewrite then nothing will.
If that sort of development can't force a rewrite then nothing will.
When it was last compiled from source, the source was punched cards. They were placed in a file somewhere and ended up either getting thrown out as part of a data retention move or shipped off to Iron Mountain to be lost among billions of other boxes.
Version control practices have changed a lot since the 70s. It's possible the code has actually been lost. Or, more likely, the version that actually runs has been lost. Some code still exists (or existed), but how exactly it differs isn't exactly known, and deploying it would require getting a higher up to sign off on, essentially, unbounded risk for their critical systems (they will never do this).
If that happened in the 80s or 90s the code that exists has probably diverged enough that it's effectively pseudocode at this point.
If that happened in the 80s or 90s the code that exists has probably diverged enough that it's effectively pseudocode at this point.
I'm sure they do, but decent version on some of these ancient systems would be... challenging. I've worked at a company that uses some pretty ancient hardware (emulated these days) for which I think there is a git client, but I don't think it works so well, so they used some equally ancient version control system.
hopefully that's the case. I have seen some that are too afraid to change it in case something breaks. They then wrap the core cobol system in many layers of java to provide a more friendly interface to external modules.
The phone company, irs, local utility, etc. any large business that was in operation 60+ years ago?
For better or for worse, the IRS is probably the worst ambassador for COBOL.
Their COBOL stuff is positively modern when compared to the oldest part of the IRS stack, which is written in IBM 7074 assembly - that’s IBM’s pre-S/360 business mainframe line, from the early 1960s. It runs under an emulator on contemporary IBM mainframes.
(I know IRS has been working on rewriting it all - the 7074 assembly, the 360/370 assembly, and the COBOL - in newer languages such as Java. I don’t know where they are up to with that, so I don’t know if they still have 7074 apps live today. But certainly they did as recently as 4-5 years ago.)
(I know IRS has been working on rewriting it all - the 7074 assembly, the 360/370 assembly, and the COBOL - in newer languages such as Java. I don’t know where they are up to with that, so I don’t know if they still have 7074 apps live today. But certainly they did as recently as 4-5 years ago.)
I believe you - it's more the perception of how backwards and dysfunctional the IRS seems to operate.
I've never worked at a company that uses it (though I've worked somewhere with lots of very important Fortran) though I know someone who worked at a place with COBOL.
But as others have said, banks and other large companies that started using computers a long time ago would have critical services written in COBOL.
But as others have said, banks and other large companies that started using computers a long time ago would have critical services written in COBOL.
I maintain COBOL systems for a large department of the Australian Government. The new code and UI are in midrange Java, but older parts and especially batch processing including generating correspondence is done on the mainframe.
In France I've some friends who got COBOL jobs almost right out of school, around 2014-2015
Same in Canada, around 2017-18. My college program actually had several mainframe development with COBOL courses which were very interesting.
I've noticed it at older large companies. banks, oil companies that sort of thing.
Obligatory: the T-800 is running on COBOL [1].
[1]: https://old.reddit.com/r/programming/comments/cd1g2/the_term...
[1]: https://old.reddit.com/r/programming/comments/cd1g2/the_term...
The second thing in my list after performing silly job interview is to send an unsolicited cobol implementation of a test task at some stage of a hiring process and later on an actual interview pretend that nothing special is happening.
A friend of mine got a job programming RPG IV on mainframes in 2022 (!).
The RPG language PREDATES Cobol! [0] https://en.wikipedia.org/wiki/IBM_RPG
The RPG language PREDATES Cobol! [0] https://en.wikipedia.org/wiki/IBM_RPG
I know "mainframe" is ambivalent but RPG was introduced and used with IBM's midrange line ie. I-Series aka AS/400; so not "mainframe" IMO, and the IBM proprietary non-COBOL language on "mainframes" aka z-Series running MVS would be PL/1.
It says right there on the wikipedia enttry it was introduced in 1959, which was before AS/400.
For me a more interesting question would "What is the geographical or national distribution of COBOL around the world.". It seems that most people's comments refer to COBOL used in the US.
Could Python be used to re-build a banking mainframe written in COBOL?
COBOL has a lot of built in business and CRUD idioms that would require fairly large Python libraries to reinvent. COBOL is a domain-specific-language and Python isn't.
you could rebuild it in any turing-complete language, including Brainfuck.
But why would you do that? I suspect there’s few good reasons for doing it (ease of finding new programmers) and many good reasons not to do it (speed, it’s code that has been battle-tested for ages).
Anyway, from friends working in the banking sector, nowadays the mainframe code is exposing an API and users are accessing data via a web interface and not a terminal emulator anymore.
But why would you do that? I suspect there’s few good reasons for doing it (ease of finding new programmers) and many good reasons not to do it (speed, it’s code that has been battle-tested for ages).
Anyway, from friends working in the banking sector, nowadays the mainframe code is exposing an API and users are accessing data via a web interface and not a terminal emulator anymore.
Find the dot!
I ended up going to neither and went to a traditional CS undergrad at a 4 year state school, and things have been fine ever since. However, on a regular basis, I think about the other life I would have had, if instead I had gotten an associate's in mainframe programming. What would I have done? Where would I have worked? Who even are those folks.
If today I found a COBOL bootcamp that reskilled developers for a career change into COBOL, i may even seriously consider it. An unexplored path that has always been in the back of my head, deep in the guts of the engines of industry.