COBOL: Everywhere and Nowhere

“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 :slight_smile:

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.