Tell me about COBOL

Let me start by telling you a story…

Once there was a big town and everyone went to school and learned to read and write and they bought and shared books. They liked reading. Then, some of the townspeople decided that it would be beneficial for everyone if the town had a library. And so they built a small library in a quiet part of town. Some people gave books to go in the library, and some people gave money so that the librarians could buy books. And the library had children’s books, books full of wonderful information for research, and all sorts of story books for people to borrow and read. And soon, the library building became too small, so they built a new library with lots of new facilities and new books. You could borrow books, you could read books, and now they had newspapers and magazines for people to look at. Again, the demands on the library grew and the number of books increased, and so they built a new bigger library with more facilities. It now had a record library, and lots of documents were on microfiche for people to look at. And again, demand increased and so the library was rebuilt with more new books. This time they added computers with networking capabilities, and other modern facilities. But then something strange happened in the town. Almost all the people stopped reading. And the schools stopped teaching children to read and write. And the library was virtually empty day after day. Then, one day, something bad happened in the town. No-one knew what to do about it. A few people remembered that there was a solution to their problem written in a book in their empty state-of-the-art library. But because so few people could read, it took them a long time to find the solution.

And that’s a metaphor for what’s happened in the world of COBOL. The library – ie the mainframe – is as up-to-date as it can be, but hardly anyone can read – ie program in COBOL.

As you know, there were lots of stories in the press last month talking about several US state unemployment insurance systems and their inability to handle the increase in traffic they were getting. An increase estimated at 1600 percent. And, as you’ll remember, the press blamed the COBOL programs for being 60 years old and the mainframes they were running on for being over 50! And some reports even went so far as to suggest that the data should be in the cloud and the processing should be on a modern platform.

Mainframes have proven security, reliability, and scalability. That’s why the data and mission-critical application are still running on them. Then there’s the fact that they can handle more data and transactions while needing fewer people to look after them than distributed systems. It’s a whole order of magnitude larger in scale.

COBOL was designed by CODASY (the Conference/Committee on Data Systems Languages) in 1959, but it has been updated since then. In 2002 it became object-oriented. And it was updated most recently in 2019. It’s far from being obscure because it’s the programming language behind most ATMs, for example. And it hardly needs saying that mainframes get updated pretty much every year by IBM. Those unemployment insurance systems may not have been running on z15 Model T02s, but they weren’t running on some ancient hardware using System/360.

No, the problem is that the people forgot how to read and the schools stopped teaching it. By that I mean sites stopped programming in COBOL and fewer and fewer COBOL programmer were needed, so none were trained.

Worryingly, there must be lots of organizations looking at this situation and wondering whether it could have been them that was in the papers as the people reliant on Old COBOL Programs. Various statistics are quoted, but you can probably assume that at least 75 percent of the Fortune 500 companies are using mainframes. And most of those have COBOL programs running.

So, what can they do to future-proof their business from a similar situation? The first solution might be to go and find a couple of COBOL programmers and put them permanently on the payroll. There are two problems with that approach. Firstly, the COBOL programs are probably running OK and won’t need any (or not very much) tweaking. So, they’ll have two programmers doing nothing, just in case. It’s not a very good business case to put to your chief financial officer. And the second problem is that most of the experienced COBOL programmers are getting close to retirement age. So, even if you did employ two good ones, it’s not a long-term solution.

Perhaps a better solution would be to combine with some like-minded (or companies in a similar situation) organizations and set up a (or work with an existing) COBOL training school to ensure that plenty of COBOL programmers are trained. If there were more jobs, there would be more people available.

The second solution would be to transfer all your COBOL programs to a modern language. And, I imagine they would advise you, at the same time, to change your database and move away from that ancient mainframe. Although there will be plenty of companies that will give you a presentation that this is a good solution – it isn’t!

The third solution is to do something that won’t affect the original COBOL code, but will make it accessible to modern programmers. And that is to use APIs. Application Programming Interfaces can be added to COBOL programs to link them to modern applications. In effect, there is a layer of middleware that will link RESTful applications from the front end with those venerable COBOL programs. Typically, this will maintain security, analytic, and audit requirements. That, in effect, for the time, negates the problem with people not being able to ‘read’. And it allows your organization to move to DevOps ways of working.

COBOL programmers need to be paid a sensible salary to stop them becoming Java or Python programmers, and to still be available when needed. Steps need to be taken to ensure younger people are trained to work with COBOL so that people are available for the next emergency. And, NO, COBOL and mainframes aren’t old out-of-date software and hardware. There’s a good reason they’ve lasted so long.