The mainframe industry is in a continual state of evolution, requiring ongoing training and development for new professionals. Trainers, mentors, team leaders, and department managers all need reliable access to mainframe resources to ensure their teams are equipped with up-to-date skills and knowledge. As new talent enters the field, the necessity for accessible and effective training has become more pressing than ever.

Continue reading

We love building products our customers will value and draw inspiration directly from the market. For our latest release, we focused on one critical issue: flexibility.

Continue reading

Recently, PopUp Mainframe’s Stuart Ashby, lifelong mainframe learner and long-time GSUK volunteer, was a guest of Amit Sharma on an episode of the Tech Sharmit Podcast Series. Here are some edited highlights.

Continue reading

Platform engineering continues to gather pace in the software engineering world. At PopUp Mainframe, we have embraced the concept to improve how we build products. Here’s a recap of our recent GSUK conference presentation on the topic.

Continue reading

At the recent GSUK conference, PopUp Mainframe presented a session on some of the most useful open-source tools we are using in our lab. Here’s a recap of the information we shared.

Our Journey With Open-Source Technology

Aiming to improve productivity, over the past year the team at PopUp Mainframe has embraced open-source tooling. Open source has been harnessed within the PopUp development team, helping us implement faster approaches, streamline our build process, and automate countless tasks. We have seen wide-ranging and sometimes surprising benefits of using open source with z/OS and now rely on open-source tools to develop, build, and test PopUp Mainframe product features. And, with customers requesting open-source options for their PopUps, we also share best practice to help them get the most from these resources.

In short, open source is important to us. Here, we outline the open-source tools we are leveraging, and the benefits.

ZTI (Z Terminal Interface)

ZTI is a Python application which gives you a full 3270 interface in your command prompt. It removes the need for a separate (commercial) TSO terminal emulator product, while giving you nearly the same green screen experience. ZTI is great for anyone without a TSO emulator, but it has a whole host of other capabilities too.

ZTI enables you to interact with z/OS through command line – running commands, connecting to the master console, and more. This is powerful because you can script these interactions and include them in applications or automation. We are using ZTI in our team to run z/OS commands and utilising it for master console management too.

CBT Tape

CBT Tape is a library of free software for the IBM mainframe MVS, OS/390, and z/OS environments. It has evolved over decades and continues to expand. Useful CBT Tape facilities we have recently leveraged include –

• SHOWZOS – makes MVS control information displayable, such as OS info, software and storage config. This can be web-enabled too.
• WHOSON – shows you who else is logged on to TSO at any time.
• Xmit Manager – enables you to view the contents of xmit files on a laptop, without having to copy it onto a z/OS system first.

ZOPEN Community

The Zopen community offers a range of tools which have been ported onto Z to help make Unix System Services (USS) easier to use. The more like Linux USS becomes, the better, as it makes USS easier to use for mainframers, as well as making the mainframe world more familiar and “standardised” and therefore easier to develop and maintain by anyone. There are around 300 tools in the zopen community.

Ten of the zopen tools are officially supported by IBM and distributed free-of-charge with the IBM Open Enterprise Foundation kit. These are all available pre-installed on our product. A couple of examples –

• Vim: While the Vi editor is available on USS, it’s not very user friendly, and now zopen gives us vim instead. The vim text editor reduces the learning curve for a non-mainframer to be able to make changes very simply.
• Bash: The popular Bash shell gives much more functionality than the Bourne shell (the default on USS), such as auto-completion, which saves a lot of time and makes for a more rewarding coding experience.

While these may seem like small benefits, they do add up and can be the difference between a useable, productive interface, and a frustrating interface which continually slows you down.

Zowe

There are two main components of Zowe which we are actively using in our team: Zowe CLI and Zowe Explorer (a VSCode extension).

Zowe Command Line Interface (CLI)

