COBOL thwarts California's Governator Inspite - or perhaps because - of its "difficult" birth, Common Business Oriented Language (COBOL) has become a survivor in the world of computing. That's caused problems when it comes to maintaining systems running the language. COBOL has now taken center stage in the rumbling controversy over the State of California's budget …
Think of it this way ... if COBOL were running your life support machine would you really want to just chuck it out and starting again? No. Of course not. So why should people whose paycheck depends on it be any different?
It's not just a switch you can flick and anyone who thinks it is is obviously sitting in front of their PC writing software for themselves and no-one else. "Managed change", it's what keeps business running. A few years out in industry and that would be painfully clear to you.
"Get rid of that legacy crap" - reminds me of when I was young and stupid. Now I'm just ... Hang on. That's not worked ...
What? You moron! If the state actually spent money to upgrade, they wouldn't be in this mess.
Friends of mine still work at the Florida state university system IT department.
For literally decades, state computer departments have been going "can we upgrade from this frigging COBOL???!! PLEEEEZE?!!" and the state goes "NO MUNNY 4 J00!!"
You really don't think the IT departments have been fighting to keep COBOL, do you?
So they end up in this... er... state.
Hey Governator...
I can find you and entire reitrement home full of programmers who will be happy to do the work, will cost you 12 Bn, 10 BN for me, and 2 Bn for the meds to keep them ALIVE long enough to do it........
Shouldn't take more than 4 months if we give them extra prune juice and make them skip naptime....
The republican governer reduced salaries, the democrat councillor refused to implement the cuts. There was a law suit, the council lost and now they have come up with a "The dog ate my homework" excuse to prevent them carrying it out.
You can bet that if there was a need to raise salaries they would find a solution pretty quickly.
COBOL is not. in all fairness, a hard language to learn, just a very very ugly and painful one to code in, but it's not intrinsically any harder to maintain than any other language, if you know the way of it.
Any competent code monkey can pick up COBOL. They might become psychotic and top themselves afterwards, but it's doable. There isn't anything particularly magical about it that makes it any different from other languages. It's a bit bondage and discipline, and has some funny ideas about whitespace, but then so does Python.
I speak COBOL, and have worked on some crawling horrors of legacy systems that were built with it, often times running in a machine emulator of dubious virtue pretending to be old ICL kit. It's never impossible, just often unpleasant. But much legacy systems work is unpleasant, it's just the nature of the beast.
So someone is telling the governator porkies, methinks. Maybe I'll shoot him an email with my CV.
Who needs a CICS programmer? This COBOL debacle is nothing compared to what will happen when that goes wrong for someone.
Fair enough, it's not a language, but the principle is the same. Most of the world hasn't even heard of it. Most would assume that something computer related that's almost 40 years old must be dead, but that's just the same sort of breathtaking ignorance shown by modern PHBs (including el Governator) when it comes to "Legacy" stuff.
I know I'm preaching to the converted here, but ask any of your nearby PHBs if they've heard of it, or if they know what Microsoft's actual software market share is in terms of cashflow and you'll realise they really just don't have a clue (To save you looking it up, It's around 10%, most people will say 80% or more)
Paris, because she's the kind of PHB I could live with - easier on the eye than most, and dead easy to baffle...
"Who pays to rewrite those systems? And why would they, when they work?"
I'm glad you asked. Who pays the guys maintaning the system at present? And does the system really work, given the ... issue ... raised in the article?
I'm pretty sure that IBM would be more than happy to do work for $30bln, but I'm also sure the work can be done much cheaper. And faster.
In a former life, as a COBOLer, what struck me was the way all literal fields were hard-coded into the reports. This meant that when the company changed names, we had to go through every single report and amend the appropriate PICT fields. Could have all been fixed with a few lines of code to read such details from a file at the start of a batch run.
I suspect California's payroll is held on ISAM files, which should be easy enough to patch en masse, with a bit of effort. There's probably even an ODBC driver available! Sounds like the old-timers and their managers have colluded to drag their heels on this chage. Can't think why.
Steve would be more than happy to sell California some "modern" cr@p to replace the lecagy cr@p.
A replacement system for $30bn? 10,000 programmers at $1 million p.a.? Before packing my bags to head on over there I checked the original article and re-thought my plans when I read it was only $30 million that was quoted.
Maybe that's the tactic that the IBM sales team should have used...
"New system? That'll be $30bn."
"How much!?"
"OK, we can do it for a 1000th of the price."
"That's better. Where do I sign?"
Dijkstra's comments anent COBOL are an exaggeration. It's quite easy to write structured code in COBOL merely by showing a little discipline in your coding style. Indeed, the COBOL got rid of the infamous "go to depending on" construct quite a while ago, though it left the "go to" intact.
In saying this, I am not claiming that all those billions of line of COBOL code are structured: in my working days I saw some horrific tangles of COBOL spaghetti code, but that was equally true of all the older languages: Fortran, PL/1, even Algol.
It wouldn't surprise me in the least to read that the backends of some modern online systems have been written in COBOL.
AFAICT, the languages most often used today embody their own very serious defects. The interminable issue with buffer overflows is due to the absence of built-in array bounds checking, and there are intricacies to the syntax of the C family of languages that make them prone to whole new classes of programming errors that can be extremely difficult to isolate.
COBOL, by its very wordiness and its demand that everything be explicitly declared, precludes many such errors.
No, I'm not saying that we should re-write everything in COBOL. But please don't think that the current generation of programming languages is the end all and be all. I will make a possible exception in favor of Ada, but who uses Ada?
The next "Red Sonia."
So, how many people who know some COBOL are going to throw in their application? I did COBOL in high school and college around the time of the Y2K threat. I still have some of my books from classes, and even bought some others along the years. Sadly, I even dust off my COBOL skills once in a while by firing up RM*COSTAR in CrossPC on my Amiga.
That's a true story, by the way. But closer to reality, I know at least a couple of people who have done COBOL professionally recently. One of them worked for ACS, which I believe is a big enough company to do work for the SoC.
Paris, dusting off her skills just in case they're ever needed.
Many years ago, a customer wanted us to include a new feature in our software. We had plenty of other things to work on that were higher priority, so we put him off. But he was persistent, insistent and consistent in his request. Finally our company owner quoted him a price just to shut him up.
"Forty thousand dollars...that's the fee for your custom feature request."
(Ha! That'll keep him quiet!)
The customer pulled out his corporate check ledger and wrote out a check on the spot.
"Guys? You know that feature we've been back-burnering for the last year, for that one customer who kept asking? The one that's less important than anything else we're doing? Guess what..."
Maybe IBM figured they could avoid the job if they quoted a high enough price?
Back in 1998 I was at college and the C teacher had a breakdown just as we were about to start the 2nd year. So after a fun year of Pascal with a view to C++ in year 2 it was announced we had to learn COBOL instead.
It was the dullest year of my life. Anyway, if a program is written well enough to run for 30 years then credit where credit is due. The problem is that nobody was forward thinking enough to suggest a change before they realised it was too late.
This is a standard ploy for IT (well, not only IT) firms who don't want the specific contact but still want to get future pork, er, contracts from an existing customer.
You give a ridiculously high figure to undertake the project to effectively tell the customer that it's an expen$ive favour .
If you get the contract, well, you're in the money (unless you are totally incompetent). If you don't get the contract, then you at least "showed interest".
Let's see. Write a "temporary" program that just spits out checks for the minimum wage and hold the "real" payroll stopped for a while. It seems pretty simple to me:
printf ("Your weekly paycheck is: %5.2f dollars\n", 6.55 * hours);
Modifications for minimum wage at a fee.
Well, I speak COBOL, being over 50... In fact, I think I invented recursive COBOL, where a program can actually call itself with new variables, and then return up the stack to to caller.
But, would I want to work for an administration that is likely to cut my contract fees if I made it work? Not so sure...
Paris, because I'm sure she could do herself recursively....
The pioneering languages pre-1990's are still strong and will remain so until someone chooses to not support some particular hardware platform change, that's the reality of it.
I was in the UK prior to Y2K and ASM/BAL at insurance firms was all the talk about how to find enough bodies to fix it back then. I certainly don't think that after Y2K they decided to toss MORE money at it for rewriting to 'modern' languages. Corporations don't think that way so long as it works they would rather buy faster hardware. There are entire sets of software and businesses that do nothing but link legacy systems to modern systems creating more user friendly interfaces with virtual teletype terminal services running underneath.
How many so-called modern languages along with their many variants and plug-ins and extensions will be viable 5 or 10 years out? Will the tools still be available to support them? The platform transferable to new hardware? This is why so many go to packaged systems where that problem is someone else's problem.
Anyone want to update (not rewrite) a ColdFusion or Delphi website?
COBOL wasnt the problem, it was the cost of memory when the systems were written, 2 digits for the year saved you some space and when you had several million dates in your db it added up. When I were a lad working on Honeywell Bull DMIV systems we stored dates as numbers, formatted YYMMDD and used simple greater than, less than tests with home rolled date routines for anything clever. Yes, I am grey and bearded.
Actually, as every geek who ever freeze-framed the first movie on video has known ever since the '80s, the T-101 was programmed in 6502 assembler[*]... none of that poncy HLL stuff for a low-down dirty killing machine like that!
[*] - and had several alternative possibilities for how to respond to that janitor beyond "Fuck you, asshole"....
All that and no mention of technology debt?
Setting aside the fact I'd eat a bullet before writing another line of COBOL code, the reason to get rid of it is really because stuff like this keeps happening, and it will keep getting worse and more expensive every time it does.
Pay someone to make something you can control/maintain/upgrade easily now, or spend much more than that maintaining it over the next decade or two.
And... For me, and for the children, please, kill COBOL now. For a brighter tomorrow.
CoBOL is a fine language for what it's used for . What exactly would you replace it with? C which is pure garbage by comparison or VB which is a joke. If it's used for business usage which is payroll accounts stock handling etc then there is no need for anything except CoBOL. I suppose most of the people chiming in have as much of a clue about CoBOL as they do about Forth.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
