This makes me think of the mechanical workings of Earth’s life support system, endlessly turning poop into clean water for millions of years. CO2 into breathable air, sunshine into food.
…and a bunch of bored yahoos come in and start tearing it apart because it’s not making them any money. But don’t worry, we’ll be able to invent a way to suck carbon out of the atmosphere that doesn’t emit more carbon than it sequesters! … eventually…
But how many layers of emulation is the code running under? (That used to be a thing even back in the day, when rather than update the code for a new environment and QA it, it was safer to leave it alone and slide in another generation of emulation.)
There is a hefty level of bullshit in that pronouncement that all this COBOL code has been thoroughly debugged.
Some years ago, I worked on a data warehousing project, taking nightly data dumps from the mainframe and putting it into a SQL Server database on a modern PC network to allow reporting and import into Microsoft Dynamics, for financial queries and accounts and balance reporting.
At one point, while running the system, the business people came to us saying they found significant differences in the mainframe accounting data and the Dynamics reports. They were certain we screwed up!
We dug into in, tracing all the information logged during the import process. No differences.
Digging into our code vs the mainframe code, we discovered significant errors in the COBOL business logic (mostly complex if blocks that didn’t implement any handling for “and it none of those match, then…”, that just threw the transaction away, and a bunch of little “backdoors” that various data entry forms used to allow transactions to be edited after entry without any corresponding audit trail.
To sum up, once the errors in the COBOL code were fixed and the backdoors closed, the mainframe started reporting the financials accurately…for the first time in 20 years.
Just because we’ve been using code for years doesn’t mean it’s right.
the ibm z is still going strong.
it supports cobol, and is very pretty.
according to it’s spec sheet, it can run up tp 2.4 million Linux containers simultaneously. ( i know containers aren’t quite the same as full machine virtualization – but still. )
This. Any programmer can learn a new language, it’s all the other systems expertise that takes years to understand and internalize and these are archaic systems to boot. Very well stated in your post.
COBOL is still evolving; there are 1985, 2002, and 2014 standards.
Gnu COBOL is actually a thing, if you have need for COBOL or want to get your feet wet. I don’t have any COBOL source code to play around with, though.
I haven’t written a line of COBOL since junior college (mid-1980s). None of my jobs have ever required it, and I’ve also never worked on a mainframe; my high school had a PDP-11 and the junior college had a Prime. When I transferred to a big school, every significant system used in my class work ran UNIX, which I took to like a duck to water.
In the late 70s and in the 80s accounting high school, where one learned to do accounting, economics, finance, business administration, marketing, touch typing and so on, started to add courses of accountant programming, where the programming languages were COBOL and BASIC. Basically all the background on bookkeeping made manually was teach along with the language and how to operate a computer.
And having some field knowledge is useful to understand better the problem.
As a side effect most of COBOL programmers were girls, 'cause accounting was for girl, technical engineering was for boys.
Or after a Cambridge comedy group named after a snake, really
Yeah, if an organisation is still using software which no one has been able to maintain for decades, my first thought is not “wow! It must be so robust!”. What it says to me is that the system overall is so brittle that it collapses when anyone tries to change anything.
As for old COBOL software embodying valuable business knowledge, I am sure that’s true. But another way to put that would be, “half our operations manual is only written down in a language none of us can read”. This is why the whole evolution of business software has been a futile search for a paradigm that lets managers understand what their software is doing. The problem was never programmers not understanding the code (even if it’s in an unfamiliar language, which might take all of a week to learn).
So, I don’t believe for a moment there’s anything special about COBOL itself. The real lost wisdom is that IT for organisations is about the organisation, not the technology. The drive to encapsulate software so “normal” people don’t have to understand it is an epic misadventure, like thinking you can run an oil refinery without knowing how pipes work.
Since the very early days of microservices people said that this architecture is not a silver bullet. For many monoliths it’s a better idea to split it into several SCSs, and then see if micro services are worth the extra effort.
Organizations fail at micro services mostly because they don’t create the communication structure required for that architecture (see Conway’s Law).
Hope I’m not too late to the party to tell one of my favorite computer science jokes!
Have you heard about the new object-oriented COBOL? They’re calling it ADD 1 TO COBOL GIVING COBOL!
…debugged 20yr old COBOL code?
SCNR, but you seem to describe exactly that. Thoroughly debugging code 20 years later seems to be a reason why it still runs, when nobody comes up with a better solution. Or the hassle to get rid of it would be to great.
Not sure about the software (I wrote in COBOL in the 60s, PL/I in the 70s, C in the 80s, Obj-C in the 90s, Python since the 2000’s and frankly its all just syntax, the important thing is to understand what you are trying to accomplish), but ALL NEW MUSIC IS INDEED TRASH COMPARED TO THE GREATEST HITS FROM BACK IN THE DAY (1960s!) LOL!
NIce, it’s been close to ten years since I worked any system that either interfaced or was to replace a cobol system. When I would ask why are we replacing the cobol systems? the answer was most often answer was “the hardware can’t be replaced”. Seemed ridiculous to me then but you know I was getting paid to write java code to replace it so who was I to argue?
This is my career & has been since 1997. When COVID-related unemployment really started hitting in late March to early April, we were handling it. It was the server-based telephone/Internet interfaces that were crashing.
That being said, IBM did come in to do two emergency CPU upgrades and we did struggle a bit with some capacity issues, but it was never COBOL that was the problem, and we always got our unemployment insurance (UI) payments out on time.
COBOL itself is from the 60’s, but the hardware in the computer room in which I work is modern and is soon to be upgraded to IBM’s latest mainframe (the z15) sometime next year.
This is what I’ve been doing since 1997 and it’s what I’ve been doing since COVID hit. Yes, my job relies on people who have lost theirs, but I do my job with pride and when I go home at 7 am each morning, everyone waiting to get their UI benefits will have received them.
That is the beauty of COBOL and a forty (50?) year legacy with z/OS. It works.
We have two z15’s scheduled to go online sometime next year. The goal is April.
in normal times, being unemployed is just a transition, and id imagine there’s always enough churn to keep the unemployment employees going. it’s a big, dynamic county.
just exactly the reason we all pay taxes. keep up the good work!
Thanks!
I’ve been on the receiving end of social services when I was young; I got my job handling unemployment claims early in my life & I had a knack for how the technical aspect worked.
I know what’s at stake when I roll in at 7 pm to start my shift.
I don’t know that we can call this a win for “thoroughly debugged”, just because another programmer and I caught the bugs.
For one thing neither of us had used COBOL in 20 years, and not this version (HP-only custom version, really nonstandard). I had last used it in an “Intro to COBOL” class, and the other programmer as a junior coder doing grunt work.
Not the ideal people to declare COBOL code thoroughly debugged
One reason we were replacing an old COBOL system at one company was that there were no replacement parts when hardware failed, and the old maintenance guys repairing the systems with parts from other, dead systems were all dying off. Literally.
The manufacturer (HP) refused to write a maintenance contract, because they were running out of guys they could bring in as contractors to do the work.
They’d sell a new mainframe and port the code; but that was big, BIG bucks the company did not want to spend.