Zowe CLI enables you to interact with the mainframe remotely and use common tools such as shell commands, bash scripts and build tools for mainframe development. It provides a core set of commands for working with datasets, USS, JES, as well as issuing TSO and console commands. It has a very small learning curve since it provides user-friendly help, giving you all options so you can get started without being an expert. By contrast, TSO commands are very brittle and not user friendly, particularly for someone who doesn’t have a mainframe background.

The Zowe CLI is very extensible too, and there are many plugins available which can be used easily by a non-mainframer, and new features are being released all the time.

Zowe Explorer

Zowe Explorer is an extension for VSCode which allows you to interact with your mainframe LPARs through VSCode. Once you are connected, you can view and interact with datasets, USS and jobs through your IDE. Zowe Explorer in VSCode allows you to ‘find’ objects simply, something which is not simple in ISPF. It also enables viewing of multiple z/OS environments at once, and the compare feature is very useful.

CI/CD Pipelines

We have built CI/CD pipelines to deliver mainframe changes, and we have seen the benefits of robust, reliable, and accelerated build, test, and deployment of code changes. One of our CI/CD pipelines looks like this –

• The pipeline is orchestrated by GitHub Actions, and is triggered when code is checked in to GitHub
• Build is performed using IBM DBB (which is not open source)
• Unit testing is performed using open-source Galasa and COBOL Check
• Artifactory is used to store the binaries
• IBM Wazi Deploy (not open source) deploys the code to the target environment
• For integration testing, we are using Galasa again, this time with Selenium, for end-to-end testing of the mainframe application.

Observability

We have built a mainframe observability solution using Prometheus and Grafana. This has saved us countless hours finding info and troubleshooting and is now a one-stop shop for the team to self-service information. Some dashboards we have built:

• A near real-time list of which z/OS environments we have. With PopUps being so quick and easy to stand up, we create new environments and tear them down often. We now have ready access to the full list of PopUps and other VMs, and their status, including which version of z/OS is running, the status of z/OS, a view of some subsystems on each environment, backup details, and more.
• License information is now available in one place with expiry dates and number of available licenses clearly visible and trustworthy.
• A report to show the usage of DASD volumes, highlighting which ones have usage over a threshold. This helps us manage our lab more proactively instead of waiting for a problem to occur.

We continue to expand our portfolio of dashboards and it is paying dividends for us. The dashboards are also available for PopUp customers and gives them observability out-of-the-box.

Ansible

We also make extensive use of Ansible in our lab – and within our core product. We have built numerous playbooks to manage z/OS environments, including config, software installation, maintenance, and user management. For more details see here.

Where next?

Mainframe innovation is driven by growing demand and fresh ideas from both end-user organisations, vendors, and the wider community. The Open Mainframe Project and other open-source efforts are delivering valuable technologies, and we’re excited about making the most of these advancements and bringing them to our customers through the PopUp Mainframe product.

In today’s enterprise IT landscape, automation and operational efficiency have become a fundamental strategic imperative. At the GSUK conference, the PopUp Mainframe session entitled “Automate the Heck Out of Every LPAR” showcased how automation, particularly using Ansible, is transforming mainframe operations.

Here’s a summary of our discussion.

Why Automation Matters

At the heart of the story, the strategic value of automation sits across three pillars: operational efficiency, customer value, and innovation. For PopUp Mainframe, automation aims to enable scalable, repeatable processes that improve both our internal lab management and customer-facing features and services.

Ansible as the Automation Engine

We presented Ansible as the cornerstone of our automation strategy. It is quickly emerging as a de-facto industry standard to support automating mundane tasks. Its simplicity, powerful z/OS modules, and alignment with industry standards make it an ideal choice for a variety of use-cases. Additionally, Ansible’s marketplace and ease of learning have helped the PopUp Mainframe team quickly understand, devise, build, and deploy our own automation solutions.

Overcoming Technical Challenges

