a companion discussion area for blog.codinghorror.com

COBOL: Everywhere and Nowhere


#201

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!


#202

yes exciting


#203

I’ve done a little contribution to liberating the world of COBOL domination :slight_smile:

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 :slight_smile: (even though it took the users a lot of time and brain rewiring to adjust to the interface change)


#204

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.


#205

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.


#206

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.


#207

thanks and greetings from germany


#208

"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!! :slight_smile:


#209

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. :wink: 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.


#210

“The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.”
– Edsger Dijkstra


#211

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.


#212

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.


#213

The Register recently ran an article entitled ‘Undead COBOL celebrates (another) 50th birthday’ which referenced a DataMonitor report on the current use of COBOL. It continues to quote the 220 Billion lines of COBOL code figure, claiming that these are used in live systems and that 5 Billion lines of new code are added annually.

The links are:

http://www.theregister.co.uk/2009/09/18/cobol_name_birthday/

and

http://www.microfocus.com/000/COBOL_continuing_to_drive_value_in_the_21st_Century_tcm21-23652.pdf [PDF]


#214

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!


#215

Where did those statistics come from? They sound like the protests of a man on his way to the gallows to me.


#216

A professor of mine used to say that COBOL has A.I.

Artificial Inelegance.


#217

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.


#218

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.


#219

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.


#220

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.