COBOL: Everywhere and Nowhere

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.
DATA DIVISION.
LINKAGE SECTION.
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
231 Comments

I'm 56 years old. I write desktop applications for Windows and lately for the Mac also using Flash.

My dad was a COBOL programmer.

Do the math.

Jim Howard on August 10, 2009 10:15 AM

My employer (a major health insurance company) has three different programming camps: COBOL, Java, and .Net. The COBOL coders keep churning out new code and that code works through millions of claims per day. The company lists a couple of COBOL positions per year.

Bruce W on August 10, 2009 10:25 AM

I learned COBOL in school on an AS/400... I hated the class hated the language but after working in the field for a few years with all these new wiz bang languages that they keep churning out to make programming easier... I have a new found appreciation for COBOL and the AS/400 that I didn't have at the time. It's reliable with COBOL 1+1 = 2 always always always always.... these new easier to program languages 1+1 might equal 2 or your web server might go down.

How often do you actually get to go back and re-factor, re-write something?? lets face it more often than not... unless you can convince your manager or tie some real dollars and cents to it, it's not going to happen. The most likely scenario you write some quick and dirty code that you know is dirty... but it gets the job done... you deploy it forget about it and when you're ready to re-write it... management has changed, the company has changed focus and you end up scraping it anyways.

anonymous on August 10, 2009 10:31 AM

I removed COBOL from my resume so I wouldn't get stuck working in it again. I bet you have met many COBOL programmers but just don't know it. Most don't advertise it.

And if you are interested in seeing if there are any jobs for COBOL just put it on your Monster or Dice profile (resume) and see what happens.

Jeff on August 10, 2009 10:45 AM

COBOL does not create "bug free" code but if the code compiles you can be pretty sure of what it does by reading it. The environment it tends to run in, the mainframe, also tends to encourage correctness in the implementation of code. The compilers are rock solid as is the library code.

Once you "get it right" it does not need to be changed and things are very well defined. You just don't get that in "modern" systems.

AL on August 10, 2009 10:47 AM

Ada is hardly a dead language, just the same as COBOL (although, obviously, COBOL is far, far more in use).

The verbose programming languages have a distinct advantage in that the notion of self-documenting code is almost a reality with them. COBOL is used almost everywhere in the DP world, and Ada is the primary military language throughout the Western world. Also any other mission-critical real-time system will be using Ada.

But why think of it like that? Is C going away? Is assembler? There are some languages that will forever stay around. I daresay that in Y3K some form of BASIC will still exist...

Gregory on August 10, 2009 10:51 AM

COBOL is still around on mainframe systems. IBM and other businesses are scrambling to train new COBOL programmers, because too many "modernization" efforts have failed. Few non-mainframe databases can handle hundreds of terabytes of information.

Training press release: http://www.ccccd.edu/news/PressReleases/2008-09/20090422Cobol.html

Jeremy Gaither on August 10, 2009 10:56 AM

@Jim Howard: The only result of that math is that you chose not to do what your dad did.

TJ on August 10, 2009 10:56 AM

We, just last week, made a pretty funny YouTube video on Agile COBOL 2009: http://www.youtube.com/watch?v=ELdYYE2F7F0

Jeff might pick up some pointers on agile development at the same time!

Mik Lernout on August 10, 2009 10:58 AM

Assuming I started learning COBOL now, How would I know when I was prepared for a job writing COBOL? and how would I convince anyone else?

james.andrix on August 10, 2009 11:06 AM

Firstly let me be clear my entire 15 year career has predominately been in Microsoft technologies BUT the reality is ...

1. COBOL is everywhere!
2. The entire financial services industry (at least insurance and retail banking) run on it - Yes they are green screen!
3. It's incredibly difficult to recruit good COBOL designers or developers in the UK
4. It's easy to recruit good COBOL designers or developers in India
5. The investment that would be required to rewrite has no business case when requirements or application driven
6. It will only start being decomissioned once the cost / upgrade path of the infrastructure becomes too difficult to maintain
7. There are many advantages to the technology that cannot be expressed with an example of language syntax
8. Systems referenced in the comments almost account for the 220bn lines!

JF on August 10, 2009 11:24 AM

Like others here I took Cobol in college and it was a nightmarish experience. My prof. was completely incompetent so it was *very* challenging to learn anything from her. The programs were just so VERBOSE that I had a hell of a time breaking things down to a level of familiarity and comfort that I had with C++. I actually had a much easier time picking up more compact languages like C/C++ and Lisp, go figure.
Also, about that 220 billion lines of code figure I can guarantee that if that code was rewritten in C the line count would go to 220 million lines of code easy if not smaller. Using an automated translator like Mecki suggested is an excellent idea to rid the world of this verbosely written scourge.

o.s. on August 10, 2009 11:34 AM

No. Cobol -- despite our best attempts -- still lives on.

If you want to talk about dead languages, talk about Ada. There main development webpage hasn't been updated in two years: http://www.adahome.com/.

David W. on August 10, 2009 11:44 AM

Steven Howes,
University of New Brunswick? I took a COBOL course there in 99.

Tim B on August 10, 2009 11:45 AM

I got a job right after graduating as a mainframe COBOL programmer for a large financial processing company - 3 years ago. I like it.

privatehuff on August 10, 2009 11:56 AM

Those heaping scorn on COBOL as a stupid language merely display their ignorance of why and how it was designed. As someone else commented, "the B stands for Business"; it was designed for use in Business systems, with maintainability a major concern. Truism: no matter how elegant the code is, if you can't read it you can't modify it. Those 'extra' lines of code cost a (little) bit more to write in the first place, but they pay for themselves many times over as they help later programmers understand the design.

I started with Algol and Fortran, naturally despising COBOL as a language for dummies. Then I took a job managing a corporate COBOL shop. What I soon learned was that the structure of COBOL, in particular the rigidity of the DATA DIVISION, made it the easiest language there is in which to modify someone else's code.

Flexibility and rapid re-structuring are important for web sites, in the production and financial sectors you'll trade those any day for stability.

Dan Covill
San Diego

Dan Covill on August 10, 2009 12:15 PM

I actually started my programming career 5 years ago doing COBOL. I agree it is a huge challenge to get young developers into the language and about the only way is with promises of getting to work with newer languages. ( For me I got to work with Java after I was able to support our COBOL system. )

I'd say there was about 25 programmers supporting the application I worked on and most of the work was done performing firefighting on the existing code. I often wondered why there was no push to rewrite the system especially when processing of records was taking almost 2 days. If anything terrible happened there might be a need to restart the COBOL program from the start.

I think most COBOL is still around because as far as a business goes "it still works" even if it could be rewritten in a year or two and 20 COBOL programmers can be sent searching for jobs elsewhere.

Ryan Higdon on August 10, 2009 12:21 PM

I work for one of the largest companies in the world and there are tons and tons of COBOL programmers here. I fortunantly get to work with C# and Java for the most part, but COBOL is alive and well here. Tons and tons of new COBOL programs are being written daily.

LemmingRush on August 10, 2009 12:24 PM

If you haven't met met anyone who was writing COBOL (yet), just visit Elbonia:
http://www.bfmartin.ca/search/stripfinder/cobol

Roland on August 10, 2009 12:27 PM

@Dan Covill

"What I soon learned was that the structure of COBOL, in particular the rigidity of the DATA DIVISION, made it the easiest language there is in which to modify someone else's code."

