COBOL is absurd language

I had been in the first two years of my post-University career a COBOL programmer. To put that in context, I graduated 2001.

The software in question had been originally started in 1983 to fill a gap in the market. By the time I joined the company, there was about 10 modules and millions of lines of code. Of course given COBOL's verbosity, that would equate to about 5 lines of C#.

In general, the reason given for not moving to a more modern language was just the sheer scale of how long it would take to rewrite!

I also had the somewhat dubious pleasure of meeting several old COBOL programmers and the amount of brainrot that had set in from writing such a hideous language had reduced them to barely able to take any form of independant thought!

Fortunately I jumped into the small part of the company that was doing C# then after gaining enough skills that the COBOL was a little buried on my CV, I jumped ship!

Strength and robustness!

I a bank or assurence company, why change a back office program that work for 20 years?

Cue obligatory Dilbert reference: http://www.funnyphotos.net.au/images/dilbert-cobol-programmer-dinosaur1.gif

This explains!

We are living (in the Internet) in some what an ideal world. We use latest technologies and cutting edge solution.

When I discovered the outside world, I found that they still use Microsoft Access, C++ (Ms-Dos) and very old technologies. Yet as you said they wrote hundred of thousands of lines of code that made tweaking the old better than moving to the new.

In my opinion, it's microsoft (or any other producer fault). If Microsoft support dot net for 20 years and developers build amazingly giant applications and then MS comes and says it wants to make the switch to a cutting edge solution and platform: This is really not a so smart solution.

As they do (by tweaking their old code) MS and other companies should do by tweaking their old platform rather than creating new ones.

Cobol writers are quite old and are not part of our world.

I had to work as a Cobol developer (I'm a Java specialist) for one year in my former company. I was something like 25 yo but most of my coworkers where over 40 and on the customer side, they were over 50.

All of them doing COBOL for 20 years, some of them don't know how to use a mouse and worked on VT-100 terminal (orange and black screen , one keyboard and that's all).

Cobol is still alive but it's death is closer than ever because people that knows it are going to be retired soon...

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

No, absolutely not, but since COBOL programmers are so hard to find, companies instead hire teams of "new" developers to write screen scrapers and wrapper APIs for the old systems, hoping to fix bugs and circumvent quirks in the process.

If you can't maintain it, hide it...

The line number figure sounds pretty impressive, doesn't it? 220 billion lines of code, 80% of all code lines in the world. Wow, that's really, really impressive... for those people that don't know COBOL at all.

For the rest of us, those who (as sad as it is) know at least some COBOL, this number is not so impressive at all. As your own sample above shows, considering the fact that you may need 100 lines of COBOL to do the same thing that a modern language can do in 20, if you are lucky, maybe in 3(!!!) lines of code, somewhat puts the number into perspective.

Rewrite those 220 billion lines in a language that is not older than 20 years and the number will shrink so dramatically; it will shrink even without considering things like powerful standard APIs that would further reduce the number even more. And all of a sudden 80% of all code lines in the word are not even getting close to 5% any longer.

@Rach: Yes, rewriting all this code is a damn lot of work. It is so incredible much work, that I would question the concept of a rewrite and instead considering writing a translator. A translator that can take any piece of COBOL and translates it to ... I don't know, translating it to a high level language like Java or C# seems to make no sense to me. I would translate it to plain C. Basically you write a COBOL compiler, but not one that outputs machine code for the CPU but that outputs C source code. Such a translator can be written in a couple of months - definitely less time than rewriting all those COBOL lines! And once you have it done, it can translate billion lines of COBOL and it won't even take long for that (even if you are no compiler guru and your implementation of the compiler sucks, it can easily translate 1000 lines of COBOL to C within a second).

Of course this won't fix the main problem. The structure of COBOL code sucks and so will the structure of the C code. However, unlike COBOL there are million of C programmers out there that have no problem to slowly re-factor the C code more and more as they go over it to fix bugs, add features, etc.

Alternatively write a compiler that translates COBOL into Java Bytecode. Not only do you have immediately executable code that way that any JVM in the world can execute, there exists great Java Decompilers that can translate .class files back to .java files and the code is surprisingly good and readable. The only problem here is that the OO concept of Java is not compatible to COBOL IMHO and the output of decompilation will produce real Java code, however Java code that no Java programmer in the world had ever written that way.

The company I worked for had a mainframe as database vehicle. They'd quit working on documentation and more than the essential maintenance years before because the system was going to be replaced. Turned out that C++ on a bunch of PCs didn't gave the required performance.

Fast forward a few years, years in which the documentation was updated somewhat and the system had grown only bigger. The new silver bullet was .Net, with all the shininess of C# and SQL Server.

This was years ago, when .Net was in its beta stages. Migrating to a platform in its infancy is slightly braindead, doing so without essential trust in the capabilities is even worse.

You won't believe the trouble we ran into. But that wasn't the worst. The existing workforce had been chased away or was under training to work with the new architecture ("What's object orientation?"). Documentation was again no priority. Fairly dumb terminals (bottom grade PCs) had to be upgraded to something that carried at least XP, with all the organisational trouble that came with that. And when we finally produced a basic transactional system, it didn't perform, no matter which expert looked at it. Although we could write the code faster.

I went away, don't know the end of the story. It's very well possible that there was no return back to the mainframe anymore but maybe they threw enough fast hardware against it to make it work. I'm still wondering why anyone would bother to replace one vendor lock-in for the other (one of the main reasons for the transition) but that's not up to me.

Sure, COBOL's dead, just like the mainframe it ran on. More in the minds of the management than in reality though.

We have as many COBOL programmers at our company as Java developers maintaining the legacy systems. The programmers are typically non-Computer Science graduates who are taught COBOL in house, and are actually often quite youthful. I guess the advantages to employing non CS grads is that they have no frame for comparison...

Actually more like:

method-id. "button1_Click" final private.
procedure division using by value sender as object
e as type "System.EventArgs".

set button1::"Text" to "Call COBOL"

end method "button1_Click".

including a bit of white space to look pretty. It's a good idea to make your comments based on knowledge rather than outdated hearsay.

