August 9, 2009
I'd like to talk to you about ducts. Wait a minute. Strike that. I meant COBOL. The Common Business Oriented Language is celebrating its fiftieth anniversary as the language that is everywhere and nowhere at once:
As a result, today COBOL is everywhere, yet is largely unheard of among the millions of people who interact with it on a daily basis. Its reach is so pervasive that it is almost unthinkable that the average person could go a day without it. Whether using an ATM, stopping at traffic lights or purchasing a product online, the vast majority of us will use COBOL in one form or another as part of our daily existence.
The statistics that surround COBOL attest to its huge influence upon the business world. There are over 220 billion lines of COBOL in existence, a figure which equates to around 80% of the world's actively used code. There are estimated to be over a million COBOL programmers in the world today. Most impressive perhaps, is that 200 times as many COBOL transactions take place each day than Google searches - a figure which puts the influence of Web 2.0 into stark perspective.
Every year, COBOL systems are responsible for transporting up to 72,000 shipping containers, caring for 60 million patients, processing 80% of point-of-sales transactions and connecting 500 million mobile phone users. COBOL manages our train timetables, air traffic control systems, holiday bookings and supermarket stock controls. And the list could go on.
I have a hard time reconciling this data point with the fact that I have never, in my entire so-called "professional" programming career, met anyone who was actively writing COBOL code. That probably says more about my isolation as a programmer than anything else, but still. I find the whole situation a bit perplexing. If these 220 billion lines of COBOL code are truly running out there somewhere, where are all the COBOL programmers? Did they write software systems so perfect, so bug-free, that all these billions of lines of code are somehow maintaining themselves without the need for legions and armies of COBOL programmers, decades later?
If so, that's a mighty impressive feat.
And if COBOL is so pervasive, why is it number one in this list of dead (or dying) computer skills compiled in 2007?
Y2k was like a second gold rush for Cobol programmers who were seeing dwindling need for their skills. But six-and-a-half years later, there's no savior in sight for this fading language. At the same time, while there's little curriculum coverage anymore at universities teaching computer science, "when you talk to practitioners, they'll say there are applications in thousands of organizations that have to be maintained," says Heikki Topi, chair of computer information services at Bentley College in Waltham, Mass., and a member of the education board for the Association for Computing Machinery.
When you dig in and read about some of these real world COBOL systems, you can get a glimpse of the sort of difficulties they're facing.
Read says Columbia Insurance's policy management and claims processing software is 20 years old and has 1 million lines of COBOL code with some 3,000 modifications layered on over the years. "Despite everyone pronouncing Cobol dead for a couple of decades, it's still around," he says. "We continue to enhance the base system. It's still green-screen, if you can believe that."
Read says getting younger workers to take on Cobol chores is a "real challenge, because that's not where technology is today." He simply tells them they must do some Cobol work, promising a switch to other things at the earliest opportunity.
Remember how the common language runtime of .NET promised rich support for a plethora of different languages -- but none of that ever mattered because everyone pretty much just uses C# anyway? Well, that CLR didn't go to waste, because it is possible to write code in COBOL.NET.
See for yourself.
private void button1_Click(object sender, System.EventArgs e)
button1.Text = "Call COBOL";
That was C#, of course. Here's the COBOL.NET version of same:
METHOD-ID. button1_Click PRIVATE.
01 sender OBJECT REFERENCE CLASS-OBJECT.
01 e OBJECT REFERENCE CLASS-EVENTARGS.
PROCEDURE DIVISION USING BY VALUE sender e.
SET PROP-TEXT OF button1 TO "Call COBOL".
END METHOD button1_Click.
Is there anything I could write here that the above code doesn't make abundantly clear?
COBOL: so vibrantly alive, yet â€¦ so very, very dead.
Posted by Jeff Atwood
I've been maintaining a legacy accounting system here for about 20 years and an equal number of years of threats to migrate it. Long live the mainframe!
I've done a little contribution to liberating the world of COBOL domination :)
A couple years ago, I was asked to re-write a cobol Sales Forecasting program into ABAP (because they would phase out the mainframe and move to SAP completely).
Since nobody could lay hands on the original source code or specs, we had to do a 'black box' rewrite, but I'm told that it works pretty well :) (even though it took the users a lot of time and brain rewiring to adjust to the interface change)
I would put COBOL up against ANY language for processing high volumes of transactions, batch processing, or record/transaction oriented processing. Pick your platform Windows, Linux, or Unix...(I didn't mention the mainframe because its no contest).
Pick your language: C#, VB.NET, and especially Java.
I can also take quite a bit of 30 year old complex subroutines and recompile as managed COBOL code...and call it from a managed COBOL .NET class or COBOL.NET WPF, WCF, ASP.NET, WinForm based application...if I choose to go Windows and .NET.
Also see what happens when you take VB 6.0 and compile it in Visual Studio 2003, 2005, or 2008.
I think the thing that is most obsolete in this author's article and some of the comments is the knowledge of what role COBOL plays and what it is capable of TODAY.
oh..one more comment. I heard in the 70s that COBOL was dead or dying soon...that C, C++ were going to rule...then again in the early 80's that Pascal was going to be THE language...then in the 90's it was Powerbuilder and Java.
In 15-20 years...there may be some brand new languages and a few that have lasted, but one of them will be called COBOL.
To all those that claim these 'new' and 'fantastic' programming languages are all so brilliant that you can code in 5 lines what you need 100 for in COBOL are missing the point completely.
COBOL is fantastic at describing serialised and logical data.
It is fantastic at producing rapid transaction based functionality.
It was a core language that compiled down to exectuable, even middleware systems were 'linked' into it so that object code was executed. COBOL ran on systems that were stable and reliable meaning a high level of confidence in the portability of the code.
Today with modern language and Bill Gates O/S methodologies in play, you get none of these.
You can write a piece of code this afternoon in any 'modern' language, go home, sleep, and then arrive for work the next day and wonder what the hell you were smoking the previous afternoon as you cannot fathom your own code.
This does not happen with old dinosaur COBOL. What part of ADD DAILY-INTEREST TO END-OF-DAY-BALANCE GIVING NEW-CURRENT-BALANCE is difficult to comprehend as a measure of programmability. Compare that with all the typing and casting you have with modern languages all attempting to uniquely control a bloated GUI or classifying data types into lists.
It is about time that the PC development guru's worked out that they need an encapsulated layer that takes the GUI away from the programmer so that he/she can concentrate on functionality and not form.
Until then, people will still rely on COBOL, and require new COBOL be written. It's future is assured for the very reason that so much has been created to do the same, there is no standard; VB (various incompatible versions), JAVA (again multiple incompatible versions), C, C++, C#, Delphi ..... Even old 4GL's have tried to adapt to the GUI such as Pro-IV.
Any programmers that has joined the industry within the last 10 years and have never seen/used/coded in COBOL, ask yourself this, what part of the code you have written in the last 10 years will still be in use 10 years from now? This asked by a man who last year recompiled over 1000 COBOL programs to pick up a DB extension runtime and had to regression test all of them. Some (well above 10%) had not been touched for almost 30 years. They were re-compiled, were re-linked, and with absolute rare exception the vast majority worked without issue. Try that now by getting a windows 3.1 program working on VISTA or Windows 7.
thanks and greetings from germany
"Did they write software systems so perfect, so bug-free, that all these billions of lines of code are somehow maintaining themselves without the need for legions and armies of COBOL programmers, decades later?
If so, that's a mighty impressive feat."
If so, they should have written Vista in COBOL!! :)
After reading most of the comments it seems there are a couple misunderstandings. First, the statement about 220 billion lines of code does not necessarily mean that all 220 billion are actively used nor that it makes up 80% of current code.
The second most important thing deals with longevity. Cobol was built in an era where the companies / programmers had complete control of the desktop. There was no such thing as upgrading the dumb terminal, except to replace a broken one because the green stopped. ;) This, more than anything, is what continues to contribute to 30+ year old applications still humming away.
Today's languages deal with a very hostile desktop environment. Sure, a company can control whether they have XP or 7 or whatever the OS is.. However, ALL of the current OS manufacturers issue updates with a high frequency rate. Further, you have no idea if that new accounting package is going to require an upgrade to the browser. Which it might, and therefore cause a break in that cool activeX thing you wrote. And god forbid if you deploy web apps that the general public can use in some capacity.
The point is, current apps have a built in "expires" date for no other reason than the OS and Browser manufacturers constantly update their software due to ongoing security and maintenance concerns. Incidentally, this is a leading reason for the high degree of failure in the development of internal applications.
With that in mind, I firmly believe Cobol will be around as long as they can find people to jump in. And, I'll admit, the hourly rates are very attractive.
“The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.”
-- Edsger Dijkstra
What genuinely irks me about this whole deal is how folks can say (A) to one group of people, (NOT A) to another group of people, and somehow sleep well at night.
Case in point: COBOL is dead, you should learn a man's language, like Java. Get modern, or get out. Yadda yadda. Yawn.
OTOH, OMGWTF are you doing re-inventing the wheel? We have libraries for XYZ you know. You should use the libraries instead! Stop trying to be so arcane about this stuff.
Knowing that languages and libraries are essentially identical from a semantic point of view, how *DARE* you try to convince me that folks should abandon their use of COBOL when you, the very same group of people, turn around and try to convince me that re-inventing the wheel is such a bad thing that I'll go to hell for eternity for it.
Give me a break!
We re-invent the wheel all the time. When was the last time you saw a wooden wagon wheel attached to an automobile axle? When was the last time you saw a family member use a Michelin to roll dough for a baked good? When was the last time you attempted to attach two pieces of wood together with a ball-bearing? (A screw = wheel + inclined plane, if you'll recall, so the example fits.)
Re-inventing the wheel isn't necessarily a bad thing. Just as there are millions of different kinds of screws, ball bearings, flywheels, etc. that you can order from a parts catalog, so too should there exist a gazillion different, custom-tailored software components too. If some of these components are written in COBOL, who gives a flying fsck?
COBOL, Java, BASIC, et. al. are all systems of notations -- if they excise your ability to think critically about software development, that is purely a reflection of the programmer, not of the language used. I'm huge follower of Djikstra's advice about being able to formally prove software on-demand -- but I vehemently disagree with his attribution that BASIC, and languages like it (including but not limited to Fortran and COBOL) warp the mind.
What warps the minds of coders are those who program in OO without knowing why said OO techniques exist in the first place, and therefore have **NO** context with which to judge when OO is really appropriate for the task at hand at all. Hence, all the Java bloat.
Shut up, leave COBOL alone, and go back to being productive, please. I'm so sick and tired of hearing this bullcrap.
I find it amusing that Web only programmers claim COBOL's dead because they don't see it. I haven't programmed COBOL since the 80s, but know just how pervasive it is for so many transactions.
Anyone doing anything in enterprise software, data warehousing or any related business process knows just how important it is to ensure you understand and link your legacy data from mainframes, older Unix systems (yes, kiddies, it's not just IBM, HP & Sun...) and other sources of critical information.
In fact, one of the reasons the mainframe isn't dead is that IBM gave them the ability to run Unix and Linux partitions in order to make it easier to access multiple information sources.
Saying COBOL is important doesn't obviate the importance of .net, C-- (oops, I mean C#) and other more recent tools. However, it's also true that the group of Linux clouds in no way minimizes the amount of mission critical information still running in COBOL today.
I don't know while comparing the lines of code COBOL takes vs the lines of code C# or any other modern language takes has some screen function as example always. For click of a button, I will not use COBOL. It is used for common business functions. It will take a single statement to compute 2 + 2 or to compute the annuities and all as any other common language. COBOL is not supposed to run your Internet site. Each language is supposed to do the job efficiently for the purpose it was invented. I will never use Perl scripting for system level programming or even for "Click Button". Translating the complex business logic written in arcane English is much easier to code in COBOL than in any other langauage because it is so much like English.
We have been hearing that COBOL is dead for almost 15 years...and it is still 15 years to completely wipe out COBOL from the planet (as most of the people are predicting). This makes it 30 years. I don't know if an MS technology has run for even a decade!
Where did those statistics come from? They sound like the protests of a man on his way to the gallows to me.
A professor of mine used to say that COBOL has A.I.
Don't see COBOL? Then you need to get out more. When you get away from teh Intarwebs, startups, game shops and step away from the Linux/Windows wars, there is a lot of old technology still floating around.
In the post-Y2K era I was tasked with re-training groups of COBOL programmers to do something more current like CGI programming. A lot of my students got sucked right back into the COBOL world because it's so damned lucrative and steady.
There's a lot of inglorious code running out there that everyone forgets. Your bills (phone, cable, water, taxes) were all processed by something, and it sure as hell wasn't written in C#. And the web site for your bank is probably written in something cool (for 2003, like Java), but the system grinding away in the background to auto-pay your bills through ACH isn't. If you take your car in for repairs and the dealer needs to order a part, that system is not written in Python. Or Haskell. Or Erlang. (What's the flavor of the month, this month?)
It's a lot like real life. Not everyone can be doctors or lawyers or Software Engineers. Someone has to clean your office bathrooms, get the dent out of your fender, and fish your dinner out of the Fryolator.
Hey Jeff, you probably didn't meet them because COBOL programming isn't done in Silicon Valley or New York or any other high tech arena. Alot of its done where I live.
If you'd like to meet some COBOL programmers, I can introduce you to the 3000+ COBOL programmers that I work with here in Columbus, Georgia.
Why all the fuss? the code you write today will be tomorrows legacy code. At least with Cobol an CICS its a relatively standard and available environment.
Wait until the systems developed during the 4GL fads of the 80's and 90's start faililng. Things like Unisys Mapper, dBase 2, Clipper 87, Powerbuilder, Cold fusion, Delphi and the like.
1 Million COBOL programmer? Are you having a laugh?
I did a search for COBOL jobs in New Zealand and only found one match. By comparison, there are hundreds of jobs for .Net developers.
Being a COBOL developer is a recipe for career death.
WHY IS IT ALL CAPITALS? MY HEAD HURTS NOW.
COBOL is not going away any time soon.
- Cost of converting the 10.5 million lines of production COBOL code.
- Finding a system to replace COBOL running on IBM Mainframe(s)that has the ability to process 800,000 stock market transactions at market open in less than 1 minute.
An ex-COBOL Developer with 10years of experience,I had to develop in Delphi and then .NET on the side to keep my sanity.
Very young compared to most COBOL Developers 40
Where there is death, there is life.
If indeed all that code needs maintaining and no one is here to maintain it, those who LEARN it become invaluable.
Could actually be a good career move.
Large new reengineering projects don't failing multiple times because of what language is or isn't used, smug comments to the contrary. Projects like that fail because the problems they are trying to solve are extremely complex.
The key reason why an older system can keep chugging along in a complex environment, while boil-the-ocean reengineering projects fail, is that the legacy system has evolved into its niche. It embodies more detailed knowledge about the enterprise than any one person has.
The specific reasons for any new, large project's failure can usually be tracked down: inadequate business analysis, software development management blunders, interference from the pointy-haired ones, engineers with technology fetishes. But those are details. The main reason is simply that the legacy system knows more about the enterprise than you do.
Well, it's obvious that COBOL syntax isn't that friendly.
However, it is far and away the best language for batch processing, i.e. importing a file, sorting it and updating some table.
I worked on a job a few years ago, C++, 6 month contract.
Could have done the whole thing in COBOL is 2 weeks!
Trust me, it may be out of fashion these days, but it is damn good at what it does!
First of all, let me put this clear: I'm not a Cobol programmer. I'm an .Net/J2EE architect with both Java and C# certifications (among others). I don't need to believe that there are many Cobol programmers outhere, I know that. I work in a company that cannot hire all Cobol programmers that it needs.
Regarding the low number of positions on US for Cobol programmers, that's pretty easy to understand: all those Cobol jobs went to India, Brazil or China (I live in Brazil, so I know what I'm talking about).
I agree that Cobol is a pain in the ass, but don't you go that fast to discredit OO Cobol. It is verbose for sure, but the logic part of the code is pretty amazing the same as for C# or Java. Don't you believe me? Take a look in this excerpt below to digital sign an XML file:
set emptyString to StringEmpty of SystemString
invoke ClassCspParameters "NEW" returning cspParams
set KeyContainer OF cspParams to "XML_DSIG_RSA_KEY"
invoke ClassRSACryptoServiceProvider "NEW" using cspParams returning rsaKey
invoke ClassXmlDocument "NEW" returning xmlDoc
set PreserveWhitespace of xmlDoc to b"1"
invoke xmlDoc "Load" using "c:\test.xml"
invoke ClassSignedXml "NEW" using xmlDoc returning signedXml
set SigningKey of signedXml to rsaKey
invoke ClassXmlReference "NEW" returning xmlReference
set uri of xmlReference to emptyString
invoke ClassXmlDsigEnvSignatureTrans "NEW" returning env
invoke xmlReference "AddTransform" using env
invoke signedXml "AddReference" using xmlReference
invoke signedXml "ComputeSignature"
invoke signedXml "GetXml" returning xmlDigitalSignature
invoke xmlDoc "ImportNode" using xmlDigitalSignature, b"1"
set xmlElement to DocumentElement of xmlDoc
invoke xmlElement "AppendChild" using xmlDocChild
invoke xmlDoc "Save" using "c:\SignedTest.xml"
The number of lines to perform the logic is almost the same as for C# (if you don't believe in me take a look in the Microsoft sample to do the same task in C#: http://msdn.microsoft.com/en-us/library/ms229745.aspx).
My point is that Cobol is evolving, and to believe that it would fade away in a near future is not only a mistake, but a recurrent mistake done in the last decades by IBM (PL/1), Nantucket(Clipper), Powersoft(Powerbuilder) and Microsoft(VB/Foxbase) just to name a few...
I do believe that the part of an existing Cobol code that should exposed data to the world should be done by OO Cobol, so you would not ended up with aliens languages trying to communicate with legacy (Java JNI for instance...what a mess) or relying on text files import/export (ugh), EAI (2x ugh) or something like that.
To code a web services in OO Cobol is not only convenient, but also easy to do. There are many compiler options of OO Cobol out there, being Fujitsu one of most impressive.
One of my projects it to create a website with examples of how to do GoF patterns (all 23), RIA with Flex, webservices etc all with OO Cobol. Why? Not only because it is possible, but because this is the way it should be done from a business perspective, and also to make younger programmers get involved without feeling that he/she is wasting their time on this planet. An Abstract Factory is the same, no matter the language...
Again, I do not work with Cobol, I just realized that it still has a long path ahead, and I want to use the best tool in each part of my projects, and not replace one with another compromising scope, responsibilities and, in the end, schedule and budget.
Architects golden rule - keep the stakeholder happy, stupid.
No one's posted to this thread for some time so I'm probably speaking to an empty room, but its a Friday so why not waste some time.
I'm a COBOL programmer. I learned the language back in 1971, and I've been making a living with it off and on ever since. Mixed in during that time I've worked in 17 other languages.
COBOL is my language of choice, but I'm a native english speaker, and COBOL was designed first for the english speaking world, and 'secondarily' for the oxcidental thinkers of the world.
If you want to understand structure the various computer languages you need to examine the environment/society from which it sprung.
English verb , adverb, object
COBOL verb, qualifier, field/record name
One other thing.. one of the old posts bragged about the brevity of the 'modern' languages compared to COBOL. You sir/madam are forgetting the library of object, methods, utilities, interpreters, functions, etc. that has to be drug along with your three lines of C# or .NET code.
Without that 'standard' library your modern language is useless.
COBOL code is still around not because guys like me are resisting change, it's still here because nothing better has come along.
COBOL is verbose, because it needs to be. If your modern language doen't describe the data in the same detail, you left something out.
i gottta take one cobol course in school. anyone know a website or person that will accept payment to do assignments?
COBOL is Dead, Long Live COBOL!
If you do not wish or do not have time to read the following then visit COBOLonWeb.com; See COBOL in Action on the INTERNET like you have never seen it before! Also visit COBOLGoldMine.com to learn more.
COBOL is dead? Right. So is the Explosion Engine that powers individual, commercial, industrial and military vehicles....and the electric car is here to rules the world's roads and highways....
Why waste all your mission-critical business COBOL applications in which you have invested so much during decades to stay ahead of the competition?
Why rewrite them using one or a combination of those fragile, slow and inefficient languages that pop up almost every six months? Your worst nightmare is to find out after all the time and money spent, that these immature languages are not meant for business mission-critical applications.
Why keep that prohibitive Mainframe just to run your COBOL Batch and Online applications when you could use more cost effective Windows or UNIX Servers to reduce a significant part of your IT overhead and still have your business-critical COBOL systems perform in state-of-the-art GUI and Internet environment and RDMBS such as SQL Server?
Still in doubt? Experience COBOL in Action at COBOLonWeb.com and believe...The rest is easy.
Legacy, eBusiness, eCommerce et alia.
COBOL has been running on more computing platforms than any computer programming language worthy of this name; from Mainframes, to mid-sizes to minis to PCs to Intelligent Cash registers, even handheld computers and scanners much used in the retail and manufacturing industries.
COBOL has also been performing on more Operating Systems than all other past and present computer programming languages combined.
So what is so special about the latest Information Technology "platform" baptized the INTERNET? ...Nothing! The Internet is simply a wide and open highway where COBOL feels right at Home.
One last remark: COBOL is too verbose? Too wordy? Here is the fact: COBOL was created to be self-documented programming language. It is the one and only of its kind. Any genuine COBOL programmer knows that one could write either:
COMPUTE NB = CB - W.
Any Maintenance COBOL Programmer can appreciate the first style not the latter.
At COBOL Gold Mine, we think differently.
Half of our workforce is working in COBOL. Ours is a software service company with strength over 10000.
The COBOL language can be learned easily. When compiled, a COBOL program can become memory efficient and can execute very fast. The feat is understanding the applications. Oftentimes, there are thousands of lines of code wherein all that can be seen is the passing of values. COBOL programmers are extraordinary because they can make sense out of these hundres of thousands of lines! I am an ERP programmer of a system that has COBOL applications for its engines - the most critical parts. Very robust and efficient, did not experience a major fix. On the other hand, the use of the friendlier programs for the more visible functions such as the pages, reports or processing, were the ones that needed most of the fixes and performance tuning.