LongEx Mainframe Quarterly - May 2021
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:
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.
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.
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.