Of course, implementing new technology is never a totally flawless exercise, and adopting Ansible in the PopUp lab wasn’t without its own hurdles. The team encountered issues with VM inconsistencies, z/OS versioning, and password management. These challenges were met with a robust architecture that included GitHub integration, secrets management via IBM Cloud Secrets Manager, and a centralized Ansible control node. Establishing a more robust approach to Ansible implementation needed some thought, but in the end gave us the solid foundation we needed.

Architecture in Action: PopUp Playbooks

The architecture spans both virtual and physical mainframes. Ansible Playbook source code is stored in GitHub, provides playbooks which can be executed remotely against any z/OS environment, and secured with secrets management. This setup ensures flexibility and security while maintaining control over deployments.

The PopUp Mainframe product includes a broad range of Ansible playbooks to help users and product administrators simply and accelerate routine tasks. Our playbook library covers the following areas, all intended to streamline and simplify the administration of the PopUp virtualized z/OS environment –

• z/OS health checks
• Configuration and user management
• Maintenance routines
• Software installation

These examples illustrate how automation can handle routine tasks reliably and consistently, and are just the start of our journey. We are constantly adding new playbooks to the product, which we will continue to share with our customers.

Automation Outcomes

The team’s reflections on their journey underscored significant improvements: increased standardisation, documentation of expert knowledge in code, and notable gains in operational speed. These outcomes not only streamlined routine procedures but also laid the groundwork for ongoing innovation and efficiency across the mainframe environment.

Improved standardization, codified knowledge, and speed improvements were all tangible outcomes of our automation journey and, with the resulting Playbooks now provided with the product, we’re delighted to provide the same benefits to our customers.

Tips for Implementation

Reflecting on our own journey towards automation using Ansible, for teams looking to adopt the technology, we would offer the following practical advice:

• Leverage the Ansible community. There is a wide variety of support out there if you know where to look, including monthly Ansible community guild calls, an active Discord channel, blogs, LinkedIn groups, forums, and more.
• Get team buy-in early. We ran hands-on playbook sessions where all team members were invited to login and run some playbooks. They quickly realised how easy it was!
• Define standards (for example using Ansible lint) and write clear README files – this is critical to ensure the playbooks can be run without specific technical knowledge which is key to democratising access to z/OS.

Additionally, determining the right way to measure that progress helps build a tangible aspect to the journey that you can record, report and use to justify further steps.

Looking Ahead

Strategically, the path of continuous operational improvements is never complete.  So, for our Ansible implementation, our future plans include:

• Better tracking of playbook validation
• Building additional custom playbooks for specific use cases
• Making playbooks available to customers via AAP (Ansible Automation Platform)
• Exploring event-driven automation

Here’s a previous article about the earlier steps in our Ansible journey. For more information on the PopUp Mainframe product, go here.

Here is a summary of the value PopUp Mainframe provides, as shared by CEO Gary Thornhill at our recent mainframe community presentations.

Continue reading

The PopUp Mainframe team was recently in the mighty Midwest, taking part in both the illustrious SHARE conference, and the TechFieldDay Extra event, in Cleveland, Ohio. In this blog we summarise CEO Gary Thornhill’s presentation.

Introduction

As data from our 2025 mainframe market survey shows, mainframe delivery cycles are often hampered by bottlenecks in operational processes. Using PopUp Mainframe, these bottlenecks can be beaten, enabling mainframe teams to revolutionise mainframe delivery.

Our conference presentationsoutlined our uniquely rapid and flexible approach to supporting faster mainframe delivery. To do this, we introduced some of the latest capabilities of the PopUp Mainframe solution:

• Full support of a modern mainframe CI/CD pipeline, using – in this case – IBM and open-source DevOps tools
• The choice of Linux on Z or the cloud for deployment
• The ability to invoke and shut down virtual mainframes in minutes
• The facility to save, reset, and shareinstances of the PopUp Mainframe environment using the new ‘FastTrack’ capability
• Integration with 3rd party data masking products for data compliance
• The inclusion of Ansible playbooks for streamlined administration

Our Demo Scenario