I'm sorry but I really fail to understand how for example a 30000 line program with all the variables that have to be _global_ within DATA DIVISION is easy to modify. Trust me, whenever you want to change anything in such a program chances are you're gonna screw something else. For all of those that mention the beauties of COBOL have you ever programmed in a real programming language? In any other programming language? I'm working with a few COBOL programmers and I completely understand the point in Dijkstra's quotation. Once you start programming in COBOL it really rots your mind.

@Schnapple
"When something came up she didn't want to do, she'd just refuse to do it, or threaten to quit."

I completely understand that. After only a few years of programming in COBOL people are unable to grasp any concept that does not exist in COBOL. OOP? Refactoring? Local variables? SQL? It's only flat files and spaghetti programming in COBOL programmer's mind. Reusing the objects? Try writing procedures (functions are too advanced concept) for every little thing that you need. Need to copy, trim, concatenate or do anything to a string? Write your own procedure. And then copy-paste it everywhere you need. Need to do anything that every other programming language has a set of pre-made functions or objects for? It's roll your own procedure in COBOL world! And that's how we come to 220 billions of lines of code. It's crap and unnecessary stuff for 90% of that! What you do in one line in most of programming languages it's 30-40 lines in COBOL.

Dragan Matic on August 10, 2009 12:33 PM

"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."

I think I might know why that is -- when I was in university, I ended up doing a 4 month Co-op position in the IT department of a large international grocery store chain. They ran everything through COBOL with no plans to migrate away from it -- I even worked on some code that originated before I was born. A bunch of us students started at the same time as a bunch of new hires.

What was interesting about these new hires is that none of them had any computing science background. None of them were professional programmers. For the most part, they were blue-collar workers in their late 30's who were looking to move into white-collar work. They were were trained entirely by the company specifically for this job. So they weren't COBOL programmers when the started, the training they got is specific to the company which so heavily promotes from within. I think that makes them pretty much invisible to you.

AlmostAlive on August 10, 2009 12:36 PM

At my college the Comp Sci majors got to play in C++ and Java and the IS majors had to take COBOL. I assume they all got stuck doing COBOL while I enjoy doing C# every day.

As far as your code sample I didn't even attempt to read it. Some good advice is to never learn or do anything you don't want to be pigeon-holed into doing. If you don't want to do COBOL make sure you don't know COBOL.

Billkamm on August 10, 2009 1:07 PM

COBOL is still out there and rumours of it's death, or even retirement, are very premature. At the very least it's utterly pervasive in the big payroll world. I'm slightly suspicious of attempts to move old COBOL code to a new platform or environment. This is code that works, you don't mess with it. At the same time I wouldn't touch the language with a 10 foot pole these days.

mh on August 10, 2009 1:19 PM

I spent the first six years of my career programming in COBOL on what was then a new system (in 1990). We were very mindful of sticking to good coding standards, and I don't feel at all sullied by the experience. Because of its English-like syntax, good programs often documented themselves. Indeed, it was originally designed to be a reporting language for non-programmers.

Of course, I prefer doing C++ and Python these days, but if I had to I could do COBOL again it wouldn't kill me.

And if you're a scripter and savvy with ISPF Edit and REXX, the development environment is not as miserable as these no-COBOL-knowing babies would say it is.

Michael Mabin on August 10, 2009 1:19 PM

You definitely have to look at the enterprise. I work for a Fortune 500 in the financial services industry. Enterprise wide, I'm guessing that we're now up to even split between .Net and COBOL. The bugs from two decades ago were either ironed out already or (something I've seen frequently) people just adapted to working around them, and forgot that the bug even exists.

sfuqua on August 10, 2009 1:20 PM

I'm 27 now and have been making a living as a COBOL programmer for 6 years now. Trust me, there is PLENTY of work coming down the pipe!

Dustin on August 10, 2009 1:23 PM

Obviously the perfect language is not needed to build enterprise systems that last decades. And I am no COBOL fan.

In a way, our condition today is a sad commentary -- that despite so many new technologies there are so many software project failures, and so much code that gets written and then put on the shelf.

Steve on August 10, 2009 1:30 PM

I actually know one COBOL programmer: my mother. She's still very much in demand :-)

Frances on August 10, 2009 1:51 PM

The Social Security Administration has a significant COBOL program inventory. 12,500,000 lines at one time - don't know how much now. I was fortunate enough to escape the COBOL batch mainframe world at SSA and now work in Java, but we are small in number compared to the number of COBOL programmers. I guess I'm one of the "old" people you youngsters are so disdainful of.

Barbara on August 11, 2009 2:23 AM

About size of COBOL code; I'm repeating a bit what others already said in comments, but if I remember correctly (I don't have this book by me, unfortunately) Jon Bentley in "Programming Pearls" described an example where rewriting code (IIRC for telephony system), which was originally in COBOL, in modern programming language with dynamic structures, reduced code size one or two orders of magnitude (10 or 100 times smaller), and make it much easier to maintain and extend.

It's not only excessive verbosity of COBOL, but also lack of modern programming concepts, which means workarounds and repetitions. So divide those alleged 220 billion (10^9) lines of code by 100 (or more) for comparison with more modern codebase.

Jakub Narębski on August 11, 2009 2:36 AM

@o.s. "Also, about that 220 billion lines of code figure I can guarantee that if that code was rewritten in C the line count would go to 220 million lines of code easy if not smaller."

Ya. Right. Each 1000 lines of COBOL would be one line of C....you really really think that? I mean.....realllllllly?

Anonymous on August 11, 2009 2:41 AM

COBOL vs Java? Java is also wordy and overblown, everything has to be a noun, functions can't stand on their own.

Java is just as bad (if done badly).

If you ignore all the declarative stuff it's just code once you get to it. I doubt the line count compared with Java would be that different.

I wrote COBOL 20-odd years ago, it's just a programming language.

Francis Fish on August 11, 2009 2:59 AM

COBOL hating isn't new. My dad had a picture of the COBOL gravestone taken when we visted the Boston Computing Museum back in 1998. The gravestone was presented to one of its creators back in the 50s, presumably by LISP programmers.

redteddy23 on August 11, 2009 3:03 AM

"I'd like to talk to you about ducts." - Gee, thanks, now I have to go watch "Brazil" again...

And what, *nobody* else got that???

Penguin Pete on August 11, 2009 3:19 AM

@Anonymous
Not directly I exaggerated a bit as a joke but its plenty bad. Modern languages make it easier to facilitate proper code reuse and makes it easier to create a reusable library of code. To be honest, C++ would be the best choice to cut down on the lines of code count since it has better OOP features but C could do some of the job.Fact is COBOL forces devs to recreate the wheel on a regular basis on top of its extreme verbosity which contributes mightily to its lines of code count. For all the COBOL lovers out there, their isn't any magical properties of the COBOL language that makes it more maintainable. It's all in your imagination, COBOL sucks and makes you work too hard to build simple systems.

o.s. on August 11, 2009 3:30 AM

Where I work (a large relocation and moving company), many of the systems are still based on the mainframe. Half of the code or so is COBOL that's been updated and modified since the 70s - the other half is a mix of Adabase and a dozen or so other archaic languages - totaling nearly 6 or 7 million lines of COBOL code. We're just now in the process of converting from the mainframe to a SQL Server/C# environment (through an automated tool that is going to cause massive, massive headaches), but even so, some of the code is being converted to COBOL.Net, which is going to keep the COBOL legacy going for years more to come. The cost of the conversion from old-COBOL to new-COBOL is still going to be far less expensive and time consuming that trying to rewrite the entire set of systems in something newer, and we plan to update sections of the code over time. People don't like the change, and older languages stick around for a loooong time.

