In celebration of the 200th edition of the Bullhorn, we are sharing what Ansible means to the mainframe community, our journey with Ansible on the mainframe, and the appreciation we have for the community.
To start, mainframes can run multiple operating systems; our journey focuses on the UNIX POSIX compliant operating environment integrated into the z/OS operating system. Our clients worldwide account for over 30 billion transactions a day and in some cases are capable of individually running over 100,000 transactions per second. Such resiliency depends on Ansible automation that simplifies tasks that can continuously monitor events without agents and retain idempotency.
The mainframes architecture allows for applications written over 50 years ago to run on our latest z17 hardware released this year. Because of this, our Ansible journey required us to remain compliant with UTF-8 while also running in the system’s native encoding, EBCDIC. To ensure compliance, our compilers team ported Python to z/OS and with a few more adjustments in z/OS UNIX, Ansible modules could manage z/OS hosts so long as users understood how to navigate the encoding limitations. At this point, IBM had developed several collections with over 70 modules specializing in z/OS specifics such as job submissions, data set creation that is the equivalent of a UNIX file, but we could not seamlessly run community modules such as ansible.builtin.
It was now time that an IBM team focused on all Ansible community projects be involved with the community. The first action was to update the Running on z/OS section in the FAQ page of the Ansible Community docs. We then created a new page on managing z/OS UNIX targets with Ansible that provided solutions on how to navigate particular EBCDIC-related challenges.
Documentation was only a temporary solution, so we began executing our plan to change the ansible.builtin experience on z/OS UNIX by introducing a new encoding option for the lineinfile and blockinfile modules that will be available in ansible-core 2.20. This enhancement enables target files not encoded in UTF-8 to be directly modified using these modules on any managed nodes where z/OS UNIX users no longer have to manually convert EBCDIC files to UTF-8.
It does not stop there; we have made changes to add environment configuration support to Ansible CLI tools, including ad-hoc commands. Not only will this ensure parity with Ansible playbooks, but it will also simplify our clients’ experience and allow them to run modules from the command line where prior, our modules had to be run from a playbook.
If you manage z/OS targets with Ansible, we’d like to hear about your Ansible experiences.
Help shape the community roadmap by engaging us: