Automating z/OS with Ansible

Automation is key to enabling scalable and repeatable processes that increase the efficiency of software teams. The core driver behind PopUp Mainframe is to help simplify every part of development and testing on Z systems, and one of the ways we do this is by providing tools to help you automate your processes.

Why Ansible for z/OS?

At the heart of PopUp's Z automation strategy is Red Hat Ansible, a widely adopted solution across the industry. Ansible supports z/OS through z-target modules and integrates seamlessly into hybrid infrastructure environments, making it an ideal choice for mainframe automation. Using the pre-installed Ansible and pre-built playbooks, PopUp Mainframe provides a straightforward way to implement automation practices in Z environments.

Using Ansible with PopUp reduces manual effort, promotes standardization, and codifies knowledge. By automating repeatable tasks, teams can dedicate more time to development, testing, training, and innovation, driving greater efficiency and productivity.

Pre-built playbooks are provided out-of-the-box with PopUp

The PopUp image includes Ansible and pre-built playbooks for common tasks. Once you have deployed your PopUp, the automation capabilities are ready to use. Check the Release Notes for Ansible version info.

These playbooks are designed to make z/OS development, testing, and operations more repeatable, scalable, and efficient, and are continously evolving to provide a wide range of automation capabilities. They currently cover:

  • z/OS health checks, including system integrity validation, started tasks verification, APF and PARMLIB checks, and tool version consistency
  • Configuration management, such as updating system identity, and setting environment variables
  • User management, including creating and deleting RACF users
  • System maintenance, such as clearing down the JES spool and managing licenses
  • Alerting and monitoring, including DASD storage monitoring and threshold‑based notifications
  • Software installation and provisioning, including PAX‑based installs and automated configuration
  • And more, as the automation library continues to expand


Ansible Architecture on the PopUp

Ansible is installed on the PopUp image with playbooks available in /opt/shared . The playbooks can be run against the local PopUp (the same VM where Ansible is installed), or against a remote PopUp or z/OS system (an LPAR on your physical mainframe). One playbook can run against multiple targets simultaneously.

wire diagram showing the location of the playbooks on the PopUp (on the Linux layer, not on z/OS), and showing that it is possible to execute the playbooks on local or remote PopUps, or a physical mainframe

There are other architecture options. You may wish to:

  • Use a secrets manager for passwords and keys, for example IBM Cloud Secrets Manager. The pre-built playbooks provide support for IBM Cloud Secrets Manager.
  • Use a source code repository to store your playbook source, for example GitHub. The latest versions of all PopUp playbooks are also available in a GitHub repo. Contact the training or support team to get access.
  • Manage your Ansible playbooks centrally, for example building a separate Ansible Control Node, or using Ansible Automation Platform. Both of the options are supported.


Getting started with Ansible automation

Running a playbook on z/OS is simple.

  1. Log into your PopUp Linux layer (as ibmsys1)
  2. Navigate to /opt/shared/ to find the playbooks
  3. Look through the README in the playbook you are interested in to understand how it works and config required. You may find it easier to get familiar with the playbook and README by accessing it through the PopUp Mainframe toolbox GitHub repo. Contact us to get access.
  4. Edit the inventory file to point to your target environment (this can be the local PopUp, a remote PopUp, or a physical mainframe - or a combination of these). Edit config files as needed.
  5. Execute the playbook (sample commands provided in the README).


Best Practices

To get the most out of the playbooks, we suggest:

  • Go through the README in detail before executing a new playbook
  • Implement a secrets management solution. This means the TSO passwords do not need to be stored in plain text in the inventory file. The playbooks support IBM Cloud Secrets Manager, and alternative secrets management systems can also be used.
  • Playbooks can be run against multiple targets in 1 go - just list them in the inventory file. This is a great way to help reduce config drift by keeping your z/OS environments in sync.


References and Further Reading

There is a wealth of information out there about Ansible, and specifically Ansible for z/OS. These links may be useful:


Page last revised on: 2026-03-02