Brian on August 11, 2009 5:26 AM

My mother coded COBOL for Philip Morris for over 20 years. Even today, entire contracting companies focus on maintaining, and yes... building new systems in COBOL for said company.

You have to remember... not everyone that codes is trying to ride the technological wave. Many COBOL programmers came to the market straight out of high school and saw it as a job no different than any other.

Jim on August 11, 2009 5:28 AM

I started a job in the finance sector programming in Cobol/Cics/Db2 back in 1995, and had people tut-tut my choice of a programming language that would be dead in 2-3 years, or 5 on the outside because surely, all companies would have replaced their old Cobol code before Y2K!
14 years later, and I'm still happily working with the same languages while some of the tut-tuting java programmers are drawing unemployment. (For fun, I also use some java/ruby/"programming language of the month" on minor tasks -- this as an aside to those who blithely assume that Cobol rots the mind. To a good programmer, a language is a tool, not a religion, and which one you use rarely matters as long as you wield it with skill.)

Libra on August 11, 2009 5:54 AM

Cases where I've found Cobol programmers include banks and a couple of mid-sized corporations using outdated AS/400 systems. That's in Greece of course which is not so advanced as the US. But then if you think of it, there must be dozens of not so advanced countries where daily operations would be performed through Cobol programs.

costas on August 11, 2009 6:30 AM

Jeff,

Unfortunately you have fallen into the common trap of comparing bad COBOL with good C#. If you had written good COBOL using Micro Focus products it would look like this:

method-id. "button1_Click" private.
procedure division using by value sender as object e as
type "System.EventArgs".
set button1::"PropTest" to "Call COBOL"
end method "button1_Click".

Which has almost exactly the same number of syntactic elements as the C# version.

You have also chosen an example of something C# is very good at. How about something extremely useful and at which C# is not very good? How about writing large precision calculation software? This is the sort of thing that stock exchanges, banks and many other 'heavy lifting' applications have to do all the time. If COBOL is so clunky, show me how C# would do this (I think you will find you need a third party class library and a page of code to do what COBOL does in a few lines):

program-id. Program1.

01 a pic 9(30)v99.
01 b pic 9(30)v99.
01 d pic 9(30).99.
01 i binary-long.
procedure division.
perform varying i from 0 by 1 until i equals 35
compute a = a * 9 + i / 91
compute b = b * 9 + i / 101
end-perform
move a to d
display "First number " d
move b to d
display "Second number " d
add a to b giving d
display "Sum of the two " d

end program Program1.

Not only is this a simple and clean implmentation, it will compile and run native on almost any major platform as well as .net.

The point being that one reason COBOL has been around for so long because it does what it does very well. Not only that, but modern versions of COBOL do everything else well in addition.

The next generation of COBOL from Micro Focus will be able to do even more with even fewer syntactic elements required and even more features C# and other similar languages lack.

Best wishes - AJ

Alex Turner on August 11, 2009 6:57 AM

it's probably not your opinion, but it's more like comparing the iphone/every other phone with a straight forward oldschool calculator

what would you use to do some simple calcs?

cobol programs are often used in banks or companies like that

if you just have to put in a couple of numbers - and calculate them/or transfer them to other banks - which is actually pretty much what banks are doing - then cobol is far better than using a 4gl language

kajdo on August 11, 2009 7:10 AM

This goes back to the root cause of all legacy software problems in my opinion "All software should have a shelf life", "All software should come with an expiry date.".

fallenprogrammr on August 11, 2009 7:18 AM

80% of all code is COBOL? And to think it's inventor didn't even have a mustache - or did she?

Jeremy Neiman on August 11, 2009 7:52 AM

80% of all code is COBOL? And to think it's inventor didn't even have a mustache - or did she?

Jeremy Neiman on August 11, 2009 7:53 AM

"I have never, in my entire so-called "professional" programming career, met anyone who was actively writing COBOL code."

There are many young ( you don’t believe though) people who are developing / supporting COBOL code, for the bank / corporations around the globe (not only North America but all over the world) – can be found in INDIA.

There are 174 job post for COBOL developer every day on local job website.
http://jobsearch.naukri.com

Narayanaswami Vengaprasad Murthy on August 11, 2009 8:29 AM

Program1... I would be interested to know how well it compiles and runs in actual practice. My concern is that 9**36 should have at least 34 digits to the left of the decimal, and you only appear to have given space for 30. (The actual number will be higher than 9**36, of course, because of the variance introduced by 'i').

(I would also be curious about the bank that needs to measure decillions of *anything*, but hey, to each their obscurely large numbers, yes?)

Thomas Weigel on August 11, 2009 8:30 AM

That last was directed at Alex Turner. Sorry.

Thomas Weigel on August 11, 2009 8:31 AM

> (I would also be curious about the bank that needs to measure decillions of *anything*, but hey, to each their obscurely large numbers, yes?)

I'm not Alex Turner, but I'll reply anyways.

You must be joking. If you ever one day do development for a bank, you'll quickly learn that precision at almost any scale is da holly grail.

Mario on August 11, 2009 8:50 AM

@Narayanaswami Vengaprasad Murthy

The people who are developing / supporting COBOL code in India or anywhere else are a product of necessity and not out of self-interest or enthusiasm.

Given a choice they will gladly accept a newer technology.

fallenprogrammr on August 11, 2009 8:54 AM

The sample code you used to show COBOL code in .net is not typical for COBOL applciation , (NO GUI) .COBOL is used for modeling business and transaction. I worked in very large project using COBOL for 3 years, and I have been working with.NET as well recently.And I can guarantee you that working in businness transaction with .net is not compared to COBOL. COBOL seems to be more concise and more ATOMIC. I've experienced a situation where Green and black terminal are more usable and bug free than fancy gui with bunch of button.
(think command line vs GUI) I think more developper find command line more productive than GUI ,same apply to end users.

youssef Elatia on August 11, 2009 9:06 AM

Herb J: porting COBOL to C, way to go! From 1959 straight to the mid 70s!

Once your colleagues are done, I suggest Turbo Pascal.

rp on August 11, 2009 9:16 AM

There. It is done.

I wrapped the entire cobol thing in a single web service. You just reference the sucker and off you go. cobol forever.

securityhorror on August 11, 2009 9:29 AM

Forget COBOL.NET, we now have "COBOL on Cogs" keeping the language alive and up with the latest programming trends.

http://www.coboloncogs.org

James on August 11, 2009 9:59 AM

Thomas,

The program compiles and runs just fine. The overflow characteristics of the calculation are defined. However, increasing the size of the fields to 9(32)v99 gives this result:

First number 04302298532283486384640958153141.48
Second number 00043457560850577111133950902536.17
Sum of the two 04345756093134063495774909055677.65

Now, as to who requires large numbers like this? The following COBOL uses large numbers to compute the geometric mean of 5 tax returns to five decimal places. I realise it is a bit artificial, but it proves the point that high accuracy numbers can be required quite easily.

program-id. Program1.

