In today’s dynamic world of DevOps and Agile software development, the need for continuous, end-to-end automation is more crucial than ever. Modern applications and services combine legacy and recent technologies, with mainframes continuing to play a central role in many organization’s core operations. Integrating mainframe legacy systems into this modern DevOps landscape has become necessary as businesses try to accelerate their software delivery pipelines and embrace continuous integration and deployment (CI/CD) practices.
IBM Z mainframe’s batch processing remains the backbone supporting mission-critical applications. However, aligning the iterative, file-centric nature of mainframe operations with DevOps agility and automation goals can be challenging. Traditional Batch Job testing methods often involve extensive scripting and programming efforts alongside coding file transfer mechanisms to invoke the JCL validation to the legacy stack. This is where the concept of ’JCLplus-as-code’ powered by the SEA JCLplus+ validation/runtime simulation framework comes into play.
The JCLplus-as-code Solution
At the heart of JCLplus-as-code is the SEA JCLplus+ for DevOps Architecture which enables JCLplus+ testing services integration from any IDE and from other services such as REST API, Java Client CLI, and others (see Figure 1).
JCLplus-as-code enhances the versatile Java Command Line Client to automate JCL validation and runtime simulation using JCLplus+ Legacy as a backbone service. JCLplus-as-code facilitates the automation and deployment of automated testing processes via the YAML declarative language. The CLI Java Client’s ability to accept YAML commands via the -tasks (-a) command-line option makes this function even more powerful. The YAML language is a human-readable data serialization format that simplifies structuring declarative instructions for JCL testing (see Figure 2).
This approach allows quality and development staff to declare different test JCLplus+ scenarios without designing, coding, or maintaining complex scripts for each specific testing requirement. Furthermore, it provides a level of abstraction to write and run different JCL testing policies without modifying or adding complex logic to the existing scripts.
A simple YAML task file looks like this:
In this example, we have several top-level elements:
- Connection: Specifies the JRemote manager’s DNS name and port. This is the z/OS image where your JCL testing will be performed.
- Target: Specifies the target logical system name where the JCL validation will occur.
- Tasks: This is where you define the list of operations to perform.
Operation Elements
We have three operation elements under the task’s element: check, edit, and reformat. These operations allow you to define different types of JCL testing and can contain multiple bundles, allowing you to work with various files and datasets. For instance, the check operation within the sample tasks file has one bundle, which specifies a set of JCL files to operate on. In this case, a single JCL file is located on the local system.
Another typical testing situation involves crafting a test case using cataloged procedures modified during a change request. With JCLplus-as-code, we can transfer those procedures from their storage location, bundle them with the execution Jobs, and run a test for this specific scenario. The following testing policy depicts the situation below.
Summary
This article emphasizes the increasing importance of achieving end-to-end automation in modern DevOps and agile software development, particularly when integrating mainframe batch-testing into the DevOps scene. While mainframes remain vital for mission-critical operations, their traditional batch-processing methods often clash with DevOps practice’s automated nature.
To address this challenge, SEA introduced the concept of JCLplus-as-code using the SEA JCLplus+ validation and runtime simulation framework. This approach offers an architecture integrating JCLplus+ testing services from various IDEs and services, including REST APIs. Enhancing the Java Command Line Client enables the automation of JCL validation and run-time simulation through YAML declarative language, allowing users to declare test scenarios without complex scripting creation or modification.
