The z/OS middleware configuration tool (zconfig) has now reached its 0.7.0 open beta. Capable of discovering and applying middleware configuration and moving teams toward a configuration-as-code model, the latest release includes support for CICS TS, Db2, IMS TM and z/OS Connect.

One of its earliest users was Andrew Twydell, a software engineer in IBM's CICS Developer Experience team. For almost a year, Andrew has been using zconfig to provision and manage CICS test environments, support development work, and help build the Bank of Z sample application. His experience offers an insight into both the practical value of the tool and how configuration as code can change the way teams work.

For Andrew, having CICS environments ready for use is critical to the Developer Experience team. “It’s totally necessary. If we did not have the environments there, we couldn’t test the stuff we’re writing.” But the requirements for those environments are constantly changing. “Being able to set them up in a way that is specific to our needs is equally important,” he says, from the minutiae of the security settings on a specific region to the relationships between regions in a CICSplex.

How it used to be

Before Andrew used zconfig, the systems he used to manage CICS regions varied. The single-server environments were written in plain JCL. With fewer than five years working in CICS, he’s very familiar with the routine for using JCL that thousands across the world employ: find something like what you need, copy it, edit it, and submit it. But even routine changes can easily go wrong. As Andrew puts it, “You might change the high-level qualifier in 19 places but miss the 20th.”

The CICSplexes, on the other hand, were managed with a complex system. “I only ever ran some horrific REXX scripts that somebody else had set up before me,” he recounts. “I would not pretend to understand what they did. I just knew that a CICSplex came out at the end. They were totally unconfigurable and very hard-coded.”

Both systems were inflexible, “and with the inflexibility comes unreliability,” says Andrew. “If it’s difficult to change all the things you need to, you end up starting out three or four times before you get everything right.”

First steps

While Andrew formed part of the initial zconfig incubator to investigate the feasibility of the idea, he’s not directly worked on it beyond that initial month or so of the project. But for practical reasons, he stayed close: “The people on the other side of the office were making it, so we were handed it as test users!”

For Andrew, trying it out for test purposes rapidly turned into getting direct benefit from the tool. “It’s super-easy to get started with zconfig,” he says. “I installed the zconfig Python wheel, did the same for Z Open Automation Utilities, and was basically off to the races” – a process that has become even easier with the introduction of the installation script.

Using the content assist and inbuilt help given by his code editor with the provided schema, Andrew started from an empty YAML file but rapidly built his way up. His first use case was setting up a CICS region with the CMCI JVM server so he could test scenarios with the Zowe Explorer for IBM CICS TS extension.

He found some surprises along the way: the seamless integration with CICS TS resource builder made it really easy to point at an existing definitions file and have zconfig handle defining the resources in the CSD. Plus, it was fast: “It creates all the data sets, initializes them, and has everything ready to start in basically no time at all!”

Understandable configuration

For Andrew, one benefit was immediately clear. “Reading YAML configuration is infinitely easier to understand than JCL,” he says. With the configuration reduced to fewer places, and using a single syntax, it naturally becomes easier to see the full picture. On the other hand, with JCL, “especially once you get procedures involved, it’s much harder to read it and to trace what’s going to happen.”

The approach of starting from nothing and building up configuration works particularly well for Andrew's lightweight demonstration environments. But he can see that, for existing environments and experienced system programmers, zconfig’s ability to discover configuration on the system and convert it to its own YAML format makes it easy to relate to a known CICS region.

What truly accelerated his usage of zconfig though, was using the schema to provide hints in editors that support JSON schemas such as IBM Developer for z/OS, IBM Bob, and VS Code. “It’s a great addition because it actively provides you with the available options or attributes, smoothing the learning curve.”

From configuration files to configuration as code

As Andrew and his colleagues in the CICS team expanded their adoption of zconfig, he noticed changes in working practices. Source code management (SCM) started being used as the source of truth for configuration, so that changes could easily be attributed and the system be rapidly rolled back. Live system updates, which could lead to environment creep, were being avoided. “If I want to change something in the CICS region, I modify the YAML and reapply it. I do not edit the live system”, he says. Essentially, the teams were adopting configuration as code.

Then when Andrew started work on Bank of Z, the open-source banking application designed to demonstrate modern IBM Z development practices, it became an opportunity to test whether the same approach could scale across multiple middleware technologies and teams. “We’re constantly changing the CICS configuration to do more and more,” he says, alluding to colleagues from other subsystems contributing to it as needed. “And we’re successfully changing the same configuration without stepping on each other’s toes.” It goes both ways – this week he was able to understand and edit the IMS zconfig configuration, having never touched IMS before.

Looking back, Andrew sees that it could have been very different. “If I think what Bank of Z would be like without zconfig, I think it would have been a repository full of complicated snippets of JCL that you had to run in a very specific order.” Instead, much of the ordering, dependency handling, and setup is captured directly in the configuration itself. The experience has made it clear to him what the use of zconfig can bring to an infrastructure team: “Maintainability, reproducibility, and flexibility.”

Getting started

Andrew’s advice for anyone starting out with zconfig is highly practical. “Number one, use the schema. I see people trying to write YAML without the schema, but it makes life so much easier.” Beyond that, he suggests starting simple, creating a basic CICS region that you can log on to, and building it up incrementally. If you have access to source control such as Git, commit incrementally, “so that when, not if, you break it, you can roll back and review your history to see exactly what’s changed.”

But if zconfig disappeared tomorrow, what would he miss most? “The ease of use. The ability to quickly create new environments that match my requirements whenever I need them.” Andrew pauses, then grimaces. “Avoiding JCL!”

After nearly a year of using the z/OS middleware configuration tool, Andrew's assessment is surprisingly straightforward. The biggest benefit isn't any single feature; it's that configuring middleware becomes easier to understand, easier to maintain, and easier to reproduce. Whether he's creating a simple demonstration environment, building a CICSplex for testing, or contributing to Bank of Z, the process starts with the same thing: configuration captured in source-controlled YAML rather than hidden across JCL, scripts, and tribal knowledge.

Interested in finding out more? Get an introduction to the z/OS middleware configuration tool.