opinion: Should Mainframe Modernisation Include COBOL Retirement?

Sites looking at mainframe modernisation will be looking at options and direction for keeping their mainframe relevant. One possible modernisation option is to retire COBOL, replacing COBOL code with something more modern such as C, C++, Java or Node.js.

But is this a good idea, or madness? Let's take a closer look by reviewing some of the reasons why some think that COBOL has to go.

COBOL is Old

This is true. COBOL dates way, way back to 1959. To put this into perspective, C was born in the early 1970s, C++ in the early 1980s, and Java in the early 1990s. But COBOL today isn't the COBOL of 1959.

COBOL 74 wasn't the first 'upgrade' of COBOL. And COBOL 85 wasn't the last - COBOL 2014 is the latest (to date, IBM Enterprise COBOL includes many of the 2002 and 2014 changes, but not all). COBOL has been changing as new features are needed. We'll talk more about some of these features shortly.

So, while COBOL may be old, that doesn't mean that it hasn't kept up with the times.

COBOL is Hard

There's a lot of discussion about how to get COBOL programmers, and how it's difficult to find them. From this, it's easy to think that programming COBOL is hard.

In the heydays of COBOL, there were a lot of other languages competing with it: including Pascal, C (yes, SAS/C was on z/OS from the mid-1980s), PL/1, Fortran, Ada, and Natural. But in most cases, COBOL won out. And there were good reasons: sites chose COBOL because it suited their needs. It wasn't too hard to learn, and program development wasn't too slow.

There's no doubt that COBOL is different to what many graduates used to Java will expect. But there are lots of resources to teach COBOL. And if there aren't enough COBOL programmers, offer more money: I'll bet you see the numbers of candidates increase.

It's Too Slow to Develop in COBOL

This is an interesting one. I've never seen any studies comparing the time to develop a program in COBOL against other languages. However, I'd bet that a COBOL programmer could produce a program in a similar time to an equally skilled C/C++ programmer. Java may be a little faster, but again, this will probably depend on the environment and the coder.

It's true that many sites struggle with changes or modifications to existing COBOL systems and code. But this is not COBOL's fault. It will always be harder to modify existing code, or develop code that works with existing code. Many Java projects start with a clean slate.

Sites with well-written code, who clean up old code and resources when they're no longer used are in a better place. They will be thanking the stars that they aren't at those other sites with no enforced coding standards, missing source code, and lots of unused stuff lying around.

COBOL can take longer to develop than Java because of change management. Sites sometimes apply one set of change procedures to critical COBOL code that they are less comfortable with, and another to Java code.

Finally, COBOL programmers can be their own worst enemy. Most Java programmers will be using an Integrated Development Environment (IDE) or other tools to speed up their programming. Products such as IBM Developer for System z, Zowe Explorer and Compuware ISPW do something similar for COBOL, and are brilliant. Think colour coding source code, 'stock' code that can be inserted anywhere, and highlighted compilation errors while editing. But I've met many COBOL developers who don't want to use them: they've been developing with ISPF for years, and aren't in a hurry to change.

It's Not Object Oriented

Well, actually it can be. From COBOL 2002, object-oriented COBOL was introduced. The fact is that few people use it. This is probably because many COBOL programmers have been doing it for years, and are more familiar with the traditional COBOL structure.

It Can't Work With Web

Not really true. Later COBOL enhancements include statements to create and read JSON (JSON GENERATE and JSON PARSE) and XML (XML GENERATE and XML PARSE). It also has functions that can work with UTF-8 strings, and features to convert between codepages (e.g., UTF8 to EBCDIC).

Most online COBOL programs run in CICS or IMS: and these have features for working as web services.

You Can't Port COBOL Programs From Other Platforms

This one has a point. COBOL doesn't run exclusively on z/OS: it can run on other platforms. And a 'vanilla' COBOL program created on Windows could possibly run in batch on z/OS. But as we've mentioned before, most online COBOL programs run in CICS or IMS to use their online features. Similarly, few sites use COBOL on Linux, so porting applications from z/OS to these is unlikely.

This is an area where Java becomes interesting. If using standard Java classes to access Db2, and running in Websphere Application Server, then a Java program on z/OS can be ported to a Linux system (or vice versa). Similarly, there can be common Java classes that work on several platforms.

The Cost of Retirement

The reality is that maintaining a COBOL code base is expensive: just as it is expensive to maintain any code base. Although many sites are struggling to find COBOL talent, in many cases this is because they are looking for experienced programmers, and don't have a training pathway for new ones.

COBOL remains an excellent language for what it does: processing commercial transactions. There's not much that C/C++ can do that COBOL can't. Similarly, Java has areas where it excels: particularly in web services. But that doesn't mean that similar functionality can't be performed in COBOL.

The big issue is cost: recoding legacy COBOL programs into something like Java is going to be expensive. Some vendors offer utilities that can automatically perform this conversion. However, these tools are not perfect, and always require manual intervention at some point. What's more, there will always be issues or problems to make this difficult. Think of things like:

• Missing source or copybooks
• Lack of internal knowledge of a system, and why things are done the way they are done
• Load modules not matching source
• Legacy resources that Java can't easily handle. For example, Direct Access datasets, control blocks, calling Assembler modules
• Working with legacy security functions

Once your COBOL code is converted, retiring or retraining your existing COBOL programmers will be another cost to consider. And don't forget performance.

The Cost Savings of Retirement

• CPU. Although Java programs often use more CPU, this can be offloaded to zIIP, saving on software licensing costs. And this saving can be big.
• COBOL compiler. The Enterprise COBOL compiler isn't free, while the Java SDK is.
• CICS/IMS. CICS and IMS are expensive. If running Java in Websphere Application Server, the cost of this software may be cheaper.
• People. Many believe that Java programmers are cheaper than COBOL programmers. Interestingly, salaryexpert.com suggests that in Australia, COBOL programmers are cheaper. Again, it probably depends on the individual programmer.

Bottom Line

The bottom line is that COBOL is great at what it does. There's no doubt that many IT professionals are more comfortable with Java and more modern technologies. However, this alone is unlikely to justify the cost of retiring COBOL.

There will be some situations where replacing COBOL is a viable option. However, the costs and risks involved need to be careful investigated, and compared with the benefits.

David Stephens

LongEx Quarterly is a quarterly eZine produced by Longpela Expertise. It provides Mainframe articles for management and technical experts. It is published every November, February, May and August.

The opinions in this article are solely those of the author, and do not necessarily represent the opinions of any other person or organisation. All trademarks, trade names, service marks and logos referenced in these articles belong to their respective companies.

Although Longpela Expertise may be paid by organisations reprinting our articles, all articles are independent. Longpela Expertise has not been paid money by any vendor or company to write any articles appearing in our e-zine.