So a couple of posts by James the other day caught my attention. He addresses the still widespread use of COBOL in many enterprises and how it, not the mainframe running it, is a source of evil.

Before I comment, a little background.

Once Upon a Time

When I graduated from college, I didn’t have money in my back pocket, much less a job. Like many graduates, I listed every technical skill that I had on my resume and hoped for the best. My first response was from a company that needed COBOL help. I had taken COBOL once in college as part of the MIS curriculum and, while I wasn’t a pro at it, I was a pretty good developer and problem solver. I got through the interviews without much of a hitch. I took the job, even though it was COBOL, because it was a great company and there was a chance to move beyond COBOL.

Move beyond I did. I worked on some efforts to take the Mainframe COBOL programs to the PC, a fairly easy port using MicroFocus and XDB (now owned by MicroFocus). We then moved some others down using SQL Server as the back end. That was more challenging as many of those applications were so old that many of the variable names were less than four characters, a limitation at one time in COBOL. You can sometimes judge the age of a COBOL program by the variable naming convention.

My fondest memory from this effort was trying to replicate some actions that had been handled easily by the Job Control Language. One program’s output was another program that took some input parameters and then printed a large amount of pension data for each person. This program was always immediately called by the creating program and needed to be invoked by several others over time. With a little tinkering, the generating program compiled the output into a DLL which was then called by that program, and any other program that needed it.

That’s correct, a DLL written in COBOL. Take that all you Java developers!

My final effort, this was all in the mid-90s before Java was a viable choice, was to take that same system and move it to Visual Basic. The previous effort was designed to be a quick effort to reduce mainframe cycle times (cycles=money). This move to Visual Basic was the follow-on effort to take the 20+ year old system into the client-server era. Forget the next century, 3-tier, n-tier, or anything else. We where willing to get something that would work and be relatively quick.

We were able to introduce all sorts of improvements to the framework. I also got a first-hand look at how efficient COBOL could be for certain activities. It opened my eyes just a bit.

Death to COBOL! Long Live COBOL!

COBOL excels at batch processing. I’m not talking massive complex decision trees here, but taking large amounts of data and running calculations on it. I was able to compare run times for COBOL versus Visual Basic on the PC and the differences were dramatic. I don’t know how things line-up these days, but it gave me a whole new respect for COBOL.

The reason for this performance lies in many of the faults that James finds in COBOL. If is extremely efficient at moving data from one format to another. This can be from a simple storage format into a well defined print format. It can handle very large numbers with strange rules of precision natively. Want to make sure that things line up in a massive print job, use COBOL.

As for CICS applications. Kill them. The only advantage they ever offer now is sharing the code base with any batch processes. That can be useful when dealing with detailed calculations with multiple steps that need to be tracked. It can cut testing way down, but on the whole it seemed silly to me over a decade ago and it surely hasn’t improved.

Why COBOL is Dangerous

I was lucky. I was able to escape COBOL with my technical abilities intact. When the lucrative money for all of those Y2K jobs started to appear, I recognized the career trap. I skipped the easy money and dived into this new thing I had discovered called Document Management.

Using COBOL is not programming. It is only slightly better than writing a simple web page with java script. HTML is not a programming language people! Most COBOL work is just maintenance and consists of updating of equations from the previous year. “New” COBOL programs are typically just the heavy re-purposing of an existing COBOL program.

Edsger W.Dijkstra wrote in 1975, not 1968, COBOL cripples the mind. You lose the critical thinking needed to evolve as a technical expert. I’ve watched it happen. I survived through tenacity and side projects. The only problem is, COBOL is still necessary.

If you are using COBOL, what are you going to do to survive?