01 a pic 9(28)v99999 occurs 10.
01 b pic 9(28)v99999.
01 d pic 9(28).99999.
01 i binary-long.
procedure division.
move 125621.23 to b
*> generate some numbers - these would be from a data source
*> in a real application
perform varying i from 1 by 1 until i equals 5
compute b = b * 1.11176
move b to a(i)
end-perform

*> compute the geometric mean
perform varying i from 1 by 1 until i equals 5
multiply b by a(i) giving b
end-perform

move b to d
display "Working variable " d
compute b = b ** 0.2

move b to d
display "Geometric Mean " d

end program Program1.

Which gives:

Working variable 0137870017292352733686651403.77949
Geometric Mean 0000000000000000000000169002.82570

As with any example, this one can be attacked, however, I believe it to be illustrative.

All the best - AJ

Alex Turner on August 11, 2009 10:13 AM

> As with any example, this one can be attacked, however, I believe it to be illustrative.

Or in the words of the great Knuth:
"Beware of bugs in the above code; I have only proved it correct, not tried it"

Mario on August 11, 2009 11:06 AM

> As with any example, this one can be attacked, however, I believe it to be illustrative.

Or in the words of the great Knuth:
"Beware of bugs in the above code; I have only proved it correct, not tried it"

Mario on August 11, 2009 11:06 AM

> As with any example, this one can be attacked, however, I believe it to be illustrative.

Or in the words of the great Knuth:
"Beware of bugs in the above code; I have only proved it correct, not tried it"

Mario on August 11, 2009 11:07 AM

