Nearly a quarter of a century ago, I went for a job interview with ICL. “What do you think of COBOL?” they asked. “It’s a dinosaur, won’t last, should be put out of its misery,” I remember saying. The two grey suits looked at each other and turned back to me. “We’re a COBOL shop,” said one, before the interview very swiftly …
Its all the same - just a different colour
What never ceases to amuse me is that 20 years ago I could use the simple tools available for C programming to enable me to be track the slightest change to any byte in a few GB of code/data.
Now I cant even get management to admit a contract exists - even with their signature on it!
if it still works... ;)
Ah, those COBOL days. I cut my professional teeth on COBOL OS V1 and 2, multiple CICS A/TORs, VSAM and DB2 back in 1989.
I worked for a large Bank at that time and millions of transactions were being applied to millions of accounts each night.
Whilst the requirement is there to perform these processes surely, with developments already complete, it's cost effective to keep them running?
COBOL is still around simply because a) these processes are still functioning well and with integrity and b) they are too expensive to replace. And they won't be replaced until requirements are significantly altered to justify the huge costs of development.
Too Effing True
Not to mention: if it ain't broke etc etc etc.
Why people get their underwear in a twist over this totally useful language that has proved its utility over half a century and more is beyond me.
It is optimized for working with money, which C-derived languages ain't (as more than a few Wall St. firms quietly discovered and frantically dealt with in the 90s).
It has built-in support for structures with ridiculously easy redefinition capabilities.
It does arithmetic perfectly well, despite some rather witless people who claim it doesn't on the grounds that they once wrote a program in it once for a course credit and everyone knows you shouldn't take any notice of the length of time it has been dealing with payrolls, taxes and gosh-knows what else.
It can be written as procedural code, declarative code, decision matrices and lately, OO code. You picks your paradigm and you writes your program to suit.
Consistent and easily understood punctuation rules. Compare with the C-family semi-colon (rated by several surveys in the late 90s as the most expensive bug-source in the dotcom world o' tomorrow).
Why on earth would anyone think that a purpose-written financial language would be a worse choice for a general ledger application than a language designed primarily for coding system utilities?
Having programmed financial systems in both C and COBOL you make an excellent point. The amount of frakking work it took to ensure complete number accuracy in C was mind numbing and involved an enormous testing effort. In COBOL it was cookie cutter.
I do disagree on one point: The COBOL clause ending period caused me more headaches than the C semicolon.
The year 2000 issue was the last big thing which forced people to migrate to newer systems (whether it need to or not!).
Unless something like that comes around old systems will soldier on until they drop.
"old systems will soldier on until they drop."
What a fantastic ROI.
The "Y2K" problem (actually, a raft of problems most of them to do with outdated human procedures) required a few lines of code be added from a Cobol perspective. It took longer to identify them than to fix them in most cases, and the enterprise in which I work experienced two consecutive waves of date rollover problems because we keep track of very old things (people).
Coding for the century rollover was almost trivial, the time involved mostly due to a database update time-suck.
I don't know of a single shop that used the advent of Y2K to throw out their obviously useless Cobol programs and kit out with new (whatever).
Neither do I know of any bank whose ATMs stopped working on New Years Day (the big Y2K Gorilla in the Room).
There were a few ATM booth door locks around here that wouldn't function, and a couple of our UPSs shut down pending a code update, but the machinery in them wasn't running Cobol.
An old idea applies here - concentrator networks and then something at the top to coordinate it all like Interlink's BES which I use as a manager of managers for zSeries, pSeries, windows, tandem etc etc.
Someone's got to bring up Cloud here, so let me be the one.
I find it fascinating that Cloud is the current evolutionary state of IT and it arguably requires more management technology that any previous point on the IT evolutionary scale. Further, given Microsoft's recent paper on the benefits of using a Cloud service provider to truly get economies of scale from Cloud solutions, it is odd that the cost benefits of the most complex computing solution ever can't be fully realized by doing it in house( according to a Cloud service provider of course). To get the most benefit, you have to outsource it, which creates even more of a management nightmare.
Does increased management complexity ever end? Probably not, which means an increased spend on management solutions to deal with the entropy inherent in the evolution of IT.
the answer all boils down to ROI
If the existing system, no matter how old and outdated, costs close to $0 to maintain, then what is the incentive for the bean counters to "allow" IT to spend thousands of dollars to transfer that data to a newer form. Never mind the cost of hardware (which is the lesser expenditure), the man/hour cost of recreating application code from the ground up (which is what should be done) or just the cost of database translation in man/hour...
Add this: The existing system is still in use while conversion is going on, (meaning the new system online date is a moving target) and "must look and work exactly the same as the old system or we'll have additional training cost for or staff that still uses the system."
Now, tell me why any house would be willing to undergo this kind of transition with its associated costs when "the system we have still works, and we've amortized out all the operational costs"?
Up to a point
Legacy systems rarely do "cost $0 to maintain". A business so static that its IT requirements never change is unlikely to survive. Changing requirements mean modifications to legacy systems. Modifications mean cost and, more important, risk.
Making changes to systems where the technology is obsolete is much more expensive and risky than changing newer systems. The reason these systems don't get replaced is that businesses prefer to incur cost and risk in small chunks.
close to $0?
Hardly, some of these old mainframes are mind blowingly inefficient power wise. Now of course if the system is mission critical the cost is peanuts but overall the power and maintenance contracts alone on some of these legacy systems can be quite significant.
"Making changes to systems where the technology is obsolete is much more expensive and risky than changing newer systems."
And who is the wise guy to claim that Cobol is obsolete? You?
Your statement applies _only_ to hardware, not programming languages.
couldnt agree less
Its much easier to amend a classic CICs Cobol DB2 system than one of these new dangled J2EE ,hibernate systems. And if its c++ then you may as well give up.
As Always it depends
If you are talking 20+ years ago you are correct about the power costs. Early in the 80's there was no longer a need for power/water cost to be high. All Mainframes that I know of had a divorce a long time ago from water cooled.
The latest nainframes are indeed a bit stingy on the power needs.
Some operating systems run at 100 percent cpu busy 24X7 and they hum along as there is almost never a strain to put more work on. You can't say that about any INTEL based OS. In Fact if you run at less than 100 percent chances are your work is going to take longer. Long long ago the max memory you could put on a M/F was 8 MB now its 2GB (and might be more). Can you shut down specific cpu's on INTEL for maintenance while the system continues on without a reboot, no. Can you add memory on the fly, no you cannot. While you can do it to a limited extent on a M/F you really have to "reboot" to take advantage to some extent.
Yes the MF may seem old and its there so I have to put up with it, but indeed it does run a majority of Fortune 500 business's still and there is a lot less need for scheduled IPL's than there ever has been before. When there is an outage, you can generally find out what caused it and get IBM to fix it reasonably quickly.
Someone mentioned the MF as being secure, all I can say is I agree 100 percent *AND* if you find a way to bypass security and IBM recognizes it as an issue it is given a high priority within IBM to find a fix and send the fix out quickly. Can MS or MAC say the same?
IBM has a solid reputation for Security and relability of fix's. For the last 25 years the broken fixes IBM supplies has gone down to a small 1 digit number) as they first test internally and then ship the fix out to interested parties and as soon as they give the all clear only then will be fixes be made generally available..
IBM M/F's have also decreased the number of hardware problems to a small percent (it depends on the hardware that is talked about).
Approximately 30 years ago we had just gotten in a new M/F and the first day it went into production if failed about 6 times. The second day it failed 10 times. The third day we had IBM flying in people from Poughkepsie on jets and it we kept the system up for tthem to get a solid idea why the system kept failing as none of their tests hsd shown any problem. One of the system guys wrote a guarenteed never to fail program and we were able to prove to IBM it was absolutely a hardware problem. Then it took less than four hours to come up with a solution and they replaced a tri-lead into the high speed memory. It worked and never failed (for that reason again). One wire was 2 inches to long.
Never have I seen such good response from IBM on an issue. Somewhere around early 1990's
IBM started to go down hill. They laid off all their really good people it seemed like and their service has not kept up their previous level since then. It's still good mind you but far from what it was.
My dad spent all his programming life on a defense installation using COBOL - I tried (unsucessfully) to get him out of retirement for the run up to 2000. I still wonder how much he could have earnt, especially having signed the OSA
Mind you, I should have listened more to my tutors whilst at college teaching me the damn thing...
Where? Am I one of the few sub-40 year olds who know COBOL? It were my first proper job 'n everything. Ah well, back to this new-fangled Web2.0 stuff. It won't last I tells you.
I regretfully left COBOL (with ICL) very many years ago. Never really found anything better: in later more managerial years UML came close, but you can't seem to get it to compile (as we used to do, all night, with punched-card decks and flailing magtapes). Where's today's comprehensible, self-documenting, unambiguous language with which I can define, describe and evolve my business interrelationships?
The cost of old systems sneaks up on managers
You have in house developers. They do a bit here, a bit there.
You now have a workable system that's meeting the business needs (these systems were built for *business* needs, not because Unisys/IBM/ICL/Fujitsu or MS had some new shiny bit of kit to sell) and you think you'd like to port it to the new language/platform that's going to take over the world.
And you multiple all those developer hours by the rate of developers in *new* environment.
To get back to where you are *now*.
Suddenly it does not sound *that* much of an improvement.
I've heard of some clever mainframe re-architecting tools (EDS came up with the dodge of putting it on a mainframe and have the developers email chunks of old IIRC COBOL in for re-work, then it emailed them the new version. No GUI, but a neat hack I thought).
And as for that old S360 Assembler code.......
Do not speak ill of S360 BAL. It is more likely to still run on the current crop of IBM mainframes than anything written for Mac/Windows/Unix/Linux/... 5 years ago.
For the non-readers in the group, the title says, branch to the address in R14 and put the return address also in R14 (after saving the branch address in an internal h/w register of course). At the end of the routine at the R14 address will be a BR 14, which takes you back to the instruction following the BALR 14,14.
No hardware stack, no hardware recursion, lots of wild pointers.
Just imagine IBM would've been patent sharks in the 60s/70s
Almost any RISC CPU of these days employs a very similar function call / return mechanism without hardware stack:
ARM: BL ... / B LR
PowerPC: BL / BLR
SPARC: call sets %o7==%PC, "ret" is a "jmpl %o7+8,%g0"
MIPS: JAL / JR
Just think of it, had IBM patented this "set reg to [next] PC and transfer to [func addr]' with a few additional claims on variations of the technique drip-fed in every decade, what CPU instruction sets would be forced to look like these days !
Ah yes, Y2K
I still have fond memories of leaving work at 8pm on 31 Dec 1999, stone cold sober, and walking home through the drunken festivities while being paid £80 an hour to be on standby in case the next shift of guts needed help if / when the sh*t hit the fan.
COBOL has lingetring (positive) impacts even where the code isn't still being run..
I trained on COBOL back in the heady days before PC's cam along to ruin my dreams, firmly convinced that my working life would be spent in the warm and loving embrace of a brightly lit, white walled, environementally secure cocoon in the basement of a bank somewhere.
Unfortunately things didn't quite work out that way and I ended up supporting horrid things called Users continually invading my networks. Over time I have developed considerable hero worship for the BOFH.
That said, that grounding in structured programming has served me very well. My junior staff are often left slack-jawed when they underestimate my ability to read a bit of code and leave their latest 1337 bit of java script shattered on the cutting room floor. Those of us who went through the period of time when memory mattered, and efficiency was king will always be one step ahead of the kids who don't even know what those words mean.
COBOL, and the lessons that it taught us in terms of the correct approach to application development for business is still helping to keep us on the straight and narrow. But God help the organisations that have put all of its grey-beards out to pasture...
You too huh? (Y2K)
I had to go to work at 8pm on 31 Dec 1999. Midnight saw me standing in a client's IT department next to their IT Manager, both with beers in hand, watching the developers shut down, bring up & test the main on-line commercial system to make sure nothing went "splot".
Unfortunately I was being paid nothing extra for the privilege of doing this, which still rankles come to think of it!
could it be more fundamental
err, 'proper' design of the language and proper use goes a long way.
Choose the platform and the language up front with ALL the requirements in mind (Functional, non-functional AND life-time costs).
Being trendy costs, fashions come and go.
IS backward compatibility (in the future) not a concern for you ?.
Oh and every new generation of IT manager ('generation' = a mere handful of years it seems) fails to build on the knowledge of the past. e.g. How many shops still sign software contracts that end up tying them over a barrel FFS ?
Nice to see comments about structured programing in the posts. Ask a recent Computer Science grad about it and see the looks you get. or just ask them to explain what the impact to a business is of ignoring backward compatibilty.
And as for vendor hype - lord save us all.
A vendor classes a product/service as 'strategic' when they have marketing strategy for making lots of money from it.
Next time a vendor tells you they want to be 'a partner' with you just accept it glady and than them then tell them the names of your top two or three competitors and declare your aim to take them out of the marketplace and say "As our partner what are you going to do to help us take them out ?'
I have done this and believe me the reaction is pricesless. Plus it does rather clear the atmosphere and puts the relationship with the vendor back into its real perspective.
and yes C was written as joke - what a joke its has turned out to be.
Woods, Trees etc
You get all your requirements up front... Must be nice!
We rarely get them before we've finished building something. The last project I was on, the requirements were signed off mid UAT.
Sometimes the best choice isn't fashionable
A program that has run reliably for nearly 20 years needed amending for changing business requirements. Half an hour of COBOL, it is up and running and everyone is happy. (And yes I admit, I enjoyed it!) Re-writing in something more modern would have taken several days for no added business benefit. There's life in the old dog yet.
"[Mainframes] and also offers one of the most attractive cost-per-CPU-hour propositions if it is fully laden" - is this really true? I thought Mainframes where extremely expensive, because when you consider their abysmal cpu performance you dont get any work done for each MIPS?
Mainframe COBOL programming looks weird. I saw an example of "Hello World" in COBOL on Mainframes. It was like 200-300 lines of code. "A typical Mainframe program in COBOL". Gosh.
200-300 lines - you must be joking. Just Google "Hello World Cobol" - the first example I found was about 20 lines long (and at least half of the lines in this example were completely redundant).
If brevity really mattered
we'ed all be coding in APL.
Look it up.
worthy of admiration....
APL is Yikes. I learned Miranda (The Name Miranda means worthy of admiration) many years ago at university. Think that syntax is much nicer.
Not that I've used any of that for the last 20 years :^(
As for Cobol.. then Cobol are only good for killing in a Dungeon.. or are there some things that I've misunderstood here ?
Definition of "legacy"
What's the definition of a legacy app? - One that works.
"When does management itself become the problem?"
I had a call just the other day from an agency I'd lodged a CV with almost ten years ago, asking if I'd be interested in a SpeedBase (an obscure COBOL derivative) position. Given I'd not coded full-time in it since about 1996, or in it at all in the last six years, they must have been scraping the barrel a bit to have called me. Pity it wasn't nearer, or on a basis I could have considered it.
(Maybe I should dig up a dev system and polish my skills again..)
IBM zEnterprise plus zBX plus URM -- defragging system management
Regarding, "The downside of multiple generations of systems is that each tends to come with its own set of management tools and practices. Research we have carried out recently (soon to be published) suggests the phenomenon of fragmented management – that is, if each system requires separate management capabilities, the resulting overheads in terms of staffing outweigh the in-principle benefits of having such management tools in place in the first place."
...IBM's zEnterprise system with zBX (zEnterprise BladeCenter Extension) links traditional mainframe architecture with POWER7 and x86 blades, all centrally managed by the Unified Resource Manager. Announced July 22 so real-world experience with it should trickle in soon. For IBM's view, see
or consult your favorite source of information.