Yep, I know there aren't many of us left and some of the work isn't as exciting but I'd rather earn what I'm earning rather than competing with some kid just out of high school who'll charge fifty bucks to set up a web site that will be probably full of security holes and be unmaintainable in a month. That's not to say we don't know c#, VB or any other number of languages. That's also not to say there aren't dinasaurs in the COBOL world ... I've met quitea few ... I've also met quite a few in the VB and Java world as well.

What a bunch of crap. Not what you write Jeff, but the COBOL "article" you reference.

First of all, the author of the article is one Stephen Kelly, who seems to be the owner or is otherwise affiliated with Micro Focus World, a dis-functional website (http://www.microfocusworld.com/) with a business focus. Micro Focus is a sponsor (the only one?) of http://www.cobolportal.com/ which as you can get by it's name is all about COBOL. Gasp, cue conspiracy theory...
So of course such a person would spout all kinds of "facts" about how prevalent COBOL is and how it is still important.

As for the facts themselves...

"There are over 220 billion lines of COBOL in existence, a figure which equates to around 80% of the world's actively used code." - bunch of crap figures regurgitated from a 2003 (!!) PDF linked to from the Wikipedia article on COBOL (citation #5). That PDF was published by LegacyJ, a -- you guessed it -- software firm specializing in COBOL solutions. Gasp again!

Not only that, the LegacyJ PDF lists a 1997(!!!) Gartner study as the source of these figures - but fails to provide a reference. Was there really a Gartner study back in 1997 which gave those numbers? How did Gartner collect them? what does "actively used code" even mean?! Are these numbers as relevant now, 12 years later?!

"There are estimated to be over a million COBOL programmers in the world today." - yes, estimated by COBOL software houses eager to sell you their solutions and to calm your likely fears of being stuck with a language but without any programmers...
Pop question - how many questions in StackOverflow are currently tagged COBOL? It's 61 of this writing. Compare to 17k questions tagged Java, just for example...

I could go on but you get the idea. COBOL is out there, it is used. But I seriously doubt any claims making it to be the "dark matter of programming languages". It it were so prevalent we would know.

Now if you really want to talk about a prevalent but no longer sexy language, there's... C. Simple old C, no longer sexy enough for most people... yet so much code is still written in C, including the little OS that could, Linux...

Cobol code lines == Zombies

Honestly, those numbers are made up on the spot. How on earth can anyone make any guess about how many lines of code any programming language has?

At the moment i'm involved in a project to replace old Cobol software with a brand new Java-based one. The old software is absolutely critical and rather big so it was a tough decision to rewrite it. They probably wouldn't have done it at all, but they wanted certain features which Cobol simply couldn't implement.

The numbers are probably exaggerated, but a lot of Cobol is still out there up and running. The smaller and less critical software has already been replaced, but some big and important ones remain because they are so expensive and important.

Wow... that is new COBOL with functions it looks like. I was taught old COBOL86. No functions for me.

"It it were so prevalent we would know."

@Solidstate: That is the point, you would if you were told about it, but most people are not, so you don't. As a programmer these days, the smart money is in COBOL because it is a niche, you could charge pretty much whatever you want as a consultant and they would pay because they would have very few other choices ;).

Wow, Cobol86! when I went to UNB in 97 they were still using Cobol72. It was hard to take a course seriously when the compiler was older then 99% of the class. I didn't mind COBOL all that much except for all the typing, I sucked (and still do) suck at typing.

My first job as a programmer was doing COBOL development. This was a little over a year ago. The company I worked for not only did maintanence of old COBOL programs, which, granted, was the bulk of the work, but they were also doing new applications in COBOL. Right before I left, the company was gearing up to create a new web app in COBOL. Before then, I didn't even know you could do that sort of work in COBOL, but lo and behold, you can.

The reasoning behind using COBOL was that COBOL was more readable than any other language. I would tend to agree that COBOL is easier to comprehend in smaller programs to non-programmers (it was, in fact, created to be understandable to managers), but when any sort of complexity is introduced, the sheer verbosity of COBOL causes programs to become convoluted messes that take a large amount of time to figure out what's going on.

The major problem with using COBOL as a starting point (most new-hires cut their teeth with COBOL before being allowed to go on to anything else, if they ever were) was the carry over of COBOL techniques to more modern languages. The PHP and ASP apps tended to be utter messes. There were a few notable exceptions to this, but, for the most part, The COBOL mentality dominated.

Besides just using COBOL, we were also using an antiquated version of COBOL (COBOL86, I believe) on an antiquated system (MPE/iX). There were many times where the copyright date on the software I was using was before my year of birth. One was even around 10 years before I was born.

Is this the norm? I highly doubt it, but don't be so quick to believe that COBOL is gone. It may be dying, but it's going to die a very, very slow death. There are (shockingly) some people in the world who actually find COBOL to be a very good language, and will continue to use it, regardless of developments in language design.

I think you should take the site you quoted with a grain of salt though.

It lists C as the #6 dying technology. Clearly, that's not true if you walk into anywhere that does embedded, systems, or a number of other different kinds of work.

I keep hearing about how COBOL programmers are in demand still, yet I never see jobs advertised for it. You'd think if it was so in demand that they'd be looking for people! COBOL is not my preferred language, but I have no problem with it. Problem is that so much "COBOL" is actually CICS... They DO still teach COBOL in school, but nobody knows CICS, so there's a significant amount of learning that needs to happen for new COBOL programmers before they can actually get any work done.

Also, you're right, there's a huge disconnect between the "Internet world" and the rest of the programming world. There's a huge portion of programmers that don't do web, don't use the web other than e-mail, etc. The things that they're working on just don't intersect with the Internet world. A few of us try to live in both worlds. :-)

You need to ask Joel to emit COBOL from Wasabi, and he could make billions :)

One of those big investment banks which just failed had a core trading platform written in Cobol on an AS/400 with a back end DB/2. They had scores of Cobol programmers maintaining it.

They had a C# front end I worked on which could only access the database by sending socket messages to Cobol jobs. Of course these jobs were actively being developed as well, in many cases by people in different offices, which made debugging and development something of a challenge to say the least. You could go for hours unable to even start the C# app up, because some crucial job was shut down ("in message wait").

They had also contrived to bring the lack of productivity you expect from green screen Cobol development to the .NET world.

Most of the screens were so complex they were incapable of being loaded into the screen designer, so adding a control meant spelunking through the .designer.cs file and adding it (and figuring out location co-ordinates) by hand.

And by underpinning the whole with a very large and creaky market data engine written in C++ they removed the ability to use the Visual Studio debugger. If you stopped in the debugger at any point the market data engine killed your process!

There were enough WTFs there to write a book.

Putting aside the "my computer language is bigger than yours" statistics, it's interesting that computer language communities are so isolated from each other. Is it just because of historical happenstance, or is there some not-well-understood advantage in staying out of the "mainstream"?

THIS: http://media-tech.blogspot.com/2009/06/naca-presented-jazoon-2009.html
... is great. That company migrated all their Cobol codebase to Java by writing their own conversion tool. You have to read all the papers, because it's a very cool way of doing it.
Basically, unlike what you'd expect from existing language converters, the converted code is maintainable, and there is no need for any manual intervention after it's done.
They fine-tuned the system until it was perfect, continuing in the mean time on working on the Cobol code (because you always need some amount of change to keep your business going!) and when it was, they converted and migrated over to the java version, working on that from then on.
They released their tool as F/OSS so that others could benefit from it.
Very, very cool.

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

The other day there was a presentation in school by a former student and also friend of mine. She is working for New York Life, an insurance company, and guess what tool she is using everyday to write programs? You said it: Cobol (and also Assembly!).

COBOL is trivial enough to be generated/converted to be abstracted. Could this be a solution ?

COBOL is trivial enough to be generated, converted.. Well, to be "abstracted" somehow. Could it be a part of a solution ?

Why is COBOL around? There are a lot of reasons but I can certainly give you one glaring example. IBM mainframes and DEC VAXes and Alphas don't have "Blue Screens of Death". They measure their uptimes in *YEARS*. In my previous incarnations as a Cobol programmer on DEC (VMS) hardware, I can count the layers between source code and the CPU on one hand. You can't do that on Windows or with Apple. You could be running an ASP.NET application with Java going through a browser built on several layers of OS andp-code translators before you actually make it to the CPU. All those opportunities for failure.

Don't get me wrong, I'm in the .NET world now becuase there weren't enough "legacy" jobs as of 5 years ago. If you learned top-down modularization and object-orientation, your programming skills still translate in the "brave new world".

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

You would if you've ever worked for a bank, an insurance company, or anywhere in India.

The 3 COBOL programmers I know are half dead, but COBOL itself remains unendingly alive.

There's something delightfully perverse about installing a build environment for a 50 year old language on a brand-spanking-shiny-new Sun T5220. I recommend it.

My first job after graduation(2000) was also on COBOL - for giant US based insurance company and they are still using COBOL. I did write tons of code to produce very little output.

As an ex-COBOL programmer,

If you've only really programmed on *nix and Windows, there's a good chance you haven't come across COBOL.

But if you cross into the mainframe world, it's everywhere.

Billing systems, printing systems, accounting systems. My brushing up against it has been in the telecom and printing world-- so there are a lot others on this list but I haven't had as much direct experience with them.

Most of the credit card billing, landline telephones (and, where they've integrated, cell phones), and I suspect bank software is still on COBOL.

So every time you make a call from the phone on your wall, many of the cell phones, purchase something with a credit card-- chances are high that there are one or more COBOL queries going on behind the scene.

It is a verbose language; it largely reads like English. I don't know whether that made code written in COBOL less buggy when originally written but I do know that most of what is out there was debugged in the 70s and so while it may not be perfect, it's at a place where it pretty much just runs.

I think that most of the jobs in COBOL are internal; and they tend not always to be viewed as "programmers" but rather "MIS" staff.

The people maintaining the code probably weren't hired as programmers or even as something called IT but rather as people to handle the tape drives on the mainframes and then they progressed from there. At least that's what I saw at the customers I dealt with.

I programmed in Cobol for years then moved to .net, then got a job in Peoplesoft which had an overnight job that ran forever and guess what it was in cobol and I was back there again. What is funny about cobol is that it had convention over configuration to an extent. You had a Data division that you had to declare a certain way, even making sure that the correct data was in the correct column in the source file. The thing about it that people forget is that the B is for Business and for Business apps, nothing could be simplier. It only has a hand full of data types. Where the modern cobol has gone wrong is where I feel c# is going wrong. It tried to be all things to all people, object oriented cobol never worked. C# is now going to be dynamic I hear, why. There are dynamic languages already. Do I write cobol today ? no way ? Would I if cobol was as easy as it was with green screens and people did not try add every feature that java, c# and c++ have, in a heart beat it was so easy back then.

You don't hear about COBOL because COBOL programmers don't hear about you. Seriously, I used to program COBOL and at 30 years old, I was the by far the youngest programmer. Everyone had PCs, but they were basically dumb terminals. Right now the industry is desperate for a good migration strategy away from COBOL (this is a huge cash cow waiting to be milked), but the solutions I've investigated in the past have been awful.

It's also worth noting that I would sometimes fix software which was written in the 60s. Very little spaghetti code you see today will compare with the horror of much of that code, but the thing is, that code *works*. The only thing which will fix this problem is when the availability of COBOL programmers is so short that their salaries skyrocket to unmaintainable levels. Even then, companies will wrap the software rather than rewrite. Also, many of those old COBOL programs have been compiled and the source code is not available, making a rewrite significantly harder.

I am one of the not so rare bread of COBOL programmers, or at least have been until last year. A large pension insurance in Switzerland has a 30 year old COBOL program, both heavily batch oriented as well as CICS (some sort of transaction processing environment for online programs).

The company started 5! attempts within the last 10 years, usually staffed with 80-120 programmers, to replace the system in ORACLE Forms, Java, JEE, C#. All failed, each costing many millions.

The programmers that keep the system alive, implementing law changes on a yearly basis, has an average age of maybe 55, with many being retired and working on part time.

The hardware the systems run on have been discontinued for the last 5 years, the hardware company went bankrupt, but there still are some other machines retired and then bought up as spare parts. Next a port to UNIX midrange is planned, with a virtual OS and CICS emulating the host environment.

Huge problems. But then, many are facing the same problems and go out of their way to solve these,as it is less expensive short term then starting the 6th attempt of a rewrite.

Referencing a Computerworld article on programming is a lot like referencing the National Enquirer in your term paper.

Sure- you can do it, just don't expect people to take your point seriously.

"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." (Edsgar Dijkstra)

I forgot where the quote comes from, but I have come across it several times.

I'm under the impression you haven't been involved in the enterprise development biz that much? That is, ERPs and whatnot?

I started my career developing systems for the logistics business, and in my "first real job", my team of around 10 people had one full-time COBOL programmer and two part-time. And this was in 2005.

More recently: last year, I was consulting a press/publishing company and they had a full-time COBOL coder working for them.

So they're still out there.

On the other hand, COBOL systems have been kicking about for so long that they've pretty much got the boiler-plate stuff fixed so the maintenance focuses on keeping the business logic side up-to-date.

"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." (Edsgar Dijkstra)

I forgot where the quote comes from, but I have come across it several times.

@Brian:

> I keep hearing about how COBOL programmers are in demand still, yet
> I never see jobs advertised for it. You'd think if it was so in
> demand that they'd be looking for people!

Job-offers are done by obituary notices

Regards, Lothar

220,000,000,000 LOC / 1,000,000 programmers = 220,000 LOC/programmer. Hmmm.

Come on Jeff, If you are going to play shenanigans and include a event handler in COBOL at least include a routine to store data in hierarchical DB.

Sure, COBOL is older than dirt, but it is *STILL* up. It's like a pathological cockroach that just wont die. The uptime on our mainframe is currently over 8 years. Since the day we moved to a new data center. It was 15 years before that.

And just because I have never met a *REAL* VB or assembler programmer doesn't mean they dont exist.

I once applied for a job as senior programmer for the Ministry of Public Service in charge of teacher payrolls, i found they programmed in COBOL so i ripped a site and made a cobol manual using which i learned COBOL. when the senior (in the true sense of the word) programmers heard i had learned COBOl in a week, i was sent to work in records. I quit after a month. I love COBOL. It was the easiest language i have ever learned in the shortest time too. i never saw COBOL.Net or the promised object oriented cobol or even relational db in cobol. i feel short changed!!

oh and the microfocus IDE costs an BOMB!!

COBOL was my first commercial project. Like, first ever. Including these "you're good at computers, can you fix this little problem I have with my work PC?" type of jobs which barely count as commercial.

I was 14, knew a good deal of BASIC, and... well... nothing else, actually. A new law required my father's inventory software to be changed slightly, but no one knew how to. With the confidence of a pubescent kid, I stepped in -- and made it.

The concept of "GOTO 1200-1299" (right, not a single line number, a range of lines) grossed me out, however. I promised to never touch COBOL again, and the promise still holds :)

Regarding the article, it was the only COBOL software I ever saw. But I am willing to believe many of these facts. If some software has been working for 20+ years, where's the incentive to switch? Whole companies went out of business because of ignoring the old wisdom of "don't fix what ain't broken".

I have been rewriting (less critial) systems from scratch, and it takes years to flesh out all the little details that are invisibly buried below the obvious functionality.

I still have a large number of COBOL listings, i haven't thrown them out because there's something gratifying about looking at the reams of alternating color print paper.

@Sudeep: I've got COBOL code thats probably older than you, still running, still earning a very large financial institution LOTS OF MONEY and its relatively maintenance free. Whats absurd is all of this new stuff that comes and goes while COBOL's "death" keeps coming up and going away just as fast. Take for instance, agile. Another FAIL.

To the rest of you knocking COBOL, you're just jealous that you dont earn $150/hr writing and maintaining mainframe systems and are considering retiring before 50.

I'm a Java programmer and I had to work with a team that had COBOL programmers interfacing with our software. We were working on a system that had to interface with an insurance company's existing systems. They didn't have an XML parser because IBM hadn't released a non-beta COBOL XML parser for that platform, so they parsed XML by hand (improperly, I might add). It was... interesting.

But certainly there are lots of COBOL systems out there. I suspect many of these systems are being extended through non-COBOL means where possible. But then again, I have a friend who worked for a bank where they weren't allowed to use C; they had to write code in assembler. You read that right. And this was in 2003.

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

This is because you are less than 50 years old, as are most of your friends probably. I know several COBOL programmers who work for things like insurance firms, etc. But I only know them because they're relatives.

Look in the classifieds of major newspapers under software jobs, until recently a big chunk of them were AS/400, Crystal Reports, and COBOL. This stuff was the nuts and bolts of business software for the past 20 years or so, slowly being replaced by a more modern spectrum encompassing VB, Access, Oracle, SAP, whatever. But they're still around.

I still write COBOL in my job... It's currently my primary language, though I'm shifting towards primarily .Net development.

And as far as usefulness goes, I can make COBOL do most things I need it to. Including servicing web calls. We've got .Net code that makes a web service call that is served by a combination of COBOL and Fortran.

Is it my first choice for doing that? Hell no. But when you have to live within certain shop constraints, you learn to adapt and get the job done.

The world could probably benefit from a Cobol variant that adds a more familiar C-like syntax in the source code but is binary compatible to previous versions. (There apparently already are recent versions with modern language features like object-oriented concepts, etc.)

Not a bad post, but remember that total cost and total revenues are not the same as marginal cost and marginal revenues.

I think everybody here is confusing syntax, power and tool scope.

Every successful language has a syntax tuned for it's task (sql has a good syntax for data manipulation, c for memory/register manipulation, awk for lines of text manipulation, etc).

COBOL is not an exception. Yes, you can see that fragment of code and think what a verbose thing. You are wrong! COBOL syntax if pretty compact for what it is designed to do. You are just looking at the wrong example. Try writing a Java (or other modern language) program that receives an input file (say XML, reads every entry, does some calculation and writes it back to the same format and you would get exactly the same verbose bunch of lines. On the other hand, write an online processing server and the same language is very succinct.

COBOL was successful in it's days because it's very close to assembler (the syntax is easier to maintain but it can be easily translated). It has no dynamic memory allocation (so you can guarantee performance for every transaction, which is not as easy in modern languages).

And it's oriented towards data processing, NOT object or functional processing.

This should not be a problem for anyone trying to use the right tool for the right problem (unless of course you plan to use awk to write your next mission critical accounting application).

I don't write COBOL (and i prefer C++ or Javascript/Python), but there is a healthy community of COBOL programmers (mostly in any large companies having a system that has must handle more thank 100K customers/invoices).

I think it's unlikely that it will go away as it is still very efficient doing what it does (that's why it's wrapped with new technology's applications).

If nature and evolution enhance what is already there to create better organisms, i don't see why our industry should work different.

PS: regarding the COBOL to automatic translation, it's not so easy. Not because of lack of local variables in functions (which a modern compiler will figure out), but because it has a very particular "call" semantics (aka "perform" statement) that can cross "procedure" boundaries (ex: "perform a thru d" where each from a to d are different named chunks of code).
In this scenario you would be tempted to make a secuence of calls, but the problem is that you can jump from inside one of these blocks to another. This, i believe, was the right semantics when COBOL was created, because memory and disk was scarce, but most important, because at the time, modern CPUs didn't have stacks and call/return instructions (if you can imagine such a world :-).

I had to take an editor class and COBOL class in college about 10 years ago. Man there was a lot of paper printing on those computer lab printers. I kind of miss those 3 inch tall stacks of paper that made up each program.

When I moved to the corporate office to program, one of the stipulations was that I had to learn COBOL so I wasn't just using .NET and could help with the other technologies.

I'm by far the youngest person here, but there are plenty of people under 40 who use COBOL daily.

After 2+ years with it, I have to say, it's like writing a novel for ever program, to top it off, we don't even use a relational database, still on VSAM.

As painful as it is, COBOL has made me a better programmer. It tends to make mistakes in logic painfully obvious.

"The line number figure sounds pretty impressive, doesn't it? 220 billion lines of code, 80% of all code lines in the world. Wow, that's really, really impressive... for those people that don't know COBOL at all."

Hilarious, and oh so true.

We love to sit back and watch you young wipper-snappers reinvent everything we've done before!

I'm a lead application engineer at a Fortune 500 company. The application I support has around 3,400 COBOL and around a thousand assembler programs (yes assembler!). We continue to add features to our system every day. We bring in the young ones that have been brained-washed into thinking they can program in a vacuum, and teach them COBOL. The fact that it is in English and is fairly easy to use it a big bonus!

And yes it runs on big iron, which is getting smaller and faster every day. Think of the mainframe as a large server. ;-)