sorry :(
Bad firefox.

Mario on August 11, 2009 11:09 AM

OK, no way am I reading 200+ comments, but I submit this:

Most of the COBOL workforce is retired, dead, or dying. There exists little to no interest in young Developers to go the COBOL route. Companies better start migrating, lest they find themselves in a pinch to find any COBOL people.

That said, the average salary for COBOL Developers (Sorry, "Programmers") is poised for a steep hike in the next decade or so.

Slackmaster K on August 11, 2009 12:10 PM

Euthanasia?

Sam on August 11, 2009 1:20 PM

@Dragan Matic

"For all of those that mention the beauties of COBOL have you ever programmed in a real programming language? In any other programming language?"

IBM Q7 Assembler, Philco 2000 Assembler, JOVIAL, ALGOL, FORTRAN, APL, BASIC, 8080 Assembler, C, dBASE 2, FoxPro, Visual FoxPro, and most recently Python.

Do I need more?

Dan Covill on August 11, 2009 1:48 PM

COBOL programs have decades and still service. No absolute way this can happen today.

Compare this with the stupid environment of today, where for a silly "Hello World" webpage there is need of a framework of 500 MB, developing tools of 10 DVDs, when it stops working there is no way to understand why, just reboot something.

COBOL comes from another era, where programmers used to use their brain, in front of a problem they tried everything before asking for help. Today, first reboot, then Google, then forums, then change everything simple like some configuration, then wait a day maybe it solves by itself, then think to solve the problem.
Once upon a time if a program did not work no one, repeat no one, ever thought maybe it is a compiler or operating system problem; today is the first thing we think.

For those here laughing at COBOL, it is like laugh at Egypt Pyramids, they are there from 5000 years and they still will be there in next 5000 years, while you and your "hello world" webpage needing 24 activex to work will be deleted, replaced, forgotten next month.

xlr8 on August 12, 2009 2:27 AM

Instead of doing Iphone development with Objective-C why not do somethings in Qt (with C++) instead? (link: http://qt.nokia.com/)
And Nokia looks good too!!!
Did you hear about the Iphone which exploded in some girls face? Apples are not my thing... I like rainboots more..

pukki on August 12, 2009 2:29 AM

The choice of computer languages has always been an emotional choice; more so if it is left to the programmer. However if the language is chosen by feature and requirements then COBOL has it place just like other languages. So until another language comes along with business style credentials, COBOL is here to stay.

You will find COBOL everywhere from the mainframe (with IBM etc).. to the mid-range/desktop with Microsoft/MicroFocus and Fujitsu.

Even Microsoft understand that COBOL is am important market that helps them..

I am sorry but COBOL is not dead, it is alive and kicking in the enterprise...

Long live COBOL...

ref: http://www.microsoft.com/presspass/press/2008/jul08/07-02EntAppModernizationPR.mspx

wibble.wobble on August 12, 2009 2:51 AM

I would rather program in COBOL than in Java.

COBOL has a proven track record of reliability and robustness, even if it can get a little bit wordy at times.

Java is the turd that just won't flush.

Peony on August 12, 2009 5:29 AM

>Or in the words of the great Knuth:
>"Beware of bugs in the above code; I have only proved it correct,
>not tried it"

Also code being proven to be correct can contain bugs:

- Ariane V
- Quicksort in Java

In both cases, code being proven to be correct was placed into a
different environment (reused code of Ariane IV, C to Java
conversion where an unsigned int became a signed int)


Cheers, Lothar

Lothar on August 12, 2009 5:53 AM

I'd just like to say that I love reading this stuff. I found this blog because of your Evony ads article and I enjoy reading it ever since!

Devroush on August 12, 2009 8:45 AM

COBOL programmers are still working hard at mainframe applications in Banks, Insurance companies etc. At least in the Netherlands.

dingoe on August 12, 2009 10:58 AM

We have some 50 COBOL Programmers who write code daily in our company, though i am a core C# programmer, daily i have to read through the 100s of lines of COBOL programs to understand the businiess logic of our product whose business logic is still in COBOL.

Pakeeru Shaik on August 12, 2009 11:57 AM

The COBOL programmers are all here in India Jeff.I work at a major financial services company and almost 80% is all work is still done in COBOL.

Hashname on August 12, 2009 12:15 PM

FYI: http://ldami.blogspot.com/2009/08/yapceu09-paper-on-managing-genevas-law.html talks about (ongoing) project of moving Geneva's law system from COBOL to Perl.

Jakub Narębski on August 12, 2009 12:54 PM

Yet again, blatant ignorance is spewing out of your keyboard at an alarming rate. Think before you post this shit, please.

Just because you, Jeff Atwood of Coding Horror, have never worked in an IBM shop or talked to a COBOL programmer, does not mean that COBOL is dead. If anything, it means you are dead to the real business world. You clearly have no idea how dedicated these IT veterans are to IBM and COBOL. And there's a legitimate reason for that: legacy. You can bet there are tons of bugs that spring up in older (sometimes 20-year-old) programs; enough to hire several full-time maintenance programmers.

My first job out of college was a COBOL programmer at an insurance company, and I still work there with the same people, although now I've moved onto primarily working on .NET and the web. Everybody here understands that the mainframe will always be the primary workforce of our company. That's right baby, green screens FTW! No matter how much you have to say about switching a different platform, nothing can handle the workload like a mainframe. Nothing. And there's nothing more secure, either. NOTHING.

We literally put the entire history (and in many ways, the future) of the company on the line when choosing a computing platform. Why would anybody switch from COBOL after it's been loyal for decades? Until you become a vice president of a successful IT department (in an actual business, not some pansy software development firm), you should not talk about COBOL because you sound utterly foolish. It is not going anywhere for a very long time, you can count on that.

And here's another thing you need to understand: computers were not made for people like you (with some insane OCD-level infatuation with upgrading). They were made for business purposes. Keep that in mind the next time you want to take shots at programmers who work in the industries that make the world go around.

Josh Stodola on August 12, 2009 1:06 PM

no one programs on a 10 year old computer.

so why program in a 10 year old language?

c# is just as dead as COBOL, it just happens to retain some zombie cred.

erica on August 12, 2009 1:16 PM

I program for a living and otherwise in Java, JavaScript, and Python, and I'm looking to get into COBOL - simply because I don't know it and there may be jobs in it. Languages are all interesting and all inconvenient. When I rode the boat from Istanbul to Odessa, I had to stop talking Turkish and start talking Russian, the former exotic and the latter impractical and neither of which I did well, but no regrets. They were just part of the geography. Travel geography, workplace geography, it doesn't matter. The only thing that makes me want to get out of computer programming is the tendency to loud idiot conceits: "Microsoft is evil," "IE6 is crap," "OOP is Allah." These are the things you say when you can't - or, more likely, won't - program.

John on August 13, 2009 5:08 AM

A lot of what people don't understand about COBOL is the problem set. You don't write highly reusable all dancing widgets in COBOL. You write a transform from data set A to B. Then someone else writes B to C and B to D. Then you get D back along with new set E and transform that. Then tomorrow comes and the whole thing happens again. And somewhere in their your employer makes money.

When you are granted that all your data comes in standard form with no deviation and your output is standard form with no deviation and you have to do the same operation forty billion times a day, you end up with different tools than a C program that takes all kinds of input and has to figure out what to do with it, or a LISP program that designs another program to handle the data it just got.

I'm not sure I'd believe 220bn *unique* lines of COBOL programs, as calculated that's hundreds of thousands or millions of lines per programmer depending on flat average or normal distribution, but certainly 220 bn lines worth of jobs on different systems at different companies. And being COBOL, it's the horrifying beetle-like men who scuttled so nimbly through the labyrinthine corridors of Ministries.

Nick on August 13, 2009 8:58 AM

COBOL is having 'Existential' crisis.

Aman Tur on August 13, 2009 9:52 AM

Thank you for reminding me of my youth. COBOL was the required language for Into Computing. This course was taught to everyone, not just the IT folks. We learned the language from offical IBM green softcovered workbooks and submitted batched punch cards. I remeber it took forever to writeup the code because it was so verbose. It was for this reason that I jumped onto the next great language on the horizon -- APL! Seriously, I'm not surprised it is still around because so much of it was written, either that or FORTRAN. We didn't have the choices we have today. In business, who rewrites code just because it is out of fashion.

fxp on August 13, 2009 10:15 AM

Thank you for reminding me of my youth. COBOL was the required language for Into Computing. This course was taught to everyone, not just the IT folks. We learned the language from offical IBM green softcovered workbooks and submitted batched punch cards. I remeber it took forever to writeup the code because it was so verbose. It was for this reason that I jumped onto the next great language on the horizon -- APL! Seriously, I'm not surprised it is still around because so much of it was written, either that or FORTRAN. We didn't have the choices we have today. In business, who rewrites code just because it is out of fashion.

fxp on August 13, 2009 10:15 AM

I spent about a year of my life hating what I did every single day. Coincidentally I programmed COBOL for about a year of my life.

Seriously...there wasn't anything more depressing to me than everyone I graduated with working with newer technologies (.NET, primarily) but I couldn't touch it.

Don't get me wrong - COBOL is very strong in its uses for a few things, but it's a CHORE to work with. Absolutely miserable.

Also, I can definitely attest that COBOL is still being written and revised fresh every day. The majority of the people working on that stuff, though, wouldn't be forward-thinking enough to be reading a blog like this.

A nony mouse on August 13, 2009 12:01 PM

My COBOL anecdote is from a club where I used to go to weekly billiard tournaments. There was this guy who was close to retiring at that point. He was fun to chat with and we eventually talked about our jobs. Turned out he worked for a big Finnish bank and not too surprisingly all his projects were written in COBOL. They had some web interfaces to their systems, which were written in modern languages, but all the backend systems were in COBOL.

But even more astonishing to me, he told me that he ran a project, which eventually was responsible for about one third of all the financial traffic during the switch from our own currency to euros. Which equals a lot of financial traffic. This was around 2002 when Finland started using euros as cash currency.

This isn't to prove that COBOL indeed is everywhere, but there is this world where it is pervasive and it isn't going to disappear any time soon. The language is still very much alive, even if it didn't deserve to be.

I think you (Jeff) are wrong to conclude that COBOL's popularity is a myth. You just live in a completely different world. I've seen glimbses of this world through the acquaintance I mentioned, but also through many people I know back from times I was in University (late 90s or so).

Jarno Virtanen on August 13, 2009 1:27 PM

I unfortunately went to DeVry in the late 90's and COBOL/JCL/DB2 were the main programming languages they offered.

I remember one day as we were writing some COBOL programs and someone asked "How do you make Video Games with this language?" ha

COBOL is crazy verbose and crazy english like.

Jack on August 14, 2009 8:31 AM

Of course, 220 billion lines of Cobol amounts roughly to a "hello world" program, given the verbosity of the language! ;-)

Joe on August 14, 2009 8:31 AM

"If it ain't broke, don't fix it?"

If your enterprise is entrenched in COBOL, it can make sense to stay the course.

Outside of this, I wouldn't recommend writing any new enterprises or software in COBOL.

I wonder how soon today's PHP will be cast as COBOL is now?

Steve-ちゃん on August 14, 2009 1:29 PM

COBOL is verbose, but even so it's nowhere near as bead as Jeff would like to suppose. From 99-bottles-of-beer.net, ignoring the program comments lines, the C# example contains 38 lines of code and the COBOL example 48.

C#
/// A short and sweet C# 3.5 / LINQ implementation of 99 Bottles of Beer
/// Jeff Dietrich, jd@discordant.org - October 26, 2007

using System;
using System.Linq;
using System.Text;

namespace NinetyNineBottles
{
class Beer
{
static void Main(string[] args)
{
StringBuilder beerLyric = new StringBuilder();
string nl = System.Environment.NewLine;

var beers =
(from n in Enumerable.Range(0, 100)
select new {
Say = n == 0 ? "No more bottles" :
(n == 1 ? "1 bottle" : n.ToString() + " bottles"),
Next = n == 1 ? "no more bottles" :
(n == 0 ? "99 bottles" :
(n == 2 ? "1 bottle" : n.ToString() + " bottles")),
Action = n == 0 ? "Go to the store and buy some more" :
"Take one down and pass it around"
}).Reverse();

foreach (var beer in beers)
{
beerLyric.AppendFormat("{0} of beer on the wall, {1} of beer.{2}",
beer.Say, beer.Say.ToLower(), nl);
beerLyric.AppendFormat("{0}, {1} of beer on the wall.{2}",
beer.Action, beer.Next, nl);
beerLyric.AppendLine();
}
Console.WriteLine(beerLyric.ToString());
Console.ReadLine();
}
}
}

And COBOL

IDENTIFICATION DIVISION.
PROGRAM-ID. 99-Bottles-of-Beer-On-The-Wall.
AUTHOR. Joseph James Frantz.
*COMMENTS.
******************************************************************
* PURPOSE:
* This is a sample COBOL program to display the lyrics of the
* song "99 Bottles of Beer on the Wall."
* This version of the COBOL 99 beers program demonstrates a few
* features of COBOL:
*
* 1. PERFORM VARYING, Cobol's version of a Loop.
* 2. ADD/SUBTRACT with GIVING for math calculations.
* 3. EVALUATE/WHEN, Cobol's version of Case.
* 4. INSPECT/TALLYING, which finds the number of specified
* characters in a variable.
* 5. Reference Modification:
* Var-name(Start character:Number of characters)
* which is essentially Cobol's version of text subscripting.
* 6. Long descriptive variable names.
* 7. Use of SPACES and ZEROES for field/display values.
* 8. Highlight the self documenting nature of COBOL.
******************************************************************
DATA DIVISION.
WORKING-STORAGE SECTION.
01 Keeping-Track-Variables.
05 Bottles PIC S99 VALUE 0.
05 Remaining-Bottles PIC S99 VALUE 0.
05 Counting PIC 99 VALUE 0.
05 Start-Position PIC 99 VALUE 0.
05 Positions PIC 99 VALUE 0.
PROCEDURE DIVISION.
PASS-AROUND-THOSE-BEERS.
PERFORM VARYING Bottles FROM 99 BY -1 UNTIL Bottles = -1
DISPLAY SPACES
SUBTRACT 1 FROM Bottles GIVING Remaining-Bottles
EVALUATE Bottles
WHEN 0
DISPLAY "No more bottles of beer on the wall, "
"no more bottles of beer."
DISPLAY "Go to the store and buy some more, "
"99 bottles of beer on the wall."
WHEN 1
DISPLAY "1 bottle of beer on the wall, "
"1 bottle of beer."
DISPLAY "Take one down and pass it around, "
"no more bottles of beer on the wall."
WHEN 2 Thru 99
MOVE ZEROES TO Counting
INSPECT Bottles,
TALLYING Counting FOR LEADING ZEROES
ADD 1 TO Counting GIVING Start-Position
SUBTRACT Counting FROM 2 GIVING Positions
DISPLAY Bottles(Start-Position:Positions)
" bottles of beer on the wall, "
Bottles(Start-Position:Positions)
" bottles of beer."
MOVE ZEROES TO Counting
INSPECT Remaining-Bottles TALLYING
Counting FOR LEADING ZEROES
ADD 1 TO Counting GIVING Start-Position
SUBTRACT Counting FROM 2 GIVING Positions
DISPLAY "Take one down and pass it around, "
Remaining-Bottles(Start-Position:Positions)
" bottles of beer on the wall."
END-EVALUATE
END-PERFORM
STOP RUN.

I coded COBOL for 5 years in the late 80's early 90's. It's just a programming language and like all languages works well in some environments and with some tasks and less well with others. Slagging off COBOL for what it is is like an English speaker slagging off Lithuanian just because it's at the opposite end of the indo-european language spectrum

Kevin Woolley on August 15, 2009 3:37 AM

COBOL is verbose, but even so it's nowhere near as bead as Jeff would like to suppose. From 99-bottles-of-beer.net, ignoring the program comments lines, the C# example contains 38 lines of code and the COBOL example 48.

C#
/// A short and sweet C# 3.5 / LINQ implementation of 99 Bottles of Beer
/// Jeff Dietrich, jd@discordant.org - October 26, 2007

using System;
using System.Linq;
using System.Text;

namespace NinetyNineBottles
{
class Beer
{
static void Main(string[] args)
{
StringBuilder beerLyric = new StringBuilder();
string nl = System.Environment.NewLine;

var beers =
(from n in Enumerable.Range(0, 100)
select new {
Say = n == 0 ? "No more bottles" :
(n == 1 ? "1 bottle" : n.ToString() + " bottles"),
Next = n == 1 ? "no more bottles" :
(n == 0 ? "99 bottles" :
(n == 2 ? "1 bottle" : n.ToString() + " bottles")),
Action = n == 0 ? "Go to the store and buy some more" :
"Take one down and pass it around"
}).Reverse();

foreach (var beer in beers)
{
beerLyric.AppendFormat("{0} of beer on the wall, {1} of beer.{2}",
beer.Say, beer.Say.ToLower(), nl);
beerLyric.AppendFormat("{0}, {1} of beer on the wall.{2}",
beer.Action, beer.Next, nl);
beerLyric.AppendLine();
}
Console.WriteLine(beerLyric.ToString());
Console.ReadLine();
}
}
}

And COBOL

IDENTIFICATION DIVISION.
PROGRAM-ID. 99-Bottles-of-Beer-On-The-Wall.
AUTHOR. Joseph James Frantz.
*COMMENTS.
******************************************************************
* PURPOSE:
* This is a sample COBOL program to display the lyrics of the
* song "99 Bottles of Beer on the Wall."
* This version of the COBOL 99 beers program demonstrates a few
* features of COBOL:
*
* 1. PERFORM VARYING, Cobol's version of a Loop.
* 2. ADD/SUBTRACT with GIVING for math calculations.
* 3. EVALUATE/WHEN, Cobol's version of Case.
* 4. INSPECT/TALLYING, which finds the number of specified
* characters in a variable.
* 5. Reference Modification:
* Var-name(Start character:Number of characters)
* which is essentially Cobol's version of text subscripting.
* 6. Long descriptive variable names.
* 7. Use of SPACES and ZEROES for field/display values.
* 8. Highlight the self documenting nature of COBOL.
******************************************************************
DATA DIVISION.
WORKING-STORAGE SECTION.
01 Keeping-Track-Variables.
05 Bottles PIC S99 VALUE 0.
05 Remaining-Bottles PIC S99 VALUE 0.
05 Counting PIC 99 VALUE 0.
05 Start-Position PIC 99 VALUE 0.
05 Positions PIC 99 VALUE 0.
PROCEDURE DIVISION.
PASS-AROUND-THOSE-BEERS.
PERFORM VARYING Bottles FROM 99 BY -1 UNTIL Bottles = -1
DISPLAY SPACES
SUBTRACT 1 FROM Bottles GIVING Remaining-Bottles
EVALUATE Bottles
WHEN 0
DISPLAY "No more bottles of beer on the wall, "
"no more bottles of beer."
DISPLAY "Go to the store and buy some more, "
"99 bottles of beer on the wall."
WHEN 1
DISPLAY "1 bottle of beer on the wall, "
"1 bottle of beer."
DISPLAY "Take one down and pass it around, "
"no more bottles of beer on the wall."
WHEN 2 Thru 99
MOVE ZEROES TO Counting
INSPECT Bottles,
TALLYING Counting FOR LEADING ZEROES
ADD 1 TO Counting GIVING Start-Position
SUBTRACT Counting FROM 2 GIVING Positions
DISPLAY Bottles(Start-Position:Positions)
" bottles of beer on the wall, "
Bottles(Start-Position:Positions)
" bottles of beer."
MOVE ZEROES TO Counting
INSPECT Remaining-Bottles TALLYING
Counting FOR LEADING ZEROES
ADD 1 TO Counting GIVING Start-Position
SUBTRACT Counting FROM 2 GIVING Positions
DISPLAY "Take one down and pass it around, "
Remaining-Bottles(Start-Position:Positions)
" bottles of beer on the wall."
END-EVALUATE
END-PERFORM
STOP RUN.

I coded COBOL for 5 years in the late 80's early 90's. It's just a programming language and like all languages works well in some environments and with some tasks and less well with others. Slagging off COBOL for what it is is like an English speaker slagging off Lithuanian just because it's at the opposite end of the indo-european language spectrum

Kevin Woolley on August 15, 2009 3:38 AM

COBOL is verbose, but even so it's nowhere near as bead as Jeff would like to suppose. From 99-bottles-of-beer.net, ignoring the program comments lines, the C# example contains 38 lines of code and the COBOL example 48.

C#
/// A short and sweet C# 3.5 / LINQ implementation of 99 Bottles of Beer
/// Jeff Dietrich, jd@discordant.org - October 26, 2007

using System;
using System.Linq;
using System.Text;

namespace NinetyNineBottles
{
class Beer
{
static void Main(string[] args)
{
StringBuilder beerLyric = new StringBuilder();
string nl = System.Environment.NewLine;

var beers =
(from n in Enumerable.Range(0, 100)
select new {
Say = n == 0 ? "No more bottles" :
(n == 1 ? "1 bottle" : n.ToString() + " bottles"),
Next = n == 1 ? "no more bottles" :
(n == 0 ? "99 bottles" :
(n == 2 ? "1 bottle" : n.ToString() + " bottles")),
Action = n == 0 ? "Go to the store and buy some more" :
"Take one down and pass it around"
}).Reverse();

foreach (var beer in beers)
{
beerLyric.AppendFormat("{0} of beer on the wall, {1} of beer.{2}",
beer.Say, beer.Say.ToLower(), nl);
beerLyric.AppendFormat("{0}, {1} of beer on the wall.{2}",
beer.Action, beer.Next, nl);
beerLyric.AppendLine();
}
Console.WriteLine(beerLyric.ToString());
Console.ReadLine();
}
}
}

And COBOL

IDENTIFICATION DIVISION.
PROGRAM-ID. 99-Bottles-of-Beer-On-The-Wall.
AUTHOR. Joseph James Frantz.
*COMMENTS.
******************************************************************
* PURPOSE:
* This is a sample COBOL program to display the lyrics of the
* song "99 Bottles of Beer on the Wall."
* This version of the COBOL 99 beers program demonstrates a few
* features of COBOL:
*
* 1. PERFORM VARYING, Cobol's version of a Loop.
* 2. ADD/SUBTRACT with GIVING for math calculations.
* 3. EVALUATE/WHEN, Cobol's version of Case.
* 4. INSPECT/TALLYING, which finds the number of specified
* characters in a variable.
* 5. Reference Modification:
* Var-name(Start character:Number of characters)
* which is essentially Cobol's version of text subscripting.
* 6. Long descriptive variable names.
* 7. Use of SPACES and ZEROES for field/display values.
* 8. Highlight the self documenting nature of COBOL.
******************************************************************
DATA DIVISION.
WORKING-STORAGE SECTION.
01 Keeping-Track-Variables.
05 Bottles PIC S99 VALUE 0.
05 Remaining-Bottles PIC S99 VALUE 0.
05 Counting PIC 99 VALUE 0.
05 Start-Position PIC 99 VALUE 0.
05 Positions PIC 99 VALUE 0.
PROCEDURE DIVISION.
PASS-AROUND-THOSE-BEERS.
PERFORM VARYING Bottles FROM 99 BY -1 UNTIL Bottles = -1
DISPLAY SPACES
SUBTRACT 1 FROM Bottles GIVING Remaining-Bottles
EVALUATE Bottles
WHEN 0
DISPLAY "No more bottles of beer on the wall, "
"no more bottles of beer."
DISPLAY "Go to the store and buy some more, "
"99 bottles of beer on the wall."
WHEN 1
DISPLAY "1 bottle of beer on the wall, "
"1 bottle of beer."
DISPLAY "Take one down and pass it around, "
"no more bottles of beer on the wall."
WHEN 2 Thru 99
MOVE ZEROES TO Counting
INSPECT Bottles,
TALLYING Counting FOR LEADING ZEROES
ADD 1 TO Counting GIVING Start-Position
SUBTRACT Counting FROM 2 GIVING Positions
DISPLAY Bottles(Start-Position:Positions)
" bottles of beer on the wall, "
Bottles(Start-Position:Positions)
" bottles of beer."
MOVE ZEROES TO Counting
INSPECT Remaining-Bottles TALLYING
Counting FOR LEADING ZEROES
ADD 1 TO Counting GIVING Start-Position
SUBTRACT Counting FROM 2 GIVING Positions
DISPLAY "Take one down and pass it around, "
Remaining-Bottles(Start-Position:Positions)
" bottles of beer on the wall."
END-EVALUATE
END-PERFORM
STOP RUN.

I coded COBOL for 5 years in the late 80's early 90's. It's just a programming language and like all languages works well in some environments and with some tasks and less well with others. Slagging off COBOL for what it is is like an English speaker slagging off Lithuanian just because it's at the opposite end of the indo-european language spectrum

Kevin Woolley on August 15, 2009 3:39 AM

Don't go by what someone says regarding whether a language is fading... do a job search and compare it to job searches for other languages. For instance, I just did a search for "cobol programmer" on Monster.com (no locality given) and I got 90 hits. I did the same search for ".NET programmer" and I got 361 hits. "C programmer" got 459 hits, but "ruby programmer" only got 35 hits. Perl got 110 and PHP got 133. Just "Programmer" got 2055.

I guess cobol is fading. Those lines of code must be really good and really old.

Owein on August 15, 2009 5:03 AM

Some commenters contrast COBOL with Java, which is supposed to be a modern language, but the tendency I see is that Java has peaked and is declining in popularity. Do not despair, though, Java programmers! Considering the amount of code currently being written in it, Java will be the next COBOL!

Martin Vilcans on August 16, 2009 4:02 AM

Actually, what all these comments say is that IT doesn't matter. The destested Nicholas Carr was right!

For all that we keep hearing about how IT can be a source of competitive advantage, it rarely turns out to be true. You can search airfares using mainframes and TPF. Or big UNIX servers and C++. Or Linux clusters and Lisp. Doesn't matter. (These are real examples.)

IT tends to occupy the same percentage of the budget in different organizations. (Not unlike military budgets.) If you find a way to be 10x more efficient at your business-critical processes, then great, your IT staff just gets more time to goof around with non-critical toys that make them happy. It doesn't, however, allow you to fire 90% of your IT people and pay out the savings as dividends to your shareholders.

COBOL is dead. COBOL is alive. COBOL is ugly. COBOL is beautiful. COBOL corrupts the mind. COBOL promotes good programming. None of this matters. COBOL simply ... is. And that's that.

Tom on August 16, 2009 8:19 AM

Neither line count, years in development nor the number of active developers are good measures of the quality of a language. A two-person startup using a modern, succinct language can convey a lot of functionality in six months and a few thousand lines of code.

Yes, there are still some people using COBOL. I bet you could say the same thing about any programming language that used to be somewhat popular at one point in time.

But if COBOL programmers are making good money, that only means there are few of them left. If there were plenty, they'd be cheap.

Pies on August 17, 2009 5:24 AM

Hi. great Site, reading it little time ago.
Now respect to cobol (escuse my english, im spanish native), im always wish to learn it (no teach it in university).
Now im working in bank industry, and i see a lot of cobol. I enter this company as Java, javascript, bash, html coder. But i´d been so great, that they ofer me a trainee in cobol. I say yes, and now im learning it. Its not dificult to learn, but like the comments expose here, its a economics move, because theres a few programers, and a big market to work (not so big like web thing, but is better paid and stable-im thinking in to stay in this company a few 10 years :) )
I think cobol is not dead, and im moving it to this desert market.

