Longpela Expertise logo
Longpela Expertise Consulting
Longpela Expertise
Home | Press Room | Contact Us | Site Map

LongEx Mainframe Quarterly - May 2021

opinion: Five Ways I'd Modernise My Mainframe

I'm a z/OS systems consultant who has worked on many different z/OS systems around the world: big and small. My clients are very interested in mainframe modernisation, and they're not alone. Mainframe modernisation seems to be one of the most talked about mainframe topics today.

So, how would I recommend sites modernise their mainframe? Here's five ways I'd do it:

1. IDE

Today, there are brilliant integrated development environments (IDEs) available for mainframe developers that will reduce development costs, reduce errors and issues, and help in unit testing. Examples include IBM IDz, Compuware ISPW and Zowe Explorer. Every mainframe site should be using such an IDE. But that's not all.

Each should be properly setup: enforcing coding standards, including standardised 'code snippets' to help coders do things like get an MQ message, write to a dataset, or add something to an error log. They should be setup not just for new programmers, but also so that older programmers will enjoy the new features. They should be part of a full development environment: hooked into the SCLM, and regularly monitored.

2. Micro Services

I believe that JSON microservices are the way to go. And Zowe is an excellent example: using JSON for internal and external communications. All sites should identify key z/OS-based services and resources, and publish JSON services to leverage them.

Something like the Zowe Mediation Layer should be used to manage these services: from load balancing and resilience to features showing what services are available (and if they're up and running), and Swagger documentation.

3. Java

Java has become an industry standard for developing new applications. Java programmers are easier to find than COBOL programmers. Using Java for new applications in many cases makes sense.

Ideally, this code should be as 'platform agnostic' as possible, making it easier to move away from z/OS should it be necessary. Modules with z/OS-specific code should be separated away from other code, with clear documentation of what and where.

4. Clean House

Every site I see has 'old stuff' lying around. From modules with no source, to a CICS region with unused programs, to old datasets that have not been cleaned up. The more application resources there are (transactions, programs, datasets, databases, jobs, JCL, REXX execs, z/OS UNIX scripts etc), the more expensive it is to maintain the application. What's more, changes have a higher risk. With enough 'clutter', and application can be seen as too dangerous to change, and become frozen.

This probably doesn't sound like mainframe modernisation. But I believe that this effort will help resolve some of the issues that would otherwise require modernisation.

I would like to see every site retire all resources that are not used. Similarly, dead code should be removed when a module is updated.

5. z/OSMF

z/OS administration is difficult. There's a lot to remember, and a lot to know. IBM has identified z/OS Management Facility as the tool of choice to address this issue.

To be honest, I wasn't the biggest fan of z/OSMF a few years ago. But today, I see z/OSMF as a must. Every site should have z/OSMF installed and available. Workflows should be uploaded and used when available.

What's Not On the List

You'll have noticed that my recommendations aren't that big, or difficult to implement. And that's certainly a reason why I've recommended them. I see these as real and achievable for most mainframe sites.

Similarly, there's not a lot of new software to buy. I believe that there's a lot of tools and resources around that are free and stable, and can be used.

I haven't suggested getting rid of the mainframe. As a mainframe consultant, you may be forgiven for thinking that this is a reason. Maybe you're right. But I believe that there are cases where retiring a mainframe makes sense: moving to a solution like Micro Focus or LzLabs, or even replacing the applications with something else. However, these aren't solutions for everyone.

I also haven't recommended changes for the sake of change. I haven't suggested rewriting all COBOL programs in Java. Or getting rid of IMS. COBOL and IMS are great, and do their jobs just fine. If you're going to move away from them (and there will be cases where this makes sense), then this should be done for a valid reason: not simply because they're old.


Any site that has decided that they will still have a mainframe in five years' time should be thinking about how to keep it relevant. How to reduce costs in managing it, and how to enable it to remain a part of the site's overall IT strategy. There are a lot of options to do this: not all involve forking out large sums of money, discarding legacy mainframe components, or retiring the mainframe.

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.

Inside This Month

Printer Friendly Version

Read Previous Articles

Longpela Expertise know about mainframes and the mainframe market. We can help managers, journalists and architects with their mainframe questions, projects and problems. Contact us to get your own independent mainframe expert.
© Copyright 2021 Longpela Expertise  |  ABN 55 072 652 147
Legal Disclaimer | Privacy Policy Australia
Website Design: Hecate Jay