In our presentation, we used a demo scenario, featuring a simple mainframe application, “NextGen Bank”, with a web-based UI, z/OS Connect to call the backend, atypical mix of COBOL, CICS, and Db2. The backend would ordinarily be a production LPAR on a physical mainframe – in our demo we ran it in a PopUp Mainframe environment, as a test version.

Invoking PopUp Mainframe X and Z Editions

There are two editions of the product – X Edition, for x86 hardware and the cloud, and the Z Edition, running on Linux on Z. Both provide a virtual, on-demand z/OS environment on-demand, only the underlying hardware changes.

You can invoke either in a few minutes.

Once the PopUp Mainframe product (or “PopUp”) is available, you can populate it with our choice of applications and data – our own unique dev/test environment, including compliant/masked data – to perform our task. This was totally configurable each time, of course.

Another key capability of a PopUp is to allow users to take a snapshot of the z/OS environment and, at any time, return to any of the snapshots. This meansyou can reset to a previous state anytime, perfect for testing out new features or upgrades. So, before we made a code change requested by the customer, we took a snapshot of this PopUp to save a ‘before’ state.

Implementing an Application Change under PopUp Mainframe

Thesample Next Gen Bank application was originally showing the customer transaction history in ascending date order, oldest first. For our demo, we have received a new change request, from the business, asking to see the most recent transaction at the top, which means the transaction history needed to be sorted in descending order.

In our example, the development process is a relatively straightforward CI/CD pipeline, featuring a standard IDE to do the development, then specific build and unit test steps, before deploying the code and running system tests. Of course, the stages, and the choice of tools, crucially, is completely flexible: PopUp supports all approaches.

Starting with the code change, in this scenario the developer checked out the code from the GitHub repository using VS Code, modified the query to retrieve the rows in descending order, and committed and pushed the code back to the GitHub repository. The CI/CD pipeline was automatically triggered by the code check-in. This pipeline used GitHub Actions, which, in this example, built the code using the IBM DBB facility, then conducted unit tests using the open-source tool COBOL-CHECK, and pushed the compiled binaries into an artefact repository, Artifactory. These binaries were then deployed onto a different z/OS instance using IBM’s deployment facility, Wazideploy, where integration tests were performed using the Galasa open-source testing framework.

Mainframe application processes are not always simple or successful.So, in our example, the testing reports an error. The application showed that the balances were now blank. As it turned out, the developer had forgotten another relevant change.

In situations like this, it is useful torevert to a previous working state and restart.

The PopUp Mainframe FastTrack capability reset our environment to the snapshot taken before we started the code change. With the environment quickly restored, the developer could isolate and fix the logic error.

With the code fixed (using the IDZ product this time – PopUp Mainframe supports your choice of IDE),the pipeline was this time successful.

Our simple example illustrates an environment that is productive, flexible, and scalable.

Operational Efficiency

A further new capability was the inclusion of pre-installed Ansible playbooks to assist with the administration of the PopUp environment. We showed one such playbook example to support adding and removing users within one PopUp instance without the reliance on, say, a RACF administrator.

Another important facet of a PopUp is that it can be shut down immediately –meaning no environments left running idle, and no wasted resources. As customers have told us, this is perfect for helping meetIT sustainability objectives.

Summary

Our presentations underscored our vision to revolutionize mainframe delivery by dramaticallyaccelerating the mainframe delivery process.

As we demonstrated, from a developer making a code change, committing to GitHub, then sequencing build, unit testing, deployment, and integration testing using a variety of 3rd party and open-source tools, resetting to a previous state, this all happens in the instantly available, flexible PopUp Mainframe environment.

Customers have reported up to a 400% increase in mainframe deliveries made, a reduction in the average time taken to deliver, significant sustainability metric gains by being able to switch off unused resources, and greater flexibility and responsiveness.

Thanks

Our thanks go to the fantastic Tech Field Day team and the panel of experts for their time and insights, and to the wider SHARE organization for their support.

Further Information

Watch the recording of our session via the Tech Field Day SHARE 2025 page