phantomcl on August 18, 2009 4:04 AM

I CAN'T READ COBOL CODE WITHOUT WONDERING WHY EVERYBODY IS ALWAYS SHOUTING.

Ted on August 18, 2009 4:06 AM

Back in 1999, I taught a Visual Basic course to COBOL programmers at a large company that handled credit card transactions. This was one of the most challenging groups I have ever taught. These fellows really had a huge mental block when it came to "visual" aspects of VB and event-driven programming. They seemed quite intelligent but they just could not "grok" the concept of visual, event-driven programming. There seem to be some strong patterns in COBOL that render a long-time COBOL coder incapable of making an easy transition to modern languages. I decided it was generally easier to teach VB to a novice than to a long-time COBOL coder.

Vadim on August 18, 2009 6:22 AM

Cobol is Dead? No one gives a damn? Well it looks a pretty long thread if no-one cares.

Cobol is cool - true you would not use it to write a 1k space invaders ... Opps showing my age and first comp there, NO not all COBOL programmers are the wrong side of 40, I think we are the right side of 40. COBOL is a tool, excellent for handling Business Data - without creating the Bloat surrounded by modern data database index's.

All languages have their place, and I certainly will keep writing COBOL code for as long as the demand exists.

IscaFortis on August 18, 2009 6:43 AM

