So for those who don't know, Microfocus is a retirement home for technologies that need to be taken out behind the barn and shot but can't be because there are like 3 major customers out there that have a Microfocus product as a core part of their organizational structure and can't move away from it.
That being said my understanding has always been that learning COBOL was never the hard part, the hard part was always that it's not just COBOL it's learning the mainframe it runs on, and learning the JCL that is associated, and a dozen other pieces of finicky technology.
In addition, I think the common saying “COBOL pays well, they are running out of COBOL devs!” is misrepresenting the issue.
I heard this on HN, so this hearsay itself, but I believe it’s not that these companies can’t find people that can learn COBOL, it’s that there are people with 30+ years of COBOL experience on their codebase.
The COBOL job security comes from being the only person who knows the codebase, not that somehow people can’t learn COBOL.
I worked at a finance company that still has a lot of cobol devs (cobol, jcl, db2) and they usually made less than the web / cloud devs given same seniority. There were plenty of contractors ready to step in and fill slots.
I think this meme has a lot of caveats. There are some banks running very very specific old versions of mainframes and databases and thus need expertise, so they are paying high emergency consultant fees for the few with that expertise. The average developer is better off learning aws and python.
We have an oversaturation of devs. There are no issues in hiring. If there ever becomes real issues then tech corps will actually spend money on education.
>If there ever becomes real issues then tech corps will actually spend money on education.
are the systems so mission critical and complex that it's cheaper to spend money training devs on the system than it is to have the existing ones start to migrate the codebase to anything else?
COBOL code that has been working since the 60s is a lot more safe than new code would be. If it is commission critical and complex, keep it in COBOL where it works and pay lots of cash for additional features.
Rather then migrate it over in hopes you don’t have to pay for training, but then deal with tons of risk of systems breaking that haven’t broken in 50+ years.
You may have to define "cheaper" for some of these companies.
Keep in mind the sunk cost fallacy and that every million dollars invested in 1960s money is about ten million dollars in today's money. Some of these projects are so foundationally sunk cost to these companies that they might as well be load bearing sunk costs. The company doesn't think that it exists without those sunk costs, and the company doesn't think it could survive a second, similar spending program today, at least not without their shareholders pitching a fit in potentially lots of short-term quarters given current shareholder obsessively short-term thinking.
I learned a little bit of COBOL when I worked in a finance company, just to help on call stuff. And I think you’re right. Learning COBOL the language is easy. It’s just an imperative language with no fancy constructs. But jcl and the specifics of db2 and mainframes, and also the weird terminal emulator you need to use to work with them is the hard part. Java is 100x more complicated than cobol, but mainframes and the surrounding infrastructure are very alien compared to todays stuff.
I can't speak for many of their products, but I thought the compiler tooling (back in the 90s) was great. Either cross-develop from PC (OS/2, Win NT) targeting mainframe emulation, or compile natively running even Win32 GUI apps with recursive calls. Ignoring that COBOL syntax is verbose, it seemed almost like a normal runtime.
I'm surprised that the guys worried about one or more "collapses" aren't more into COBOL. Because when something heavy and hard hits, all that's left will be roaches, COBOL and Perl scripts.
But seriously, I bought some old COBOL books recently, and was meaning to get more into it. Not because of some job situation, but it seemed different enough, in a "cozy" manner. I could get away from the Algol-ish day job languages with something blatantly more concise (extremely functional, esolangs or APL), but that's more the "puzzle" aspect where COBOL might be more the "knitting" approach.
COBOL runs on mainframes, which need clean power, air conditioner, filtered air, and on-call support engineers. Those things will disappear first under any sort of collapse.
If any sort of collapse hits, the popular programming jobs would be either old PCs (of which there are tons around, and which have tons of replacement parts); or repurposing old cellphones into something else (again, sheer number of things); or something super simple like 6502.
One of the reasons that Cobol is still so popular is because of banking products like Tata Consultancy's BANCS. If you're starting up a new Bank and need an off the shelf, secure and robust banking system, then TCS BANCS is a viable option. It comes with TCS support and dedicated developers, to implement new features or customize existing ones at a premium.
Cobol is powerful when it comes to batch jobs, and you can bundle transactions ( ie. TX1900 means execute this transactions, which consists of 10 other transactions that will create a new client, and open a savings account, etc). Your front end can be whatever you want and all your business logic is embedded into Cobol transactions.
The con however, is that these consultancy companies do not share these transactions with their clients or external developers. You'll either have to figure it out on your own ( good luck ), or use the consultancy company. These products are really cash cows for their vendors.
There are _many_ other off the shelf core banking systems - some are more modern and cloud first (Mambu) and others more direct competitors to BANCS (Flexcube, Finacle, Temenos). I don't think many of them are Cobol/mainframe based.
My (uninformed) perception is that 30% of the (apparent) complexity of COBOL is due to its verbosity, some 40% of (self-inflicted) due to brainded/outdated APIs (wanna write a binary file? lol no, you have to pretend it's a report, because that's all people that wear a tie know) and the rest is due to you having 20 jobs stepping on each others toes in the same system instead of a consistent data path
So job 1 reads your data and does light processing (good) job 2 turns it into a CSV of weird codes and turns BCD straight into base-10 digits integers (huh), job 3 then reconverts this back and joins this with more DB data and finally saves that data (split into every 12 customers) into a file with a sequential file name based on week number and current time in US Central time zone (but the system is in Germany)
I used COBOL for maybe 5 years (roughly from 1988 to 1993).
The language is not complex at all, but as you correctly point out it is verbose. And handling variables is quite tedious.
It can work more or less fine if you couple it with a RDBMS, but if you are instead using IBM files and job scheduling/control you add another layer of stuff to learn. Again, more tedious than esoteric.
I would not enjoy going back to it, probably (in any case I am not really writing code anymore in my current position) but if it was the only alternative to starving I would have no big qualms picking it up again.
Is there still demand?
Is it better paid? There's a German website where you can compare average hourly rates for different programming languages and according to this COBOL developers get lower than average. This might not be significant, but does someone know how the situation is globally/in the US?
If that's the mean, I wonder what the median would be – I wonder whether, for example, people with million-dollar salaries are being counted for other languages.
same, semantically the language is not complicated, the syntax is a verbose (as designed) and funny at times (the famous `pic X(...)`) but it's the legacy that kills.
people make it a rite of passage to give some horrible cobol code to interns for a few hours just to scar their soul a little
Does anyone want to comment on why COBOL has a reputation of being good for critical stuff? Are there technical reasons for this, or is that just branding?
its not so much COBOL, its the mainframe environment that is brilliant for critical stuff. My company migrates mainframe applications to the cloud so we find all kinds of reasons for clients to move, cost/skills/scalability etc but the mainframe is a highly optimized platform for running mission critical applications. Its a different model 1 platform 99.9999% uptime vs the distributed cloud approach where you can have failures on any particular node. A lot of other stuff on the public cloud replicates and is inspired by the mainframe.
It isn't, but rewrites are always percieved as being more dangerous than incremental change. So you get systems with 50 years of incremental change on them.
The "old" language which actually might deserve the "good for critical stuff" reputation is ADA.
Not COBOL itself, but Mainframes/Z systems are known for their high availability/reliability. Mainframes have many hardware redundancies that help contribute to their fantastic uptimes, despite being a single unit. One might ask why a distributed system wouldn’t be better, which is a fair question. It really depends on what you are doing. This is where the CAP theorem comes into play. For situations where data consistency is a must, mainframes are a good fit. If you look at some of the notable examples of where mainframes are used, such as VISA transactions or banking, you'll see that data consistency is critical in these situations. Building a comparable distributed system would not be an easy feat.
Mainframes, especially modern ones, are pretty cool imo. The obvious downside is the high cost, which makes them very unappealing for startups.
The impression I get in some cases, is less that it's the best choice, but more that a lot of companies have decades of data or systems all inter operating with it, and migrating things to something modern would be a nightmare but they can't afford to lose the data.
Typical COBOL has no unit tests, no version control, and no "dev" environments, while handling millions of dollars. Touching this stuff is scary.
So if you are (say) IT director in the bank, and you value your career, you should reject all attempt to modernize, as all failures would be blamed on you. Just say something about COBOL being most reliable and ask for more budget for contractors.
Maybe simply because some critical stuff currently runs on COBOL. So it has stood the test of time. There may be languages/tech that would be just as good or better, but we know that COBOL can do the job.
Yeah, I think there's definitely a lot of survivorship bias involved. COBOL was IBM's biggest suggestion at the height of IBM selling every business that they needed a mainframe to run their core business. For a brief era "every company ran on COBOL [on IBM mainframes]" and those programs were core to a lot of those companies' success stories. As computers moved on, the programs that survived in COBOL were already critical to business success. Every decade fewer COBOL programs survive, leaving only the "critical" ones left. Tautologically that survivorship sometime implies that COBOL itself was a key ingredient that made them critical programs, but mostly they are just critical programs because they survived that test of time.
There were multiple calls in the pandemic to support COBOL mainframes from the new jersey government[1] because the unemployment system was not functioning well. A lot of (older) people volunteered for it.
I work for an investment bank and we still upgrade COBOL to the new version every couple of years, surprisingly it's still actively maintained and getting updates. Sometimes I like to sit behind one of the mainframe grandpas and watch him work on his 16-colors 24x80 characters IBM Host On-Demand terminal, it's very calming.
Absolutely, MicroFocus wants to be kings in this space.
If one wants to learn I'd usually suggest the yearly Master the Mainframe by IBM, but I'm not sure they are running one this year.
If you want to work with cobol you'll probably be dropped on a Z/OS or AS400 machine or some OS owned by HP and that's what you'll spend 99% of your time learning.
I haven't seriously programmed in COBOL for 30-40 years.
But, having said that, I can pick up a COBOL program and by reading it, I will know what it does and almost certainly how it does that.
That can not be said for several other programming languages I have used. One of COBOL's criteria during its development was that it should be READABLE. It is.
If anyone could do it, they can. I took both semesters at once, cause I already knew it, did both the final programs months before due, and did not bother to show up for the last month. The teacher called me I the lab... The only one who ever did, and asked me if I was going to attend the final, I answered that I had already receved enough
Points to get my A, but if he needed help to grade papers or programs I would help. How did I get a 1400 line program typed in one day? I used the card duplicator, and only had to type in about 190 lines - while the lab assistants would come into complain about the rattling noise.
I wrote the program in the turbo pascal editor Setline numbering and then sorted it by colums. I tested it with microfocus, and it showed one bug and two typos. On to the card punch and the IBM compiler, and the IBM line printer. Finished In time to clean my card punch completely. It was the end for the card punches, and COBOL. Over the next few semesters a lot of people asked how I did the last program I one day, and I just showed them the column sort of the listing. You either wondered what use it was or you thought it was evil. The code was elegant...
Back in the 80's I had to learn me some COBOL as part of a college course. Obviously nostalgia (now) and inexperience (then) are involved, but I actually quite enjoyed it.
At the time the other stuff I was learning involved Pascal on VMS and DBase II on an 8086, so it was all great fun.
I advised someone designing a logo for a new remix a couple of years ago. (I've left the community due to toxic hostile newbies, but I still use the software.)
They had no idea that the Ubuntu logo was meant to represent something, let alone that it had a name ("the circle of friends").
> There are 800 billion lines of COBOL code out there supporting today’s mission critical business applications. That means one terrific opportunity for you.
(I'm a System Engineer, not a programmer) - Don't you need to understand a language, to understand a program, in order to be able to rewrite it to a different language?
I'm a native spanish speaker. When I hear Italian or Portuguese I can understand most of it, butnI wouldn't be able to formulate a proper sentence.
The same happens with programming language, you can get the semantic without knowing the syntax just because you know how to program, and of course, you can read specific syntax documentation (the dictionary) when something is not clear.
So I've just spent some time looking into this - there are Cobol compilers that target JVM and .NET. GnuCOBOL compiles to C too.
Apparently 80% of all bank transactions and 95% of all ATM transactions in America are still running COBOL, as is the Social Security Administration and DoD's finance systems (https://www.youtube.com/watch?v=TBs7HXI76yU)
I work at a place where they use this for running legacy, but quite profitable, trading and payment systems. These were ported from both AS400 and mainframe alike and currently run on Microfocus on regular windows VMs on our internal cloud platform.
I've always had the impression that they run on huge room sized mainframes in the bowels of banks and airline infrastructure but I have no idea how accurate that is today.
well they still run on the mainframe, many of which can sit under your desk nowadays like a standard tower.
but there is a whole industry about replatforming and refactoring these apps to modern infrastructure and software stacks.
In a word no. There is a place for LLM in mainframe migrations but it is not in source code transpilation.
COBOL (or PL/1) to any other language is a deterministic problem, imagine transpiling millions of line of code and every time you run the compiler you get slightly different output...
Anyway transpiling from one language to another ie COBOL to java is almost the easy bit, the hard bit is making the behavior and execution correct, especially when there are multiple OS and product services that don't exist outside the mainframe.
disclosure I am CTO of heirloom computing, we migrate mainframe applications to the cloud.
well i spend all my time moving people and applications off the mainframe so probably not the best person to ask, however a quick google of mainframe jobs showed up 100's (for experienced people). I have heard some large companies are instituting their own training programs for hew hires but i have no details.
That being said my understanding has always been that learning COBOL was never the hard part, the hard part was always that it's not just COBOL it's learning the mainframe it runs on, and learning the JCL that is associated, and a dozen other pieces of finicky technology.
Someone feel free to correct me if I'm wrong.