Truths and reasoning behind mainframe modernization

Mainframe modernization offers a host of benefits, including cost savings and preserving investments in legacy applications, but is it the best strategy for your IT department?

Vendors have recently touted the idea of mainframe modernization, which is a slight oxymoron. Modernization schemes do, however, offer a path for porting mainframe applications onto the distributed tier.

The mainframe modernization concept
The key to mainframe modernization offerings is moving an application to Windows or Unix while leaving most of it intact at the source level. With this premise, the targets for most of these offerings tend to be “legacy” COBOL CICS and batch applications. The methods for moving applications vary but tend to share these aspects:

  • Programming languages. Several distributed COBOL compilers are available. The most popular is Micro Focus COBOL, which has been around since the ‘80s. Other modules written in languages more familiar to distributed platforms, such as C, C++ or Java, are much more easily transferred with a few tweaks to the source.
  • Data repositories. Probably the cleanest type of conversion involves a host DB2 application that can be redirected to a distributed relational database management system (DBMS) such as UDB, Oracle or SQL Server. The distributed platform also has several open source DBMSes to further reduce costs. Vendors have different ways of dealing with Virtual Storage Access Method (VSAM) datasets: Some simulate VSAM clusters in native distributed file systems while others provide a DBMS back end that includes some code to convert VSAM file calls into SQL.
  • Transaction processing emulators. Vendors usually offer some sort of CICS emulator that supports most of the application programming interface (API). In this case, the command calls go into emulation software that provides CICS-like facilities. I am currently unaware of an emulator for IMS databases or online transactions.
  • Batch. Some schemes include tools to do one-time conversion of job control language (JCL) into scripts. Others run the original JCL through a runtime interpreter.

Porting most applications will be more involved than a recompile. Potential issues include PL/1 and assembler programs that must be rewritten or retired. Some code may have to be modified for a subset of CICS commands that aren’t fully emulated. Finally, there may be a little piece of the application, an IMS database or corporate utility that cannot move to the distributed platform. In these cases, some allowances must be made for a trip up to the host to fulfill the functionality.

The advantages of mainframe modernization
Mainframe modernization proponents point to its several advantages. First, modernization preserves investments in the legacy application. This can be significant as an enterprise may have mature, robust mainframe applications that were making money for years. Second, the code is thoroughly debugged, tested and predictable. Finally, porting preserves years of experience and knowledge of maintaining the application.

Vendors say that porting an application is less risky than rewriting it. As previously mentioned, old software is tried and true while rewriting an application from scratch is time consuming, expensive and perilous. Vendors point to surveys that show the large percentage of conversion projects that fail.

The last and most compelling reason for mainframe modernization is cost savings. Perceived expense versus the value of the mainframe is perhaps the biggest sticking point. Both sides of the argument can produce endless case studies and surveys to persuade, but there is no magic formula for converting mainframe million instructions per second (MIPS) to distributed SPECints. Furthermore, software performance differs depending on the platform, and that part of the battle must be analyzed case by case, application by application.

Is mainframe modernization really a good idea?
Ultimately, modernization is the quintessential judgment call depending on a corporation’s long-term goals, culture and the applications involved. Enterprises will have to look hard at the perceived versus actual savings, carefully distinguishing between chargeback costs versus money spent. Personnel and environment costs must also be considered.

A company will also need to look at its long-term vendor relationship. After the conversion, the enterprise may be free of IBM’s hardware monopoly, but it will be stuck to the emulation software vendor for a while.

The analysis should account for the fact that an application written to take advantage of the mainframe’s strengths might not run or operate well on the distributed platform. Conversely, the ported transaction will not be in any position to exploit Windows’ or Unix’s virtues. Instead, the customer may end up with something like a cat on roller skates.

Finally, it is most important to pick the right application for mainframe modernization. For porting a system, an ideal target would be a small, self-contained COBOL application, without any IMS interfaces loosely coupled to the rest of the application infrastructure. Loosely coupled means other applications interface to it via the network, MQ or batch files. For at least the first round, corporations should also avoid strategic, money-making software.

Mainframe modernization is possibly an unneeded tactical step in a strategic plan. Whether or not a corporation wants to move an application off of the mainframe is immaterial. If an application needs to be re-engineered or rewritten, an enterprise should do it with whichever target platform in mind. Doing so avoids a long-term commitment to a vendor and produces a truly modern application that is well-suited to its platform.

ABOUT THE AUTHOR: For over 25 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.

Dig Deeper on IBM system z and mainframe systems