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

Regular Planet Mainframe Blog Contributor
Trevor Eddolls is CEO at iTech-Ed Ltd, and an IBM Champion since 2009. He is probably best known for chairing the Virtual IMS, Virtual CICS, and Virtual Db2 user groups, and is featured in many blogs. He has been editorial director for the Arcati Mainframe Yearbook for many years.

4 thoughts on “Tell me about COBOL”
  1. I have been told by some who offered their expertise to the US states with issues blamed on their COBOL systems that mostly the issues were not in the mainframe COBOL systems, but were in the front-end new-technology systems.

    REST interfaces to mainframe data (DB2, VSAM) through CICS web services can provide high performance and scalability, but performance suffers if the approach is to simply use general access software like ZOSConnect and to leave it entirely up to the front end logic to marshal all the data it will need for a task through multiple requests. Thus organizations write COBOL or PL/I API programs to handle the data and prepare the messages for ZOSConnect.

    Generating such COBOL web service APIs has been the development emphasis in MANASYS Jazz (https://www.jazzsoftware.co.nz/) for the past few years; a few clicks will create a CICS web service offering enquiry or update for back-end databases. In a few more months the next major release of MANASYS Jazz will also build a client-side C# interface. Under all of this are standard languages appropriate to the platform: COBOL for the mainframe, C# (and in the future Java and others) for the client. An easy solution to the COBOL skills shortage!

  2. As a retired COBOL programmer analyst and MVS systems programmer I have a few comments. I was responsible at various points in my career for accounts receivable, accounts payable, and marketing programs. I also have written COBOL programs that parsed SMF 14, 15, 17, 18 30, 62 and 64 records for dataset and program usage among other things.

    First and organization needs to know how their systems work down to the program level regardless of language or system. It needs to be able to test all changes including those to user control table. After doing that it can determine long term staffing needs. A company can train their own COBOL programmers. In the 1970s the company I worked for sent people from other departments to classes at Chubb for some weeks (it’s so long ago I don’t remember the details). Organizations do need people on staff who know both the organization and the systems even if they are packages. They should know how to make changes and fixes, then test them and put them in production. While I am biased in favor of COBOL and the z series, most of these things are true regardless of language, package or organization grown, and platform.

    Maybe CO\BOL and z should be replaced but it may be smarter to make COBOL and z the backbone of the systems that run the organization.

  3. This is a training and investment problem. Pure and simple.
    I work with some companies (Banks) in Asia. If you go onto the IT floor, from one end to the other are young people. People in their twenties and thirties. What are they doing? Writing Cobol programs and maintaining the Cobol applications. I asked one of the chief managers about shortage of young people to do their Cobol programming. They have no shortage. They have internship training programs that take people from university and they train them in Cobol, in progamming and other mainframe IT skills. They pay them while they are in training and then they have the pick of the best of them when the training is completed. There is stiff competition for these training places, students want to join them.
    In the UK there is a group at Wolverhampton University that encourages interest in mainframes but it’s too difficult to get mainframe skills onto the curriculum. The group is an extra-curricular group and it is popular. One of the students wrote their dissertation on a mainframe topic and now works for a major software vendor. There is not a shortage of interest, there is a shortage of investment in training by companies, it’s been too easy to poach skills from elsewhere or to outsource or offshore. Now this lack of investment is coming home to roost.

  4. I am a partner in an consulting firm, I also taugh cobol at Pace university and other schools in the nyc area. We have not had a cobol customer in over 5 years!!
    All our clients are ecommerce and web developement!! I use the hercules/tk4 mvs emulator to run IBM cobol billing programs on dell pc hardware, they run much faster and better than
    when we had IBM 370’s and system 3’s back in the 1980’s
    The hercules/mvs simulation is fantastic!!!, we had considered buying a used Z system years ago when we scrapped the IBM 370(because of the cost of office space in nyc),
    I like working with IBM software, Microsoft software and java, Html etc.
    My cobol programs work fine on my dell computers and my IBM mvs works fine, Java, c++, c#, html, all work on the same dell hardware!!!
    You do not need a mainframe to develop cobol programs.
    all of our new client work is in java, html, c# and cobol, if a client will let me write the system in cobol(sometimes they do).
    all of the hysteria about cobol’s age is nonsense, all of the great demand for
    cobol programmers is nonsense!!
    The world has always been divided between Maintenance of old software
    and new applications!!
    Traditional software programming languages(cobol, rpg, pl1, assembler)
    are much easier to fix and maintain that object oriented languages!
    Object oriented languages have a million classes and constantly grow
    as new classes are are added.
    Cobol will always be around in some form because a traditional language
    is always easier to maintain than systems written in object oriented
    languages.

Leave a Reply

Your email address will not be published. Required fields are marked *