Rocannon on the mainframe

Rocannon started with IBM z/OS. The creator (Adam) works on IBM Z software. Browsing the ibm.ibm_zos_core module catalog through ansible-doc is what made the idea of turning every Ansible module into a typed MCP tool feel worth building. The collection has one of the richest, most consistently documented parameter surfaces in the entire Ansible ecosystem. It was a natural fit.

Why z/OS has been underserved by AI tooling

Configuration management and conversational AI tools tend to assume POSIX systems. z/OS is POSIX-capable through USS, but its native interfaces (SYSFS, JES, the operator console, VSAM, SMS-managed data sets) have no parallel in Linux abstractions. Tools designed for Linux either break or simply don't exist for z/OS.

Ansible changed the automation story. The IBM z/OS collections provide idempotent, typed interfaces for everything from job submission to data set management to HMC operations. Rocannon adds an MCP layer on top of that investment, so any LLM can call those modules against a real z/OS system.

IBM z/OS collections Rocannon supports

ibm.ibm_zos_core

The primary collection for z/OS automation. Install it with ansible-galaxy collection install ibm.ibm_zos_core and Rocannon registers all its modules as typed MCP tools.

Module	What it does
`zos_job_submit`	Submit JCL from a data set or USS path, return the job ID
`zos_job_query`	Query job status by name or ID
`zos_job_output`	Retrieve spool output for a completed job
`zos_data_set`	Create, delete, and manage MVS data sets including PDS and VSAM
`zos_copy`	Copy between data sets, USS paths, and the control node
`zos_fetch`	Retrieve a data set or USS file to the control node
`zos_operator`	Issue an operator command and return the console response
`zos_find`	Search for data sets or USS files by name pattern
`zos_archive`	Archive data sets into a portable format
`zos_unarchive`	Restore an archive to data sets on a target z/OS system

ibm.ibm_zos_zosmf

Automation through the z/OSMF REST interface. Useful for provisioning workflows, software instance management, and cloud-style lifecycle operations on z/OS without direct SSH access to individual LPARs.

ibm.ibm_zos_hmc

Hardware Management Console automation: LPAR management, CPC operations, and system-level configuration changes through the HMC API.

What this looks like in practice

A session with Rocannon and ibm.ibm_zos_core against a real z/OS system:

Submit the job in HLQ.TEST.JCL(IEFBR14), wait for it to complete, and show me the spool output.

Rocannon calls zos_job_submit, polls with zos_job_query, then fetches output with zos_job_output. Each step is a typed module call. The LLM sees actual return codes, step names, and DD output, not a raw shell scrape.

Check if HLQ.PROD.LOAD exists and if it does, copy it to HLQ.PROD.LOAD.BKUP before we make changes.

That's zos_data_set with state: query, then zos_copy. Add check=true to preview the copy before committing it.

Issue a D IPLINFO operator command and tell me when this system was last IPLed.

One call to zos_operator. The response comes back as structured text; the LLM parses the IPL date out of it and answers in plain English.

LinuxONE control node. Rocannon runs on the Ansible control node, which can be LinuxONE (RHEL for s390x) for a fully on-premises setup. Managed nodes are z/OS systems reached via SSH through IBM z/OS OpenSSH.

Why the module model fits z/OS

z/OS operations are structured in a way that maps well to typed tools. A job submission has a known schema. A data set operation has documented parameters. An operator command returns formatted console output. These aren't open-ended shell commands that could do anything; they're declared interfaces with known inputs and outputs.

That matters for safety. Rocannon tags zos_find and zos_job_query as read-only. Data set operations expose check mode. The profile restricts which hosts and module combinations the agent can reach. Compare that to raw SSH access to an operator console, where a single mistyped command can affect the entire system.

The broader picture

z/OS still runs a substantial share of global financial transactions, healthcare records, and government systems. The people maintaining those systems have had solid Ansible support since the IBM collections matured. They have had essentially no AI-native interactive tooling.

Rocannon doesn't replace z/OS expertise. It brings that expertise into conversational sessions. An LLM that can call zos_job_output against a real system, read the return code, and suggest what to check next is more useful than one that generates hypothetical JCL and stops there.