My lovely wife (a COBOL youngster at age 45) works with COBOL software running on VMS on HP Integrity servers. Her company has twice tried to re-create their software (computer-assisted dispatching for 911 call centers) under Windows. They ended up with big messes of unreliable software that have led to their being sued by various large US cities and counties.

As you can imagine, she's now pretty smug about both COBOL and VMS and wonders why my code has all those silly lower-case characters in it. On the other hand, she despairs of ever getting a programming job with anything other than a huge corporate or government bureaucracy.

I work with .NET / Java. But, the large insurance company I work for has lots of COBOL systems. I've dabbled a bit in the code. The worst part is not the language, it's the development tools -- they're the same vintage as COBOL.

We still use RPG II were I work, an IBM mainframe language that was designed for punchcards with a fixed program logic loop. You have not experienced coding horror until you've struggled with RPG II.

I recently created an ASP.NET web service using Fujitsu NetCOBOL for .NET and wrote a blog post about it. After hours of experimentation I created the only non-trivial example of using NetCOBOL to actually do something.

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.

As a college intern with a power utility company based in Staten Island, NY - in 1990 - I was given the job of extending the functionality of their HR application managing overtime approvals/accounting.
I spent a couple of weeks collecting requirements - until it was realized that this thing was required to be written in COBOL - of which I had no experience.
I spent the next three months in a COBOL crash course.
I had 3 weeks left to write the app - I managed to convince my manager that it was a futile gesture. I wrote them a Lotus 1-2-3 macro based solution, network aware, distributed, which not only met all their requirements, but at the end gave them a data dump that they could load into the mainframe.
I was never as relieved to get out that place - COBOL is not for me!

Last job at a electric/gas company for a large city was using .Net and Sql server, but ultimately at the very core, was a mainframe running cobol. Current job at a print manufacturer, using .Net, but all pricing (and lots of other stuff) comes from a custom Cobol application.

The Cobol crisis will become apparent when old cobol programmers retire and younger developers don't apply for empty positions because they don't want to work on such an old language. Thats when all cobol work will move offshore.

"IBM mainframes and DEC VAXes and Alphas don't have "Blue Screens of Death". They measure their uptimes in *YEARS*."

The AS/400s (admittedly not mainframes) that I've seen get IPL'ed (essentially rebooted) about once per week. Isn't that fairly common?

I am almost exactly the same age as COBOL, which was the source of (most of) my income up to around 1989. I know that code I wrote in the early 80s is still in operation: I still meet - occasionally - the people who run it.

But I got better. 15 years or so of mostly VB (living on in my world as Excel VBA) has now given way to the majority of my time being spent with Ruby (and the obligatory, but not exclusive Rails). Very little that I have written since my COBOL days beyond maybe the last five years survives. That's probably not a bad thing.

At my company we upgraded to a popular Accounting/ERP system last year. Its written in COBOL.

I have a hard time believing that cobol has anything to do with mobile phones. I also have never met a cobol programmer. Then again, I have managed to stay away form the horrors of insurance companies, car rental places, retail banks and the like.

@Chess: Why does it have to move offshore? There are plenty of developers here in the USA and if we paid them properly then they'd work as COBOL developers. Havent we yet learned that code coming from $12/hr offshore developers is so sub-par that 1/2 of it has to be rewritten again, over here in the States? I guess not. You get what you pay for.

i have 5 years of hands on cobol experience in a germam insurance company

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

in some ways that it is the truth

in our company we have code that runs bugfree since 1992, furthermore the vast amount of the transactions are done with cobol
in contrast the company is slowly changing the running applications from cobol to java, guess what ... 100 bugs everyday in production :-)

in the end it's not the language, but in the COBOL times and in 'those' companies (insurance, bank, etc.) the it-departments tended to produce high quality code with special quality service groups... today there are deadlines and the trinity where time and budget always wins over quality

There is an office with 100+ COBOL guys cranking it out, less than 4 miles from where I'm sitting right now. I've actually met several of them.

These guys are recruited from all over the globe and believe me, they make about 3 times more than the .NET guys they sit right next to.

This company has been attempting to port their systems over to .NET since .NET came out, and they've barely made a dent in 10 years.

In 10-15 years we'll be talking about ABAP/SAP the same way we're talking about COBOL. And the funny thing is, there's still companies paying TONS of money to SAP and its consultants to build systems that will dig them in the same way COBOL did 20 years ago.

Last year I was talking with a contractor in Chicago who recently developed a replacement for a COBOL based insurance package. It was running on Texas Instruments TI990 hardware under DX10 - an OS which has not had an update since 1984 and a hardware platform which dates from 1973. It was maintained by an 85 (yes eighty five) year old guy who came in a couple of times a week.

Jeff: So what?
Commenters: It is possible and typical to write good code in COBOL.

I can also attest to repeated attempts to replace existing large scale application systems consisting largely of Cobol. These have been a recurring nightmare to be involved in, though most have never made it into production before being called off at terrible expense.

> Cobol is still alive but it's death is closer than ever because people that knows it are going to be retired soon...

Not really (about retiring soon).
I'm 39 and I did COBOL for Alcatel back in 91. I'm maybe 20 to 25 years to retirement.

COBOL is just and only a programming language. As long as there are legacy programs running COBOL or more modern systems running on COBOL's more recent incarnations (OO COBOL and COBOL 2002), the language is pretty much alive since it's being actively used.

If we don't know any COBOL programmers it is because of the same reason we may not know any car factory workers, or scientific investigator. We tend to stay around what we do. But you do go to USENET or to COBOL specialized websites and suddenly you'll see where they hang out and your perception changes.

I agree the self-promoting text is perhaps a little too over the top. Couldn't say for sure. But the world is more than just business applications oriented towards the desktop. There's an whole world out there that powers nuclear stations, does weather prediction, maintains giant warehouse inventories, help management of commercial ports, dams, etc.

Certainly not a popular programming language these days. And definitely not the language of choice if one is given the option (which used to be a lot more limited back then).

But it's just and only a programming language. And if there is the need to support a legacy system, even if that means upgrading it, or creating something new, any of us can learn the program language, or on some cases revisit it.

I'm 32 but my first job out of college used COBOL a lot.

I was never trained in COBOL. It was instead one of those languages where you just sort of infer by staring at it long enough.

But your snippets above underscore why so much of the world's code is written in COBOL - it takes way more lines to pull even simple things off. Back when COBOL was the norm, programmers were rated by the KLOC - thousand lines of code.

When you see mentions of COBOL statistics, the #1 reason cited for the declining population of COBOL programmers is "retirement and death". Young people (myself included) don't want to use COBOL and would rather code in Java or C# or even C++ or something. So the number of COBOL programmers is in decline though there are offshoring companies willing to take up the slack. Problem comes when the companies employing those older programmers decide to cut them loose early to avoid paying pension and retirement benefits since now they have low cost replacements.

And as nicely as I can put this, a lot of the COBOL programming population is old and from a generation where computer programming was akin to candle making - you learned how to do your one thing (your trade) and you spent the rest of your life doing that. And there's fields where this is a perfectly legitimate career course but not modern programming. So the reason a number of COBOL programmers are still COBOL programmers is because they just don't want to learn anything else or change.

We once had people come in to train us on VB.NET (back in the .NET 1.0 era), and some of the programmers were furious when they thought they would be expected to learn OOP. One of my coworkers in that job was a 76-year-old grandmother who was only working to get away from her husband. When something came up she didn't want to do, she'd just refuse to do it, or threaten to quit. And this was seen as acceptable somehow (context: it was a state government gig).

So I was never so happy as when I was finally out of that job.

What I don't understand is that so many people are saying stuff like "This here newfangled Java code has a lot more bugs than our COBOL-software".

Of course the COBOL-version has less bugs: It's been debugged for 30 years! Even if someone says he's been working with some specific piece of code for the last 25 years, he still hasn't seen 95% of all the bugs that were in there in the first 5.

This is not to say that COBOL is without merits: It's probably really fast, lightweight and probably runs on any platform you throw at it, which, in the really long run, is more important than code structurability (who cares if your code is well-structured if it doesn't run on any hardware?).

But let's not pretend that if you write some COBOL-software today, it will still be used in 40 years: Those software lifespans are either long gone or at least not limited to COBOL: Given the right company policies, you'll probably find old Java-code still being used in 40 years time as well.

The fact that you've never met someone who programs COBOL for a living says way more about you and the systems you are accustomed to building than it does about COBOL.

If the programs that are compiled from COBOL simply ceased to exist modern life would follow quickly. Used an ATM recently, I'll bet you whatever you like that it talked to some COBOL code before it spit out your $100.

COBOL code lives on because the systems that were built with it are functional AND critical.

I also have never had to deal with COBOL but looking at your example you can see why there are so many LINES of COBOL. Perhaps their is a better measure than sheer line count.

sorry there not their

The fact that you've never met someone who programs COBOL for a living says way more about you and the systems you are accustomed to building than it does about COBOL.

If the programs that are compiled from COBOL simply ceased to exist modern life would follow quickly. Used an ATM recently, I'll bet you whatever you like that it talked to some COBOL code before it spit out your $100.

COBOL code lives on because the systems that were built with it are functional AND critical.

>>Burgun Wrote: "Yep, I know there aren't many of us left and some of the work isn't as exciting but I'd rather earn what I'm earning rather than competing with some kid just out of high school who'll charge fifty bucks to set up a web site that will be probably full of security holes and be unmaintainable in a month."

What are you on about? I can't make any sense out of that.

Where would you like to meet, Jeff?

Part of my first job was to move around the various parts of the organization so I got 1 month of COBOL training and 3 months doing programming.

This was 15 years ago and it had one of the best business aka forms user interface designers.
The forms portion was totally separated from the rest of the COBOL, so your COBOL code could take for granted that the code was in the correct format.

You setup how you wanted the form to look and then for each field you could specify what type of data it was(phone, SSN, date, etc) or you could create your own using regexp. Error and informative messages were done in the user interface program and you could have a simple message and there was a link the user could show more detailed info; this was auto generated or could be customized. You could differ the display format from the what the user had to enter so when the user entered a box for a number it would change to remove commas but when they exited the box it was back to having them. Best thing was that dates and other formats that could entered in multiple ways were handled and converted to a specificed format and it recognized those different format.

Still looking for a current tool that would do all that old tool could do without the need for extra coding.

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.

I write COBOL code -- only been on the job for one year, thought it would be a change of pace to do... never took it in college, they got rid of it by the start of my junior year -- and to point out, I wouldn't say the code is "perfect", but for the most part, unless we're cleaning out some old code, or code that still carries out some sort of transaction (but is no longer needed and we want to remove it to reduce line count), there can be programs that haven't been touched since 2004 (our project started in 2002, still in HS at this point!)

Since it is most transaction oriented - one program for one type of transaction (say, DB2 into some flat file or vice-versa), once that transaction works, the code stays that way indefinitely until there's some new code needed to add. This only happens if some business groups says they need something new added. And most of the time it could be done elsewhere than in the mainframe processing.

This will also say why it isn't likely to be replaced. The obscene amount of datasets, databases, transaction processing code, etc, would take forever, and then some, and besides, it's so incredibly well suited for its purpose, there's almost no reason to change it. That, and it's cake to pick up. But really, no one uses it for anything else, and obviously for good reason.

Have a friend who's parents make a living being the only people in the state who know COBOL as well as they do. They maintain and update systems decades old for organizations too cheap to completely overhaul them.

I took Cobol as part of my Computer Science degree in college but have avoided applying for any jobs that required it (it wasn't a good experience). Very much happier working in .Net.

Most of the places I saw jobs for Cobol (I applied/searched alot when I first graduated) were banks and insurrance agencies. I pitty anyone that took those jobs.

The State of Michigan was looking to hire a Cobol programmer a year or so back... they wanted an entry level person though. Good luck finding that I say, no one straight out of college is going to have enough Cobol experience to realistically work on large scale Cobol systems.

I bought a book on COBOL 2002 and I couldn't understand shit of it.

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.

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.

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.

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.

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

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

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!

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?

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!

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.

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

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

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

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

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.

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.

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

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.

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.

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.

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.

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!

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.

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

COBOL is the one that making sure your money is safe at the bank. I know it's an ugly language, but no other language does better job. And that's a fact, Mam.

I learned ANSI C and COBOL in college. I went to work after graduation in 1995 for a telecom company. I was hired as a C programmer, but when I arrived at my new job they said "We see you have COBOL skills, we want you to work in COBOL instead of C." The billing system was on IBM mainframes and the Usage system (reading the switches) was on Tandems, both in COBOL, using DB2. I worked with hundreds of other COBOL programmers until 2002 when I was laid off when most of our work was outsourced to India. Many of us went to other types of work, a few are still working in COBOL. I trained to make the switch to C#.Net with SQL Server over a year ago, but getting a job without experience in it has been impossible (and my bachelor's degree is in Computer Information Systems.) WILL PROGRAM COBOL FOR FOOD!

It is one of the great great ironies of our modern software industry that so many of the younger generation of programmers are so unaware of what technologies are actually really out there and working. Sure a lot of this modern "stuff" sounds great, but hell, it just doesn't work!

What good is a fancy, flashy interface if it just keeps eating the data? What good are dynamic languages if they are built on flaky foundations. If you can't trust the stability of the system, it would be madness to actually use it for something critical, won't it.

Over twenty years ago, when I got out of school, the big revolution was to get out there and re-write all of those legacy COBOL systems. That was the cool-aid that we all drank back then. But as is clear with the above facts, decades later and most of those systems are still humming along just fine, while their supposed "modern" replacements died inglorious deaths. And in many cases those "legacy" jobs supporting those systems have paid better than hacking at the modern stuff.

It's just another one of those cruel jokes in the software industry. We get all of these people running around, talking up the next wave of technology, telling us how great it is, how it will change everything. But ultimately, except for a few sample systems here and there, it ends as each new generation has bit the dust faster and more painfully than the last. We only seem to be getting better at building worst (but flashier) stuff. Sad, but true.

Paul.

Ha ha entertaining to read about COBOL and these ancient techniques. Myself has not working with something else besides webdevelopment. Besides in school I did some Windows Forms then it has been all Webdev.. Actually I would maybe do some other things besides web, maybe C++?? (Like Qt - that looks cool!).

The problem IMHO is that in your "professional programming career," you have been working with high-tech companies. You want to see COBOL? Go look at a company that processes payroll, or handles trucking, food delivery, or shipping. Look at companies that handle book purchase orders or government disbursements or checking account reconciliation. There's a huge ecosystem of code out there that's truly invisible to those of us who work in and around the Internet; I have the (dis)advantage of having started in enterprise software; I wrote C code that generated COBOL! I was responsible for generating millions and millions of lines of COBOL for companies to move data from one place to another.

Here's another interesting fact: most of the data in the world that isn't text is in EBCDIC, and not ASCII or UTF-8. You and I today work almost exclusively with text or text-based (XML, JSON) data. But I'd be willing to bet that the code running on the computers that handle the shipment of our computers was written in COBOL.

I'm working with COBOL right now. Actually, I'm reading this blog post while on a break from thousand of lines of COBOL code.

I'm not a COBOL programmer, I am just migrating some old COBOL programs to Oracle PL/SQL. And one of the reasons I accepted to work on this project is because I believe I'm somehow helping COBOL to die.

The reason COBOL is still alive, in my opinion, is because most developers are not brave enough to face this awful piece of crap in order to rewrite it in a better language. Having COBOL programmers purposely keeping it alive because it's the only language they know (and they don't want to learn another) also helps.

Anyway, I'm doing my part.

to TJ : Please let me know where I can get one of those $150/hr jobs.

I've been a software developer for over 30 years. When I first got in the business, people made fun of COBOL and predicted its demise. Maybe it's finally happening, I don't know. The language I used during my career has been primarily COBOL. Over the years I've used many other languages, but most of them fell out of fashion and never replaced COBOL.

I was laid off from my last job in December, 2008. Prior to that I worked there for 16 years developing commercial software in COBOL.

The main reason COBOL was used was due to its portability. The software ran on mainframe environments like MVS, VSE, Z/OS, CICS, and IMS. It ran on Open VMS for VAX and Alpha. It ran on many flavors of UNIX. It ran on AS/400. It ran on Windows. Most of the code was shared between all the platforms; the same development teams supported all the plaftorms and there were usually less than 5 people per product.

Granted, the user interface looked like mainframe green screens, but people bought it for its batch processing capabilities, not for its looks.

The last 10 years I was there, several efforts were made to replace the use of COBOL with other languages. Now COBOL, Java, C#, C++, and mainly C are used there. My guess is that the C code will eventually kill off the COBOL.

I still have a few years left in me. If anyone needs a COBOL programmer, please let me know.

There's a simple rule of thumb you can use to know where COBOL is used or not. If the organization in question existed 30 years ago and, at that time, had money enough to use computers, then it most likely used, and still uses, COBOL. If not, then it most likely doesn't use and has never used COBOL.

COBOL is still in use this is a fact! As mentionned COBOL programs still doing business! Companies maintain COBOL applications because it will be too expensive to rewrite them. Moreover lot of companies have based their core system on COBOL applications. So rewriting COBOL applications would be a business risk too high .

BUT, we have to pay attention that this does not mean COBOL programs are still under control. Several generations of developpers have coded those applications. COBOL applications knowledge has often gone away following the developpers. Consequences are: code duplication, fear to modify working, regressions... To ensure the ability of our COBOL programs to evolve we have to control them again. That is to say to instantly measure impacts of a code modification.

Newer language (Java, .NET, PHP, C) used XUnit framework to write unit tests (JUnit, NUnit, PHPUnit, CUnit). RPG has its unit test framework too: RPGUnit. The first need is to have a simple tool to write and automate unit tests on new code or on legacy code (to ensure no regression when delivering a code change or ensure capability of COBOL prgrams to interact with recent programs written in new generation language).

COBOLUnit (http://cobolunit.org) is a simple open source Unit testing framework to write and run repeatable tests in COBOL. It is an instance of the XUnit architecture for unit testing frameworks.
This framework is a way to modernize our existing application and made them more agile!
COBOLUnit is young and needs you to evolve. Have a look on COBOLUnit (http://cobolunit.org) and send your feedback to the COBOLUnit community (or join it) to make this initiative fit your needs.

Honestly.
Why do you FEAR COBOL?
...please, no "cute" answers.

I have never programmed in Cobol, but I learned some concepts and, although I did not like it, its simplicity and effectiveness is certainly something that keeps it alive. Since the language and the tools are fairly crude, your brain has to work for a living. You have to *know* how to compile programs out of object files. And, you have to understand your business problem inside out or you will not get anywhere otherwise.

Compare that crude simplicity with modern languages which pamper us with development tools, complexity, GUI... software development has *worsened* as the tools have improved. When I say "worsened", I am saying that there are more failed project (on a big scale) than ever before - despite the "body of knowledge" and "improved" tools.

Aside from its simplicity, Cobol offers a standard for everything in the pipeline, from user interface (green screen) to database (VSAM).

All our methodologies are designed to deal not only with complexity but also with ineffective development tools, ineffective build tools, shitty environment (service pack on top of another service pack), memory hogging, garbage collections which don't work as they should half of the time...

The school of simplicity was burried under OOP school of complexity. Niklaus Wirth developed an Oberon system (which was OOP all the way) which also provided end-to-end software environment (development and runtime) and worked beautifully. I am not saying that Oberon was perfect but it solve some of the burning issues that arise from complexity.

Unfortunately, the industry embraced piece of garbage called VB, dll hell, Windowses and the rest is history.

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.

I work in an office where there are about 40 COBOL developers. We also have an Indian office (10+) and UK office (a couple). They are around and I can assure you, COBOL isn't going away for the product created here for a long, long time - if ever.

The nature of the application means that it gets updated yearly and we'd do about 4 releases a year.

Thankfully, I work on on of the frontend products, using Delphi. We also use C++ and C# here.

What's the point of the video?

COBOL isn't and was never meant to do WinForms. Reminds me of the Monty Python skit where they go after mosquitoes with shot guns.

If you want to process a batch, i. e., take 1 or more dataset, apply procedural logic to them, and create a new dataset, COBOL can reliably get the job done.

WHY IS IT ALL CAPITALS? MY HEAD HURTS NOW.

I went to a "1 year wonder" school in 1986 and we were taught BASIC (Not VB), COBOL and RPG III. Got hired in a RPG shop in 1988 and we are still using RPG to this day. We even have some old FORTRAN apps running on old VAX workstations. I have done a little COBOL moonlighting. We are so backwards we still have over 75 Twin-ax tubes in our shop hooked up to our IBM iSeries. I now write some .net front ends,but I have to admit, I don't like it when I have to put files on anything but the IBM because it never ever "Eats" the data.

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.

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

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

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

Euthanasia?

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.

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.

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.

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

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.

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

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

"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

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?)

That last was directed at Alex Turner. Sorry.

COBOL is not going away any time soon.

Mission impossible:
- 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

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

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

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.

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.

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.

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

http://www.coboloncogs.org

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

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

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

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

sorry :(
Bad firefox.

@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?

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.

@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?

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.

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

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

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.

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.

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

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

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

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.

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.

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.

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

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.

>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

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.

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.

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.

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.

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

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!

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

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

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.

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.

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.

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.

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.

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.

COBOL is having 'Existential' crisis.

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.

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

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

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

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

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

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.

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!

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.

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.

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.

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.

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.

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

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

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.

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!

Cheers,

Bruce

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.

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"
returning xmlDocChild

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.

Regards, Emerson
Architects golden rule - keep the stakeholder happy, stupid.

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

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.

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

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!

yes exciting

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.

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]

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.

Artificial Inelegance.