The problem is that very few people are interested in learning COBOL these days. Coding it is cumbersome, it reads like an English lesson (too much typing), the coding format is meticulous and inflexible, and it takes far longer to compile than its competitors. And since nobody’s learning it anymore, programmers who can work with and maintain all that code are a increasingly hard to find. Many of these “COBOL cowboys” are aging out of the workforce, and replacements are in short supply.
This puts us in a tricky predicament. We need to maintain and modernize the code that underpins so much of the business and finance worlds, but we don’t have enough skilled workers we need to carry out those updates.
This is precisely the kind of problem that IBM thinks it can fix with AI.
↫ JD Sartain for PCMag
It seems like learning and getting good at COBOL is a surefire way to ensure job security. I wonder if there’s a way to make modern applications or software in COBOL? I mean, there are COBOL compilers for modern platforms, of course, but are there any bindings (I think that’s the correct term?) for modern GUI toolkits like GTK, Qt, and so on?
The headline’s probably a bit hyperbolic, but the core of the issue stands.
Sure, there’s job security, but not flexibility of location. You’d be stuck working in the middle of nowhere for one of the few companies refusing to replace their ancient software, and those companies probably talk to each other enough to prevent poaching talent.
As for GUI plus Cobol, I doubt it. Each COBOL instruction matches up with its punch card (that’s right, those ancient things.) Not a language designed to be called into like a modern object oriented GUI app.
Finally, anytime I read “shortage of skilled tech workers” for programming I know it’s pure bullshit. Almost always equates to fishing for H1-B visas because they don’t train fresh college grads anymore. Need that captive labor.
dark2,
Yeah, they say this in one breath and then execute layoffs in another, haha.The truth is the labor is there, but the incentives have gotten worse. In decades past employers would be paying for college and whatnot whereas employers today expect employees to pay for their own educations to the tune of 100k+ for jobs that can be and often are outsourced. 🙁
https://www.forbes.com/sites/timworstall/2016/03/25/new-york-firm-fine-3-million-for-outsourcing-to-india-but-look-at-the-cost-of-not-outsourcing/?sh=12506d23298d</
BTW this outsourcing has effected me personally on mainframe jobs no less.
I work at a large financial company that runs many applications in COBOL. The solution is outsourcing. We have many COBOL developers in India. There does not seem to be a shortage of Indian developers who know COBOL. It would take a while before large financial applications can be written with AI. Not holding my breath.
Yeah, I mean this is the truth here. I’m not against outsourcing per say, but In addition to cobol not being any fun to write, The writing was on the wall for the future 30 years ago, it was going to India. There was no career for a new COBOL developer. COBOL was created/advertised as “simpler” without all of those confusing mathematical symbols only Nuclear Physicists could understand like “=” , “+”, and “-“. All of the introductory material on it just straight up insulted anyone’s intelligence. Having said, that there are some really, really nice features for working with money built in, and taught early that make some common mistakes in other languages almost not possible. Other languages have data structures for currency, but for some reason novice developers never use them and just grab a float : cry:
Lots of great overseas options, where someone will pick up a Red Book and read it cover to cover. Because it’s a well paying job. Thanks to ChatGPT, US developers don’t even want to bother reading a one paragraph Stack Overflow response.
Even if there is, don’t.
I love fiddling with COBOL still in my spare time on my VMS systems. I still maintain some software for a friends small business. Haven’t seen a job though locally in .au for a long time.
While they’re not my responsibility to run beyond the platform, I run into a lot of Pick systems (basic-driven multivalue database systems) still around, of various stripes. That’s the same systems that used to underpin the old Dymo library systems, the old green and orange terminals.
The1stImmortal,
You still run into those? Haha, I’ve only heard about those.
it’s ironic that older databases supported this while SQL doesn’t. It’s often something I find limiting with SQL. The closest SQL comes to this is storing CSV (or something similar), but that brings up problems searching/indexing/etc.
https://en.wikipedia.org/wiki/MultiValue_database
Of course the idea behind relational databases is to link different tables together, but it’s nowhere near as efficient when we’ve got production queries having to join dozens of tables together.
I’m also in the same situation. I love to go back to program with COBOL from time to time when I need to do some modifications of a software I maintain for a pair of small companies. I often found myself with a smile in my face every time I program with COBOL.
The software is graphical and uses AcuCOBOL-GT with a thingy called Thin Client that you install on each PC Windows and so multiple users can interact with the same application in fully graphical mode hosted in a Linux server. Even more, depending on the Runtime, you can interact with the same application in text or graphical mode.
Thom Holwerda,
Well, keep in mind that mainframes are essentially a remote environment and that “nobody” is running mainframes on the desktop.
Even if you were developing GTK/QT front ends, in practice these would technically be running on normal desktop platforms like windows and linux without the need for cobol.
So the mainframe UI innovation, to the extent that we want to call it that, has been replacing 3270 screens with more modernized protocols, this often means web enabling them with javascript/HTML. The commercial solutions either did this by translating the 3270 data stream or finding new ways to process the BMS maps that make up the source for such screens. Incidentally this is exactly what our company was doing. This works well enough but the end result is that the HTML interface and the screenscreen interface, while being visually different, still have a 1:1 relationship to each other. If you wanted to add new functionality (or more data than was present on the green screen), then you need to change the underlying cobal application and/or add more automation logic in front of it.
Most COBOL programs on mainframes don’t have traditional GUIs. They are designed to process data in non-interactive manners. Modern COBOL does have API to interface with JSON and web servers. COBOL either runs in non-interactive batch, or in application servers like CICS. When COBOL does interact with people it is still mostly through 3270 emulators.
Something I find odd about how COBOL processes data is that huge amounts of data is processed as flat files, not databases. COBOL and mainframes pre-date relational databases and still process data as they did before relational databases became popular.
Yeah, its faster/more efficient to handle batch operations the way COBOL does it for sure. Relational databases are better at handling real time requests and more flexible for querying.
Bill Shooter of Bul,
Those learning mainframe programming for the first time after having come from linux/windows programming will undoubtedly be shocked at how primitive things are. This isn’t necessarily a bad thing, it’s just that you are programming with technology that predated many of the abstractions we use elsewhere. For example, most mainframe programmers are experienced at reading raw data from vsam files and even recognizing ones-compliment numbers and dates because storage & encoding details aren’t abstracted as they are for SQL programmers, etc. Binary encodings are rather unusual, even numbers tend to be represented as base 10 EBCDIC characters because that’s how they would be input on punch cards.
VSAM isn’t a totally flat file. For example, you can lock rows for transactions. And you can search on indexes. You can also keep multiple versions of a master file around, meaning you can “reset” and re-run a batch update if there’s a problem. Can’t really do that with SQL tables. But it’s less flexible and doesn’t play well with others, like DB2 does.
Okay, let’s take that apart a little. What does a “modern” application mean? When you look at the transactions that run through mainframes there’s often nothing “not modern” about them. There are plenty of aspects of running on mainframes which are very ‘modern,’ like virtualization or hitting 5+ 9’s of availability at very tight SLAs, something micro-services and kubernetes deployments struggle with. You can run Java and other “modern” languages on a mainframe. Even Linux VMs.
No one’s using it? Not true. They total volume of COBOL running is growing year to year. Maybe not as fast as the number of lines in your pod yaml, but it’s definitely not shrinking. And if you bought something today using a credit card, or had a mortgage, or insurance, bought a stock, added to your 401k, paid taxes, or booked a flight, or many other things, chances are your transaction was routed through a mainframe to check your credit limits, check for fraud, notify partner companies, etc.
As far as “too much typing,” that’s frankly a bullshit excuse. COBOL is verbose because it’s a DSL for business transactions and it was developed in different era, but for what it is, it’s very arguably an almost singularly effective language. For example, most languages don’t bother with a fixed decimal type for money amounts. They allow you to type a little less, but you’re off by pennies on a regular basis? Millions of transactions a day – that adds up. Sometimes code needs to be audited by non-programmers for audit or legal compliance. COBOL is verbose in the right way that you can walk someone through it.
But COBOL programming on the mainframe is maybe 25% language, 50% libraries like CICS/VSAM/DB2/MQ, and 25% knowing how to run things on mainframes (JCL, ISPF, security, etc.) The only real way to get this knowledge on a mainframe. They’re not free. They’re not cheap. Few schools even have one, much the less teach students how to use it. That means you need to get trained by the company you’re going to work for. Which means you’ll get hired off after a year by another company that’s willing to pay you for your experience and training. You can ‘rent’ a cloud mainframe at something like $8 an hour. Courses are thousands of dollars for a week of training, and might not even have a mainframe account for you to practice on. (They assume you have one at work). And finally, there is a lot of evidence that being a mainframe COBOL programmer with 10 years experience does not pay as well as a Java programmer with 10 years experience. The fact it costs a company money to train you for a less remunerative job (which you will likely leave for a slightly better paying job) is the fundamental economic reason why the US is getting out of the COBOL programming business.
ipaul,
IBM has certainly added things like GNU & linux to the mainframe, “hey some of my skills carry over”, and indeed mainframes are known for reliability. However I’d say the vast majority of companies running mainframes are using them for legacy applications first and foremost. While they can run modern linux on them, it’s not very economical to use mainframes for that except in an ancillary capacity. Mainframes (and mainframe time) can be so expensive that some companies don’t even have adequate test environments, and/or they are painfully slow. I’ve suffered through this several times. So while in theory you can run “modern” environments on the mainframe, most companies will actually use separate dedicated servers for that…many mainframe shops build front ends on windows/.net or unix/java machines.
There’s trillions of lines of code written in cobol, and when new tax or medical laws, etc, come down the pipeline those systems have to be updated. But I think there are very few companies building new applications on mainframe.
People seem to be assuming mainframe jobs are safe, but I know whole departments that have gotten laid off and had to find new jobs, partly due to modernization, and partly due to offshoring. Granted there’s still a lot of code to maintain, and new positions open up as people retire. But on the whole IMHO it’s not a good career to be investing in if the training will be on your own dime.
The tough part to get across is that there are economic reasons why there are few new mainframe programmers in the US, not technical reasons. Or, an absence of work. Or that COBOL is complicated. But there are plenty of talented folks across Eastern Europe through Asia, for whom the economic model makes sense. And that’s where that work is migrating, or has already migrated. Until the economics change, a kid fresh out of school is better of learning pretty much anything else.
ipaul,
The mainframe jobs are only plentiful in the sense that so few are being trained to fill them. But I think it would be easy for schools to over-saturate their market with mainframe programmers. They wouldn’t find jobs without moving away. Cutting edge tech companies don’t use mainframes for that work. Small/medium businesses that broadly need tech workers generally don’t want mainframes or mainframe programmers. Most startups will never use a mainframe. It’s mostly the domain of giants from last century running legacy code and even some of them are gradually replacing mainframes. The need for mainframe workers is mostly to replace older workers who are retiring and not because there’s that much growth potential.
Yes I’d agree. These same economic motives are pushing many companies to offshore jobs, including mainframes. Most of the work in my field gets outsourced to India these days because it costs less to hire employees/contractors in India than it does here.
You can learn the basics of the language for free on most common systems.
https://gnucobol.sourceforge.io