Evangelizing Mainframe
Print Email

COBOL, APIs and the Future

There was a time that most of us still remember when systems programmers could write Assembler programs straight into their green screen, and application programmers wrote COBOL programs quickly and accurately. Of course, some people remember when everything was done on punched cards or even paper tape. But the idea was that you just wrote whatever you needed and a couple of attempts at a compile gave you a working program that end users would start using straightaway. But nowadays, things have changed.

For a start, those end users had probably been waiting a little while for their new application to have been written. The program might have been modified a couple of times in those first few years, but no one left any documentation. Much the same routines got written into each program. And nowadays, hardly anyone can write COBOL.

At many sites, those COBOL programs have been working well for 10, 20 or perhaps even 30 years. But nothing lasts forever, and business processes change over time. So, somehow those programs need to be updated. And the answer to the problem is to use APIs.

An API is defined on Wikipedia as a set of subroutine definitions, protocols and tools for building software and applications. A good API makes it easier to develop a program by providing all the building blocks, which are then put together by the programmer. An API specification can take many forms, but often includes specifications for routines, data structures, object classes, variables or remote calls. POSIX, Microsoft Windows API, the C++ Standard Template Library and Java APIs are examples of different forms of APIs. You’ll probably find that most people are using representational state transfer APIs, NoSQL/MongoDB JSON APIs, or even SQL.

As I said earlier, COBOL programmers used to put their favorite print routines, for example, in every program they wrote. And that means that the same lines of code could turn up a dozen times at any particular site. One advantage of using APIs is that you find your best print routine, or you get another one, and every program that needs to print connects to that one program. No more duplication.

The other big advantage is that the code connecting to that API doesn’t have to be written in COBOL. In fact, it’s unlikely that it ever will be written in COBOL. And that means people under 50 (and perhaps even under 30) can work on mainframe programs, making them available to modern interfaces. It means, for example, that insurance salespeople no longer have to collect details from a client and send a form for someone at a head office to type into the computer so that a batch COBOL program can be run that will send out a quotation for the salesperson to show the potential client a week after they originally met. Now, using the same backend code, the salesperson can use a tablet or laptop to enter the necessary data for a quote to be displayed almost immediately. The salesperson can then change the figures around until the client is happy that the product they are buying is right for them. And that brings a huge business advantage.

The other huge advantage of using APIs is with DevOps. The idea behind DevOps is that new versions of programs can be created in very short time periods often by combining existing APIs. Each new version can be used immediately, and ideas for making the program work better, or for improving the processes that the end user has to go through, can be incorporated into the next version. Again, the better a program works, or the more optimally that an end user can get work done, gives an organization a business advantage over its slower competitors.

In short, using APIs means that organizations can re-use the best parts of their existing programs. It means that new or updated applications can be created much faster than ever by combining existing APIs. It means that programs can be documented. And, most importantly it means new young programmers can access older COBOL programs and use them to create new and dynamic programs without needing to understand anything about COBOL program structure and COBOL programming. It means that organizations adopting this way of working are getting a business advantage over their competitors and will still be in business in the future.


Trevor Eddolls is CEO at iTech-Ed Ltd, an IT consultancy. A popular speaker and blogger, he currently chairs the Virtual IMS and Virtual CICS user groups. He’s editorial director for the Arcati Mainframe Yearbook, and has been an IBM Champion every year since 2009.

Posted: 9/20/2016 12:00:05 AM by Trevor Eddolls | with 0 comments

Print Email

Please sign in to comment.

Sign In


Comments
Blog post currently doesn't have any comments.

Join Now!