I think the 1 million worldwide estimate is probably right. It may sound like a lot, but compared to the multi millions of C++, Java, VB and .net programmer around.
I also find the 220 billion line of code to be believable. Back in the late 1990, due largely to the hysteria drummed up by "The Millienum Bug" and similar books, the "Y2K Problem" became a priority and everyone who had ever had a COBOL course were put to work studying COBOL source code to find and correct date related elements in the code. I had taken a couple of COBOL courses in the late 1980s' so I stayed busy for several months doing this.

COBOL is a relatively low level language. It runs "close to the metel", in other words, it compiles to very efficient machine code, and is easily ported to different processors. It is also the second English like language developed and as such has a 50 year head start over the current crop of modern languages when it come to lines of code written.

As for the wordiness, after you include the declarations, prototypes, constructors and namespace related coding found in modern OO languages, COBOL is not really that wordy by comparison. There have even been several OO COBOL compilers such as Fujitsu COBOL. There is one thing supported in COBOL that I haven't seen in most modern compilers, Arbitrary precision arithmetic. which operates on a data type known as packed binary coded decimal(packed BCD). This feature of the language makes it particularly suitable for high precision accounting needed by government and large corporations.

Most COBOL programmers were taught the "Top-down" design paradigm which is useful in a batch environment where the program explicitly controls the process. Many had difficulty understanding the basics of an event driven system and even had some problems understanding the terminal services module that was added in the 1992 COBOL standard.

