Strategizing Mainframe Scheduler Migration to AWS

Mainframe environments typically involve complex batch processing tasks used for critical and time-sensitive business operations. As mainframe applications are migrated to AWS using AWS Mainframe Modernization service, similar batch processing capabilities are required.

This blog explores the approach and patterns for selection and migration of the mainframe job scheduler to AWS.

Overview

AWS Mainframe Modernization is an AWS service providing pre-packaged fully-managed cloud-native environments with pre-integrated toolchains.

Schedulers in mainframe help to submit, manage, and track the execution and output of batch jobs. As a part of the mainframe application migration to AWS, scheduler migration is one critical area for consideration. There is no one size fit all for mainframe scheduler migration. To understand the approach for scheduler migration, we have outlined the high-level steps in this blog.

Approach:

Step 1: Assess the mainframe scheduler

Generate mainframe scheduler reports to evaluate jobs submitted by the scheduler. The reports will contain the following information

Job definition: Job name and relevant job information.
Scheduling definitions: Examples are scheduling IDs, scheduling dates, environments, jobs, job triggering information, execution sequence, prerequisite conditions, events, and successor jobs.
Resource definitions: Resources needed to submit a particular job, for example datasets, address space or environments.
Calendar definitions: Information of calendar sets defined in the scheduler.
Automated recovery definitions: Information on automated exception handling, for example, abend code and condition code exceptions.
Dynamic Scheduling: Scan source code for API calls that dynamically schedule jobs.

The output of this step will be a scheduler inventory containing detailed scheduler information to be evaluated and used as part of migration. Append any manual scheduling information that you receive from operations or system documentation to the scheduler inventory.

Step 2: Select a migration strategy

Below are popular and successful patterns implemented by our customers.

Pattern #1: Migrating mainframe schedules to same 3^rd party scheduling software vendor – (semi-automated approach)

In this pattern the vendor for the mainframe and target scheduler in AWS remains the same. An advantage is that the functionalities supported in mainframe would be similar to the functionality of the target scheduler in AWS.

The mainframe scheduler produces various extracts containing Job, scheduling, calendar, resource, and automated recovery information. These extracts will be processed through utilities that convert mainframe scheduling information to output files. Adaptations to variables for example JCL paths, file paths and parameters will be needed before importing into the target scheduler. Most scheduler vendors will provide these utilities and migration guidance.

This option would involve minimum adaptation to the output files and is the least complex scheduler migration pattern discussed.

Pattern #2: Migrating mainframe schedules to different 3^rd party scheduling software vendor (semi-automated approach)

In this pattern the vendor for the mainframe and target scheduler in AWS are different. The functionalities supported in mainframe scheduler may have a different implementation design in the target scheduler.

The mainframe scheduler extracts will be processed through utilities that convert mainframe scheduling information to output files. For the scheduling definitions not covered by the conversion utilities, manual interventions would be needed. Most scheduler vendors or System Integrator (SI) teams will provide the utilities and migration guidance.

Adaptations are required on the output file to convert the functionality for the new scheduler. This option would involve complex adaptations to output files and overall scheduler migration is more complex in terms of development and testing.

Pattern #3: Building mainframe schedules using native serverless AWS services or 3^rd party target schedulers in AWS

In this option, the job schedule information is manually built on the target scheduler in AWS.

Build using AWS services – Job schedule information is built using serverless AWS services such as Amazon EventBridge scheduler and AWS Step Functions. For Mainframe schedules which have less complexity, this option should be evaluated. Refer to Scheduling Batch Jobs Solution Guidance on how to build a scheduler using Amazon EventBridge and AWS Step Functions.

Build using 3^rd Party scheduler- Utilizing the mainframe scheduler reports, an equivalent schedule is developed on the target scheduler using Interactive GUI screens and configuration files.

This option has the largest development and testing timeline of the three patterns.The development teams have the option to redesign the schedule definition to optimize it.

Once the pattern and vendor has been selected, additional analysis will need to be completed on dynamic schedules. Dynamic schedules submit jobs based on parameters. They need special considerations and manual intervention for developing a solution in all three patterns.

Step 3: Select Target distributed scheduler in AWS

Customers select the pattern and scheduler, based on IT strategy and mainframe specific technical constraints. By analyzing the reports and mapping the functionality between source and target scheduler, gaps will be identified. Using the identified gaps and scheduler pattern guidance, the choice and level of effort to migrate the scheduler will be determined.

Step 4: Test and deploy the migrated scheduler

Once the scheduling information is built on the target scheduler, simulated runs need to be triggered on the target environment to test the job flows.

Build test cases based on job dependencies, triggering conditions, resource dependencies, calendars and automated recovery mechanisms. Compare job execution reports from the mainframe scheduler to reports generated from simulated runs of the target scheduler.

Best practice is to convert the scheduler during the early phases of mainframe application modernization. This will allow the converted schedules to be tested through different phases of application testing. Testing the application batch jobs through schedulers, will bring in testing efficiencies by reducing manual intervention.

Once the target scheduler is thoroughly tested, deploy target scheduler to AWS production environment and complete post deployment validation including parallel tests for Go Live.

Step 5: Train the support team

In depth role-based training covering the different functionality, features and processes for the new scheduler is necessary. Based on the pattern selected for migration, the amount of training needed would vary. Involving the workforce as part of the migration journey will speed up team tool adoption.

Solution Architecture

The diagram in Figure 1 shows the AWS Mainframe Modernization service integration with a 3^rd Party scheduler.

AWS Mainframe Modernization service and 3^rd party scheduler integration

The diagram shows a 3^rd party scheduler hosted on an Amazon Elastic Compute Cloud (Amazon EC2) instance with high availability. The scheduler orchestrates applications’ batch jobs on the AWS Mainframe Modernization service using APIs. An Amazon Aurora database is used for maintaining the configurations required to run batch jobs.

Scheduler and AWS Mainframe Modernization Service integration

Figure1: Reference Architecture

This architecture is designed for high availability of the 3^rd party scheduler by utilizing Amazon Aurora as the database for the 3^rd party scheduler configurations. Aurora has a unique architecture that separates out storage and compute layers. The storage layer replicates across multiple Availability Zones to provide high durability and availability. For additional database options, check the Vendor documentation to determine what database engines are supported.
The 3^rd Party scheduler is integrated with AWS Mainframe Modernization service through APIs provided by the service. Invoking APIs are built into templates for the 3^rd Party scheduler and used to manage the lifecycle for batch jobs. Functionality supported includes job starting and stopping, determining job status and fetching job execution logs.
Jobs in 3^rd party scheduler have ability to invoke APIs for starting, stopping and providing applications status. For e.g., for applications to be redeployed, one can stop and start the application from scheduler without any manual intervention.

Detailed integration templates utilizing the AWS Mainframe Modernization APIs have been built utilizing BMC Control-M and Stonebranch Universal Automation Center schedulers. Learn more about how to design and implement these solutions by following the AWS Prescriptive Guidance:

Summary

For mainframe scheduler migrations customers need the right tool for the right job, that is aligned with the IT strategy and legacy technical constraints. This blog post helps you understand the pattern and approaches available for Mainframe scheduler migration.

AWS recommends connecting with a specialist for mainframe modernization at AWS at (mainframe@amazon.com) as you embark on the journey.

About the authors

AWS Cloud Operations Blog