Blog Post Mainframe Modernization: Automation Makes it Possible

Mainframe modernization initiatives and automation go together like bees and honey. Migrating mainframe applications to a more modern server or cloud-based infrastructure is all the hype — just about every big consulting firm has a practice dedicated to mainframe modernization. Plus, there are plenty of software-based tools on the market to help achieve digital transformation initiatives.

More specifically, there are several products on the market that provide a mainframe emulator-based framework. In addition, mainframe applications must often be re-factored from older code to modern code.

When using the emulation approach, a modification or redevelopment of current business applications should not be necessary. This is possible because the migrated applications are running on an emulated COBOL environment in the same way as on the mainframe.

When going through a mainframe modernization project, automation is one critical area that may initially be overlooked. Automated IT processes, called jobs or workloads, are critical to keeping applications on the mainframe running properly.

These automated processes can be re-created in the modern server or cloud-based environment. However, legacy mainframe-focused workload automation (WLA) tools will often need to be replaced in order to achieve automation across both on-premises and cloud-based environments.

This article explores the steps required to make the transition from legacy automation tools to modern service orchestration and automation platforms.

Overcoming the Automation Challenge

Companies heading down the emulation and re-factoring path often run into the obstacle of re-creating all the automation that kept the mainframe version of their applications running. The problem is that many legacy mainframe-focused job scheduling or workload automation tools — like IBM TWS/IWS and Broadcom — do not work in the new modern environment.

On the flip side of the coin, many companies use cloud-native automation tools that integrate and work with their new server/cloud-based business applications, but not the emulated mainframe environment. Thus, the need for a modern automation platform that can support on-premises and cloud systems together.

The right automation platform should allow you to integrate your migrated mainframe applications with modern technology, such as reusable components, microservices, SaaS applications, and containers, so you can orchestrate automated workflows that span your entire hybrid IT environment.

So how do you keep your workflows running when you make the move?

SOAP Keeps Your Automation Running

A service orchestration and automation platform (SOAP) is designed with today’s hybrid IT environments in mind. SOAPs automate and orchestrate your IT and business processes, securely manage file transfers, and centralize the management of disparate IT job scheduling and workload automation solutions.

For example, you can schedule your mainframe, distributed, and emulated mainframe jobs centrally from within a single SOAP — and even within the same workflow. In addition, the platform enables file transfers across any environment, whether on-premises or in the cloud.

How to Replace Your Mainframe-Focused WLA Platform

It’s not an insurmountable feat to upgrade your legacy WLA to SOAP, even when done in tandem with your mainframe migration. In fact, because SOAPs are an evolution from traditional WLA tools, SOAPs are both complementary and additive to the overall mainframe modernization project.

Real-World Mainframe Modernization Automation Project

As part of a mainframe modernization project, Stonebranch recently helped a large insurance company, based out of Germany, to successfully convert their mainframe-centric job scheduling software to the Stonebranch Universal Automation Center (UAC). The UAC is categorized by Gartner as a SOAP. The insurance company used the ChangeLogic JCOS mainframe emulator, but the process would be similar for other emulators, such as Micro Focus or UniKix.

The initiative had three key steps, as shown below.

Note: These steps would be similar if you were to decide to emulate or refactor your mainframe within on-premises servers or cloud-based servers (public or private). The Universal Automation Center does not care where the jobs are executed and has the ability to connect to any environment.

Step 1: Move legacy jobs to the UAC

This step includes the rearrangement of the mainframe scheduler definitions and conversion of the corresponding job control. This process is done while the legacy WLA or job scheduler continues to operate.

• During this step, the original mainframe scheduler (WLA or job scheduler) information, the corresponding processes, and the resulting dependencies are converted to the UAC.
• The information is then enriched and supplemented with the existing job control language (JCL), used in the z/OS physical mainframe. Not only is the JCL brought into a format that the UAC understands, but all scheduler-relevant information, originally from TWS/IWS, is extracted and used to enhance the schedule definitions that have been re-created.

For the insurance company mentioned above, we used the Stonebranch XCT (Xpress Conversion Tool) to move their jobs from the TWS/IWS scheduler to the UAC. The XCT is a proprietary automated job conversion tool, which transforms jobs run in most other job scheduling or workload automation tools into jobs that run on the UAC. Want to learn more? Watch this short demo about converting Cron jobs or Windows tasks to the UAC.

Step 2: Tag jobs that will migrate, and tag jobs that will not

Using the UAC as a centralized scheduler, any jobs you’d like to continue running on the physical mainframe can be controlled alongside the jobs on the new emulated mainframe.

• Mark jobs set to migrate from the physical to the emulated mainframe. All jobs that will be used to schedule applications in the future server landscape need to be tagged in the UAC database. During this process, all jobs in the job control library will move from the mainframe job control library to the UAC script library. The UAC script library offers additional version management and audit control.
• Mark jobs that will continue running on the physical mainframe. Jobs not tagged for migration to run on the emulated mainframe will continue to execute on the physical mainframe using the original job control library. Only, the UAC serves as the central scheduler for both environments, eliminating the need to use the legacy (WLA or job scheduler) solution.

Step 3: Switch job execution — mainframe to emulated mainframe-on-the-server

• Flip the switch: migrate from the physical mainframe to the emulated mainframe-on-server. Once the emulated mainframe is ready to go, you may start automating the jobs on both the emulated and physical mainframes. All z/OS jobs tagged to run on the emulated mainframe, that were running on the physical mainframe, are replaced with the UAC z/OS jobs (or scripts) running in the UAC. The switch automatically updates workflows that include any emulated mainframe-tagged jobs.

Of course, all jobs cannot be migrated from the physical mainframe to the emulated mainframe. This customer chose to run both in tandem, allowing them to simultaneously develop new jobs that are being created in the UAC to automate cloud and containerized environments, outside of the scope of the mainframe.

Learn More

Want to dive deeper? Download the Mainframe Modernization technical brief, to learn about the process in more detail including workflow diagrams, adding additional job types, customizing jobs via Universal Tasks, and more.