There are some COBOL to C++ translators(as wellas as ranslators for other languages), but they are limited by the math abilities of the target language, often requiring considerable knowlege of both COBOL and the target language and generally produce an inefficient tanslation.

Often I have observed that when someone resorts to the "My ___ is better than your because mine is newer!" type declaration in their comments, it is bscause theylack experience.

Niklaus on August 19, 2009 2:26 AM

Ted - try reading something written in the last 20 years. COBOL has been happily mixed case for at least that long.

erica on August 19, 2009 1:36 PM

Cobol is still around. Tried C# and it also worked for me... BUT I'm still doing my developed products in Cobol, except this time it is in Web Dev (no more green screen!).

Why I do keep on coming back to Cobol? I do not know. It is probably because I could type the codes even when my eyes are closed.

rasurop on August 20, 2009 1:13 PM

Hi there. I am a Cobol programmer for 11 years now, I've started with 22, direct from the university to a multinational company, and had been invited to join an american global company two years ago.
Despite the ups and downs on cobol programmers needs, there are new joiners every year in the age of 20s.
The systems are quite robust and bug-free because the language is very high-level and easy. But the laws change and so do the requirements for business and there lies the need for programmers, not only the old ones that have retired in the last 10 years...
With the idea that only the new languages would survive it was created a gap on new cobol programers, so now we have them all in the ages of 20-30s.
I develop my software in a big portuguese bank, that have several platforms and several levels of programming, but when comes the need to process large deals of information no other language can do it faster and precisely. I do not work on monochromatic screens and I have a mouse, my computer is a real PC with Win software and internet access, the link to the mainframe is made thru an emulator.

So I’m a girl in the early thirties, I am forming youngsters to use the mainframe and the Cobol and I doubt that it could be translated to another language without enormous risks to the institutions and their customers.

Regards, Clara
Sr. Systems Analyst in Financial Services

Clara Jinx on August 21, 2009 3:51 AM

It's true that COBOL jobs are going to India, China and the "Philippines". Where I work, most of the programmers/demand here is for COBOL. What the 1st world won't do anymore are being done by people from these countries. So you'll see COBOL programmers as young as 21. When you get to 30, you're expected to become a manager already and of course your job responsibilities change. As for COBOL is dead or dying, that still really remains to be seen. Our client alone uses Java as front-end and COBOL as the back-end where hundreds of millions of transactions are processed by the system every month.

Pachoi on August 21, 2009 5:06 AM

Whilst everyone seems to be contrasting COBOL and C, I always favoured BASIC amongst the procedural languages. Best one in my opinion is HP BASIC running on servers using the OpenVMS operating system. Easy to use and learn, no garbage collection or memory issues to worry about and code maintenance is very easy. I used HP BASIC to develop a full blown ERP application suite, effortlessly capable of supporting hundreds of simultaneous users. As long as you supply them with continuous power, servers running OpenVMS almost never crash or need rebooting. IBM AS/400 servers running COBOL code have similar characteristics which is why this technology hasn't gone away. If you look at most of the world's high volume mission critical applications they all favour these technology characteristics. Here is a link to an HP video which gives you an idea of stuff running on OpenVMS. The video includes a profile of a company which handles processing and distribution of over half the world's text messaging traffic.

http://h30423.www3.hp.com/index.jsp?rf=sitemap&fr_story=f155197e00e8a915606b1eedddd2008298621394&jumpid=reg_R1002_USEN

Just for fun, here is the 99 bottles of beer thing coded in HP BASIC.

! HP Basic version of 99 bottles of beer
! Created by John Cookson

FOR BOTTLE.QTY% = 99% TO 1% STEP -1%

IF BOTTLE.QTY% = 1% THEN
PRINT BOTTLE.QTY%;"bottle of beer on the wall";BOTTLE.QTY%;"bottle of beer"
ELSE PRINT BOTTLE.QTY%;"bottles of beer on the wall,";BOTTLE.QTY%;"bottles of beer"
END IF

PRINT "Take one down and pass it around,"

IF BOTTLE.QTY% = 1% THEN
PRINT " no more bottles of beer on the wall"
END IF

IF BOTTLE.QTY% = 2% THEN
PRINT BOTTLE.QTY% - 1%; "bottle of beer on the wall"
END IF

IF BOTTLE.QTY% > 2% THEN
PRINT BOTTLE.QTY% - 1%; "bottles of beer on the wall"
END IF

NEXT BOTTLE.QTY%

END PROGRAM

John Cookson on August 21, 2009 12:50 PM

«Back | More comments»

The comments to this entry are closed.