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.
Bollocks, I say (did I use that correctly, my Limey friends?) Anyway, replacing COBOL applications is really a bad way to go. It is a robust and sturdy language, point obvious by the shear number of applications which still run today (after minor modifications for the 2000 change.) It REALLY IS an easy language to learn and use, once you get used to the draconian restrictions on indentation and essentially writing your programs like you're writing a book (OPPP!)
Best of all, it has not required multiple iterations and revisions over the years to deal with silly things like "a remote attacker can take control of your computer" or "a local user may elevate privileges." Yup, no COBOL-pwnage around these here parts.
I see how this really would be a good time for some consulting firm out there to have someone on staff who knows COBOL, even if just as a hobby*. I hear from people in various industries about all the legacy applications which still run regularly, and how so many of the applications would benefit from some added features or reworks. Hell, with the right tools a PFY fresh out of university (college, for my fellow Yanks) could take on this job and win a Presidential Fitness Award in the new and special category of saving a state's ass with 1337 C0B01-f00.
Anyone search the State of California web site for a job opening requiring said foo?
Paris, requiring special-foo, and she did the People's Poet.
* I wasn't joking in my last post. When I had more time, I had a sorry habit of taking our class programming assignments and coding them in other languages as well: COBOL, ARexx, PHP, and sometimes BASIC. Mental masturbation, I suppose.
Paris, mental... oh, never mind.
Or goto for that matter. Thirty pages of dense flowchart; took longer to write that than the program.
Why? Well, I was told it was impossible.
COBOL had some fun things that you could do; like playing music on the big line printer.
(All of my programs did the rumba; drove the shop nuts.)
But I was glad to be able to stop writing COBOL code; and PASCAL which I actually did hate worse than any other language out there.
And during the Y2K nonsense I hid under a rock or something.
(COBOL? No, some other John Stepp; I no speeka the picture clause.)
Believe it or not, it is possible that state of CA does not have the cobol source for some of the binaries they are running. Or they are not exactly sure which version of source produced the binaries they are using.
Source code control and library hygiene are recent innovations (compared to cobol) . Much of the code was written by itinerant consultants, long gone and untraceable.
Many mainframe shops STILL do not use source code control.
The first generation of cobol programmers are not retiring, they are dead and buried decades ago. The second and third generation are retiring and laid off.
And a rewrite with "modern" languages is out of the question. Prolog, lisp and ascii white are insufficient to parse the policies of the great CA bureaucracy. The cobol is pure spaghetti because the policies are pure spaghetti.
There's nothing wrong with COBOL, it has gotten a bad rap because schools and vendors wanted to push their 'new magic solutions'. Sure it's a little wordy, but, having programmed in COBOL for about 30 years, there's little I've found that I couldn't do with it. I also regularly program in Java, C, C++, C#, Perl, assembler (several different architectures), each has their good points and bad points. If I were to write a Payroll system, COBOL would be the language of choice for me. If I were writing a compiler, the C would probably the language of choice.
As to all that 'spaghetti code', imagine a system written in any language that had been around for as many years as some of these COBOL systems, they'd look like spaghetti as well. Also, since much of the code was written when computing resources were very expensive, hence things like 2 digit years.
Any system that old would be a problem. Of course the thinning of the COBOL programmer ranks will make them more expensive over time, making rearchitecture (replacement) more attractive.
Of course the estimates people are throwing around are criminal. A shameless transfer of government tax money to greedy corporations. We're on record offering to replace the system in question for 1/10th of the quoted cost, and we're able to do that because we have a unique approach. If you're interested: http://www.maketechnologies.com
Or if you want the "gloves off" side of the company: http://gotlegacy.net
Tom
You know the pay scales are not hard coded in the COBOL program...
They may be in a database or a data file but it would be dirt stupid to put it in the code (and most the implementers in this environment were anything but stupid.)
I agree with the other posters that this is just being used as an excuse not to do anything.
I'm with the `CoBOL is a fine language for what it's used for' and related views. When I did my COBOL training back in the 80s writing a payroll program was one of the exercises. Sounds to me like there's plenty of BS and smoke being used to blind the bean counters, let alone the Governator. After all there's folk's beer money at stake!
Anon Coward wrote: "Get rid of that legacy crap."
That “Legacy Crap” will be running banking systems 40 or 50 years from now just like it has since the late fifties and early sixties. Without a DAY of downtime.
You people know NOTHING of maintainable, trouble free code -- which is why every major software project for the past 20+ years has been an increasingly spectacular series of failures.
I too love my 6-figure COBOL salary and I have really very little to do to earn it. I just need to understand cause/effect and the first principle of software engineering: if it ain't broke don't fix it.
LEARN how meaningful and productive software is written before “criticising” it. Not that you are qualified remotely to do so.
The complexity of making the change comes from the vast mass of bureaucratic rules and regulations that are encoded in the payroll software.
You can't just cut everyone by a percentage-- the floor is usually the minimum wage, or sometimes 0. Changing a person by a percentage may cause a negative payroll for someone having to fork over child support (for instance), or time shifting weeks, or whatever. The result might also go below a cut line for medical coverage eligibility (try surprising someone with that just before some major medical work).
Most cases are simple, it is the boundary cases that snarl up the change and take the vast majority of the conversion time. There are legal requirements, contractual requirements, common sense boundaries (how long will you work when you have to pay each week instead of being paid?), handling people who have allocated 401K sums in odd ways, and on and on and on.
Arnauld is throwing a fit because of a budget impasse but since his hissy fit is likely to hurt a great many people there's a lot of people dragging their feet. They've all but said to him "You want to change the payroll system, do it yourself".
The other reason to drag their feet is that once the budget is set up then they'd have to change the code back again.
COBOL may be old fashioned and clunky but its very reliable. We tolerate failure on a PC because it doesn't really do much except inconvenience individuals. In the real world failure is not an option. Part of this would be a very slow code change cycle -- hours to change the code, weeks to test it. (Incidentally, there's still people out there who program in IBM assembler....... I met one a few weeks ago.....amazing.....)
I don't get it... there are several companies out there that provide ready-made enterprise-level solutions for payroll (disclosure: yes, I work for one - we provide various software packages and tailor them to the clients' needs). It wouldn't take $30bn (or in fact $30m) to extract the data from the old COBOL database, buy new hardware and a payroll application and load the data on the new platform.
The "Governator" should point that out to the state's IT staff and then ask again how long they think it would take to fix the payroll codes.
“COBOL may be old fashioned and clunky but it's very reliable. We tolerate failure on a PC because it doesn't really do much except inconvenience individuals. In the real world failure is not an option. Part of this would be a very slow code change cycle -- hours to change the code, weeks to test it.”
Nope. It takes a day (or less) to re-write entire COBOL subs -- I do it. Its a simple pleasure.
It IS clunky and ever-so-dead-old-fashioned BUT WHO CARES? It actually works especially if you have a clear idea of what the fuck you're trying to say/do.
...blame system design and politics.
I was a COBOL A/P for 5 years.
(These days I do J2EE so don't start with the "dinosaur" cracks).
And the article isnt wrong. I was involved years ago with a (household name) US retailer. I kid you not we had a whole TEAM manually rewriting the business logic of our payroll system every year due to changes made by federal, state and even municipal lawmakers.
It was feckin crackers. We did the best we could, eg things like tax rates in the database and not hard coded. But how do you get logic like this...
If employee lives in area A but works in area B but spends more than 60 days per year in area C but in married to a woman residing in area B and has children in school in area D and healthcare in A and is in a union and its raining and.....
Especially in the Eastern (smaller) states where its common practice for people to live/work/deal across state borders. Now every year each state would bugger about and change all its rules. And each year our team would swing into action trying to get the whole lot changed and tested before the end of the tax year. Then after the batch run everything would change all over again.
You would have the same if the thing were written in C. Perhaps less so for C++ or Java but not by much.
The mad thing is, they could use SAGE or SAP or something if lawmakers would just do things easily and elegantly but they dont. Instead the US has all these special interests, the result being overlaps in jurisdiction, conditions, criteria and so on that are basically impossible to implement without a gigantic nested "IF". (A conditional what exists en every language I have used). The poor programmers are caught in the middle.
Somebody typos $30bn instead of $30m.
Then all the presumably clever posters pick up that particular ball and run with it and have lotsa insightful opinions about those $30bn.
Guys, ever heard of double-checking facts before engaging tongue? 30$bn is on the order of California's state budget, for crying out loud.
Paris, who is cleverer than all but the original typo guy (who made an honest mistake) and the guy who caught him.
I've worked in COBOL for 40 years and there is not much you can't do with it. Still developing tons of software using it. Also did CICS and IBM BAL assembler.
One thing I have noticed about these obsolete dinosaur languages that the young pups want to abolish: NONE of the IT disasters you hear about are written in these languages. And much more software is written in them than in the C like languages,
Yeah, they are not much fun like java and all those. But, young fellas, pay is for WORK not having FUN grinding out code. That was a lesson us dinosaurs learned right off.
Also business apps should be written in a business like language that even the original requestor can read and understand. The bracketed gobbley gook that is the C like languages is indecipherable to anyone but programmers.
Well, Python excepted because its my favorite of that kind because it is the clearest.
What everyone today seems to overlook is that software is a very valuable asset and should be as easy as possible to maintain. It WILL be modified and have functionality added if it is any good.
And my COBOL programs are NEVER spaghetti code. They are so clear any fool can understand them with copious comments in case there are any questions.
Report archive programs I wrote 20 years ago still run every day in Europe, Asia, America and have never gone down even once. Well, maybe once, but that's it.
It is the skill of the artisan that determines the end result not the tools used.
There already is one. NetCOBOL.Net from Fujitsu in the USA, along with a whole raft of emilators (NetCICS, NeoBatch, etc) that let you lift an IBM Mainframe CICS/COBOL installation and move it into a Windows environment unchanged. You can even take your ISAM files with you.
As for managed change, I'm sitting here on my last couple of weeks of a contract, the final VME site here having migrated "successfully"[1] earlier this year. We just got a call from another former client who moved off last year: "We urgently need to read this Mainframe tape on our Unix box". Best laugh I've had in weeks.
1) The usual sorry migration tale. Replace a 90 MIP VME box with a server farm. Get something that runs so slowly that people are working at 30-50% of their previous efficiancy at best. Spend enough money to buy a small country in the process.
You want to get rid of COBOL and all that legacy crap? Then simply boycott any system that uses it - anywhere in its front end or office back end.
That'll be most banks, pretty much all financial transactions (loans, insurance...), many hospitals, local authorities and a lot of airlines and many airports.
Also most road vehicle manufacturers, and the odd website or two.
Let's stop asking other people to get rid of COBOL and set an example. Remove it from your life today.
Anyone working in the financial services industry will know how widespread the use of Cobol is. From my experience the majority of the worlds large insurers all run on a Cobol system. Those that have progressed from black and green onto fancy web front ends are stiull running their business processing on a cobol based system. And it's not going to change anytime soon.
As has been said, why change it when they work well ? Cobol systems structured well and to some form of standard should be easily readable and maintainable. I'm guessing this payroll system aint one of those.
I'm a COBOL programmer and I'm only 28 - and yes I worked on the Y2K problem for a local council at 18.
Only because the college I went to still used COBOL as the higher level language (Pascal in the first year) until 1999 when they switched to VB.
At the time most of the ATM backend systems used COBOL and I'm sure some of them still exist so we do have some demand still.
So how do I apply for my US work permit?
Any reasonable competant* developer should be able to learn a new programming language easily. I've never used CoBOL before but having been sent the source to a program could quickly and easily port it to another language. it's practically written in English!
It may take longer to do, but it's not an imposssibility. Although it does raise the question of why code changes are needed just to cut someones salary. Surely any payroll system would have been designed from the start to cope with people having their salary cut? All of the salaries should be held on a database, and all of the code to handle back pay etc, should have been put in when it was first built so the database update should be all that is needed.
*Of course, whether or not reasonably competent developers are being churned out of the universities, or just people who know how to code in <insert language of the month> is another matter.
"I too love my 6-figure COBOL salary and I have really very little to do to earn it. I just need to understand cause/effect and the first principle of software engineering: if it ain't broke don't fix it." .... By Greg Fleming Posted Thursday 14th August 2008 21:22 GMT
Greg Fleming,
Surely you do not think that it isn't broken, and the COBOL Code not Cracked for Remote Proxy Administrative Use/Philching? Why do you think the Banks have Lost all their Money and Credibility to the Sharks in the Private Equity and Sovereign Wealth Markets who have Effectively taken over the Federal Reserve Money for Nothing and the Chicks for Free System, rendering them as Eunuchs in the Harem.
And as for the Sharks, well they just love their 9-11 figure Funds and unlimited Special Access Programs to All Future Sums. Wake up and Smell the Coffee. IT's Java at ITs Best.
The problem is, of course, that the Bankers have no Idea how to Fix IT with IT for they cannot See what Needs Fixing although they are Bound to Realise that something is Seriously Wrong because they are Losing Wealth, Hand over Fist, whilst Others are gaining IT. That suggest a Lack of QuITe Necessary Basic Advanced IntelAIgents Training aka tasty BAIT and/or a Failure of their Intelligence Networks and/or Both with More Shenanigans and Pain/Ecstasy to Come and On ITs Way.
Or would you posit that the Present Headless Chicken Routine is their Masterful Plan?
You'll have to spell out the Wisdom to me in that one, please, as it completely eludes me.
These are Popular Prescient Words of Wisdom ...... http://tinyurl.com/5ln4s5
I work all night, I work all day, to pay the bills I have to pay
Ain't it sad
And still there never seems to be a single penny left for me
That's too bad
In my dreams I have a plan
If I got me a wealthy man
I wouldn't have to work at all, I'd fool around and have a ball
Many of these comments reflect one of IT's worst perennial problems: the ridiculous obsession with fashion. The very first comment in this thread (by our old friend AC, of course) was "Get rid of that legacy crap."
Why? And did he mean "it's legacy and it's crap", or "it's crap because it's legacy"? I strongly suspect the latter. This is the know-nothing, "we're young so we know best" attitude exemplified by Tony Blair with his dismissive comments about the Victorians (who actually invented most of the "modern" stuff he is so proud of).
COBOL, as its name shows, was invented to handle routine business programs such as payroll and invoicing. It's specifically designed for doing calculations with money, keeping records, and issuing bills and reports. And it's very good at that. People who become programmers (or IT directors) in search of fun, intellectual stimulation, or creativity, need to remind themselves that the purpose of business is to make profits; and the purpose of government is to serve the citizens as efficiently as possible. COBOL does both these things rather well, which is why more business software is written in it than in all other languages put together. The amount of COBOL in active use has doubled since 1990 - not exactly a sign of a dying language.
If I could do one single thing to help the IT industry and its users worldwide, it would be to remove the scales from their eyes and let them see clearly the difference between something that's useful, and something that's "new and cool". Other things being equal, the new "technology" always costs more, takes years to become stable and mature, and forces everyone into expensive training and re-equipment. (Which, of course, is why so many people love it).
All together now: "What is the definition of a legacy system? ONE THAT WORKS!"
You wrote: "Many abandoned COBOL in favor of more esoteric and - some would say - impractical languages such as Lisp and Smalltalk."
Not just COBOL...
A few years ago, I was told by a programmer at a major news content-provider that they were rewriting their query engines because they could not find any APL programmers, or even recent graduates willing to be paid to learn it.
people: we want more for schools - governator: check
people: we want more for roads - governator: check
people: we want more for health - governator: check
people: we want more for pensions - governator: check
people: we want more for parks - governator: check
people: we want more for prisons - governator: check
people: we want more for greenies - governator: check
governator: we need more tax money for all that - people: OH NOES
bless mother cobol, 2nd language i learned after pl1; but why wouldn't the pay rates just be in a bunch of cards to feed in? ha ha ha; arseholes
COBOL I started with back in 68 and none of the languages since hold a candle to it for business systems. Sure it could be improved but it produced efficient code that just carries on running and contrary to this report easily amended. It's written in English not gobbledygook. Most of the modern languages are crap and cost a fortune in implementation and maintenance.
I agree that Cobol has its attractions: close to natural language, no recursion etc. (thank you, Jim Inglis, Birkbeck '91) but I really want to add part of your comment to my collection of English "howlers": "It is a robust and sturdy language, point obvious by the shear (sic) number of applications which still run today". Thanks.
@RW - "but who uses Ada" - Babbage did, didn't he ?
I know an office (which shall remain nameless to protect the guilty) which has loads of Core Duo PCs running XP connected to an IBM "mainframe" AS400 running RPG2 programmes outputting ASCII in 80x24 format !! The programmer who wrote the programmes buggered off after a tiff with the managing director; leaving behind *NO* notes, *NO* comments and *NO* indication of how the damn things work. And everyone dares not "fix" anything in case it broke everything else !!
Legacy !! Tell me about it !!
An inflexible design can be implemented in any language. What would the comments be if the language of choice was Java or C++?
I get scary when so many people forget this basic fact of an IT application.
We easy start to shoot the player - not the composer. How many innocent get blamed? How fast do we loose our basic ability to think? Please wake up.
-cle-
Another great programming language, Air Traffic Control systems are written with it. It is fault-tolerant and self documenting.
Can I seriously seeing myself putting my safety in an ATC system written, oh, say, in C or Java? No.
Lots of people use ADA, actually. Again, you get handsomely rewarded for it because you are doing proper software engineering and building fault-tolerant working software.
It isn't a fad. COBOL, ADA ... they just work and I'd never entertain doing serious work with much else, apart from assembler perhaps.
Everything else is quite trivial and doesn't even fit into the same scale of rationality.
I'd make it mandatory for everyone who calls themselves a programmer to be actually qualified in all three of the above. Then software fiascos would just disappear and people would get what they paid for. Once again.
Yeah we used to use a manual key punch for card inserts in a Cobol program deck. Some evil operators liked giving the cards a shuffle if they didn't like the programmer. Odd thing is on a box with 90k of memory and 80M of disk it ran the whole Building Society accounts - go figure. It was one of the few times in my computing life that I actually saw a system that did something useful; in this case saved about 6 months a year overtime doing account books(passbooks) manually. Oh and that was Burroughs; we used symbolic or BPL for those more system orientated tasks.
I was taught COBOL in the late eighties, as I remember it is a procedural programming language, with some fairly simple data types and rather crude data access mechanisms. If someone who fancies themselves as a bit of programmer can't pick up the ropes well enough to be able to read and maintain a COBOL program, I'd seriously question their aptitude for the job. Can't the youngsters handle a bit of data access without SQL or a ORM framework? or can they not handle a system without a mouse, menus and intellisense? I don't want to knock COBOL experts, but it ain't rocket science. Next thing people will be telling me that no one can write decent assembler code any more.........oh, they can't?
I originally taught myself to program computers by reading CoBOL source code. It was just a little office system, but I got hold of the source. I had been using the system for a while, and it suddenly came to me - "Hey, I understand what this does".
There was not a code comment in sight, but it had been written in a self-documenting way - "GET_DEPOT_OF_ORIGIN" - guess what that call does.
I'm with the 'if it ain't broke don't fix it' crowd, and also think that CoBOL is unsurpassed in what it does.
I mean, 'C' pointers to functions - thanks but no thanks!!
I'll point out that my c code is generally as readable a what little COBOL I have seen. It just requires the programmer to be intelligent, put in comments as they write the code and give sensible names to variables, functions etc. I'm very sure a bad programmer could write incomprehensible COBOL just as easily as incomprehensible C...
Before COBOL there was assembler. It was a bottleneck. I haven't written COBOL for more than 20 years, but it was a fine language for generating correct IBM or Univac Assembler (not the most efficient, but machines even then were faster than people in generating code). The data areas were accessible in dumps and debuggers (when we had them). Structured programming and extensive documentation of PERFORM A through A-EXIT subroutines gave COBOL some of the advantages of object-oriented programming without the disadvantages (the data remained in the "main"). Calls to separately compiled modules enabled reduction of single load size, while providing the easy maintainability of common code and parameters. Finally, IBM's CICS provided the event-oriented environment later seen when event-driven windowing was added to the various PC-type operating systems; it also anticipated the Web front end by off-loading the user interaction to a specialized front end management system.
The side effect of mainframe implementation is that there was just one operating system and executable application to be maintained. Once tested on the Test System (we always had one), the code could be moved to production with some amount of confidence. Yes, it was slow to happen -- nobody wanted to mess up the current system. But stability was greatly enhanced, most of the time. Operating system changes occasionally caused problems, as did new versions of the compiler. One advantage was that we all used the same language and environment and could share our experiences without the fragmentation currently experienced.
So this was not "dinosaur" stuff in the sense of lumbering extinct beasts. This was and is a parallel universe of software and hardware, as reliable as the birds who are the descendants of those dinosaurs.
It wouldn't kill any of you to learn and appreciate COBOL as yet another tool, another compiler. CICS is much harder, of course; it's hard to describe, somewhere between Windows and Web programming. And database calls are in there too -- it isn't all ISAM, or tape.
"The problem isn't simply decreasing salaries; the problem is calculating back pay and taxes on said back pay after reinstating everyone's salary in the future. The code to handle that scenario simply isn't there. Doing it all by hand is obviously not realistic."
Then the system was bad to start with.
I've seen systems, designed in the late 70s and finished in the (very) early 80s (ok, they're not quite 30 years old) that could do things like this without a hickup.They were explicitly designed to do things like that. If an employer finds out, that he'smade a mistake and "underpaid" his employes for the last 3 years would have a serious issue rectifying this problem. A good payroll system will "notice" backdated salary changes, recalculate EVERY payroll cycle (sure it'll take some time to do) and come up with a pay slip that contains all the changes and adjustments, incl. tax, pension payments, health care and whatnot.
COBOL is a cool language. A bit wordy at times, sure thing, but the wordiness has its advantages too. Look at a completely undocumented piece of C code, somethink like 2K loc, and then look at some COBOL code that does the same thing. Now which of them do you think is easier to understand? Of course it is a pain in the neck to
Most people who bad mouth COBOL base their "criticism" on hearsay and things that have been eliminated since COBOL 85, in some instances even COB 74. The bad reputation of COBOL is almost solely based on the Y2K problem, the reasons for which have been pointed out numerous times here. Guess what, take a look at how many UNIX systems are ready for the "UNIX date" issue? Well? It also stems from a time, where people simply didn't realise their ideas might be used way beyond the "expected" lifecycle. Hey, come on, Windows 95 even crapped out, because there suddenly were CPUs that could do things faster than expected (AMD K2 "issue"). Mistakes were made througout the entire industry and some even after people should have realised they were wrong.
A "nice" annecdote: Back in 1990 or so, we started writing a business application in COBOL. In the very early stages of development, I suggested to my then supervisor, that we make all date fields 8 instead of 6 digits. His answer was: "Y2K is 10 years away. Nobody will use this software by then!". Needless to say, the softwarewas canned by the end of 1999 because it was way too expensive to make it Y2K compliant and all clients using the software were left in the rain. All Y2K was, was shortsight on behalf of those, who should have known better.
You can do (almost) anything in COBOL. IIRC the Micro Focus COBOL compiler was mostly written in COBOL...well, I wouldn't go that far, but a solid business app, I would write in COBOL. Even today. Why? Because COBOL was made for it, because I can't recall buffer overflows in COBOL apps, because they don't crap out. How many of your C, C++, C#, JAVA, VB, Delphi and who knows what programs, will still run in 10, 20, 30 or even 40 years? Well?
All languages have their pros and cons and some are better for certain purposes than others. Would I want banks to run systems written in C? No thanks, not with my money involved. One buffer overflow, all gone!
Setting aside the "replace COBOL" foolishness in this thread, the actual business problem here is much more complicated than the article suggests.
1) There are over 200k employees, which puts the State of California into rare company. Your crappy little payroll system, designed to work for small businesses? Yeah, not going to cut it in the big leagues. (There are fewer than 20 companies on Forbes list with this many or more employees.)
2) This is not a pay cut. Repeat that after me: "this is not a pay cut." This is pay deferrment - the system needs to calculate their pay, but only deliver the equivalent of federal minimum wage, tracking how much of the rest will be backpay after the budget passes.
3) This is not an across-the-board change. Certain categories of employees are exempt, certain categories are receiving no pay at all (appointees, certain types of professionals, etc.). These categories are somewhat arbitrary, and do not currently exist in the payroll system (or anywhere else).
4) The $30M? Not only was there a typo of a few orders of magnitude, but that was not to replace this system, but a 'similar' system. Don't know what it would take to replace the state's payroll system, but, having worked on other large-scale systems, I'm pretty sure that it would be a multi-million dollar system. The complexity of the system reflects the complexity of the state's payroll - thousands of employees, multiple unions, different types of 401k plans, etc.
Talking about how easy you think this would be doesn't make you sound like a 'real programmer' - it makes you sound like a kid with no experience working on large projects.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
