An article by Uwe Graf, Head of Consulting at EasiRun.
Anyone who has worked with z/OS for many years will be familiar with one of the platform’s defining characteristics: many tasks can be performed with exceptional reliability, but they require considerable experience. PARMLIB structures, different command environments, TSO, ISPF, UNIX System Services, operator commands, and numerous product-specific procedures have evolved over decades, creating an operational environment that is both highly capable and demanding.
With IBM Project Polaris, IBM aims to make this environment progressively more accessible. The project is being developed as the “Next Generation z/OS Experience” and is currently in the technology preview stage. IBM has now identified four technical pillars on which this new experience will be built: Configuration as Code, AI Assistance, an API-first Architecture, and a modernized Command Line Interface.
None of these technologies is particularly surprising on its own. YAML, Git, APIs, SSH, and AI assistants have long been part of everyday IT operations in many areas. What makes Polaris interesting is how consistently IBM can bring these approaches to z/OS administration and what changes this could bring for system programmers.
Why z/OS Configuration Is a Good Starting Point
IBM has deliberately focused its initial Polaris efforts on system configuration. This makes sense because configuration management clearly illustrates the differences between traditional z/OS administration and modern Infrastructure as Code practices.
Many z/OS configurations have traditionally been maintained in PARMLIB members and other platform-specific structures. For experienced system programmers, this is familiar territory. However, those coming from Linux, cloud, or DevOps environments encounter concepts, syntax, and tools that they first need to learn.
IBM estimates that it can currently take a new z/OS system programmer between two and six years to develop a comprehensive command of the platform. With the new z/OS Experience, the company has set the ambitious long-term goal of reducing this period to two to six months. At present, these figures represent a development objective and should not be interpreted as a proven productivity improvement. IBM does, however, point out that its work on Polaris is based on discussions with more than 200 system programmers from customer environments.
Configuration management is particularly well suited to this approach because many tasks are repetitive and changes often follow established rules. At the same time, errors can have significant consequences. This is precisely why traceability, validation, and controlled changes are so important.
Configuration as Code Comes to z/OS
Probably the most visible technical component of Polaris is YAML-based Configuration as Code. IBM aims to represent selected z/OS configurations in a format that can be managed using tools already familiar to developers and administrators working on other platforms.
Probably the most visible technical component of Polaris is YAML-based Configuration as Code. IBM aims to represent selected z/OS configurations in a format that can be managed using tools already familiar to developers and administrators working on other platforms.
This creates a workflow that can be simplified as follows:
For mainframe teams, the connection with established development practices is particularly interesting. In the future, changing a system configuration could be handled much more like changing software. Git provides a change history, differences between versions can be compared directly, and approval steps can be integrated into existing processes.
This also establishes a different foundation for automation. When a configuration is available in a machine-readable, validated format, pipelines can process it, checks can be automated, and defined changes can be executed reproducibly.
IBM is deliberately starting with a limited number of PARMLIB members. According to IBM, the corresponding schemas are being developed together with the teams responsible for the relevant z/OS components. Additional configuration areas are expected to be included as the technology preview progresses.
This is an important distinction, because representing the entire z/OS configuration in YAML would be a significantly larger undertaking than introducing a new representation for a limited set of parameters. The current capabilities should therefore be viewed as the beginning of a broader development.
Git Could Play a Greater Role in System Operations
Git is already widely used for application source code in mainframe environments. Modern development environments and DevOps processes have contributed to the increasing use of Git repositories for COBOL, Java, and HLASM source code.
Polaris extends this concept to system configuration.
This has practical implications. If an SMF configuration is modified, for example, the repository can show which setting was changed, who made the change, and what the previous configuration looked like. A planned change can be reviewed and coordinated with other stakeholders before implementation.
This opens up interesting possibilities, particularly in environments with multiple LPARs and separate development, testing, and production systems. Configuration drift becomes easier to identify because configurations can be compared automatically. Instead of asking, “Why does this system behave differently?”, teams can more quickly focus on the specific configuration differences between systems.
For experienced system programmers, this does not eliminate the need for analysis. However, it could reduce some of the investigative work currently required before the actual technical assessment can begin.
Validation Before Changes Are Applied
Another aspect could prove at least as important as Git in day-to-day operations. Polaris is designed to validate configuration changes against defined schemas while they are being edited.
This changes the point at which certain errors can be detected.
With traditional configuration changes, an error may not become apparent until a member is processed or the relevant component is started or reconfigured. A schema-supported environment can detect at least some syntactic and structural errors earlier in the process.
Expectations should nevertheless remain realistic. A technically valid configuration is not necessarily appropriate from a functional or operational perspective. Dependencies between components, specific installation requirements, and local operational standards remain relevant.
Even so, early validation improves the starting point. Errors that can be reliably detected by automated checks no longer need to be identified manually by a system programmer. This allows specialists to devote more time to evaluating relationships and dependencies where their experience is genuinely needed.
API-First Creates a Common Technical Foundation
Less visible than YAML and Git, but potentially more far-reaching in the long term, is Polaris’s API-first strategy.
IBM is developing a common set of z/OS APIs intended to provide access to information about the current system state. According to IBM, the technical foundation consists of native 64-bit C APIs running under z/OS UNIX System Services. Additional language bindings, CLI functions, and tools can then be built on this foundation.
The architecture can be simplified as follows:
↓
CLI | Portal | Automation | MCP | Additional Tools
This approach is important for future development because not every new user interface will need to implement its own access mechanism for z/OS. As the underlying API coverage expands, different tools will be able to use the same functions.
This also creates opportunities for organizations seeking to integrate their mainframe environments more closely with existing automation and operations platforms. Standardized interfaces simplify integration with cross-platform processes because information no longer needs to be retrieved through a separate technical mechanism for every tool.
This also creates opportunities for organizations seeking to integrate their mainframe environments more closely with existing automation and operations platforms. Standardized interfaces simplify integration with cross-platform processes because information no longer needs to be retrieved through a separate technical mechanism for every tool.
A More Familiar Command-Line Experience
The Command Line Interface also plays an important role in Polaris. IBM’s long-term objective is to make common z/OS tasks increasingly accessible through a UNIX-oriented command line.
The idea is relatively straightforward: an administrator connects via SSH and interacts with the system using familiar shell concepts. The goal is to enable administrators to examine configurations, query system states, and increasingly perform operational functions from this environment.
Today, z/OS system programmers switch between different environments depending on the task. UNIX System Services, TSO, ISPF, operator commands, and product-specific tools are all part of everyday operations. This variety has evolved over time to support different platform functions, but it also increases the learning curve for new employees.
A modernized CLI could help make at least some of these tasks accessible through a common interaction model. For administrators with Linux experience, this would reduce the number of unfamiliar concepts they need to learn before they can independently perform their first tasks.
Experienced z/OS specialists are unlikely to abandon their existing tools immediately, nor would they need to. What matters is the possibility that multiple access methods could eventually rely on the same underlying technical foundation.
AI Gains Access to System Context
The AI component of Polaris is based on IBM watsonx Assistant for Z and is being integrated into the new z/OS experience. More interesting than the chat interface itself is the technical connection between the assistant and the system.
As part of the technology preview, IBM provides an MCP server on z/OS. MCP stands for Model Context Protocol. Through this server, the assistant can access information about the current system state. IBM describes, for example, a scenario in which a user asks about a system’s active SMF configuration. The assistant can retrieve relevant system information and use the specific context of the environment to formulate its response.
This significantly changes the quality of the assistance such a system can provide.
Today, any well-trained language model can answer a general question about SMF. For a system programmer, however, assistance becomes much more valuable when the answer relates to the actual configured system and can be connected to its current state.
IBM also plans to expand the tools available through MCP independently of the underlying z/OS release cycle. The company identifies upgrades, impact analysis, and configuration drift detection among the potential future use cases. IBM explicitly emphasizes guardrails and human oversight for more advanced automation.
This point is likely to be decisive for production use. An assistant that gathers information, explains relationships, and prepares a proposed change is considerably easier to manage from an organizational perspective than an autonomous system that independently modifies a production z/OS environment.
An Example: SMF Configuration
An SMF configuration provides a useful example of how the individual Polaris components could work together.
A new system programmer needs to enable a particular type of monitoring but is not yet fully familiar with the required settings. In a traditional environment, the programmer would first search for the relevant documentation, identify the appropriate PARMLIB members, examine the existing configuration, and then prepare the change.
In the Polaris model, parts of this process can be brought together more effectively. The AI Assistant helps the programmer understand the task and can use the MCP server to incorporate information about the current system state. The relevant configuration is presented in a structured format, a planned change can be validated, and Git can then be used to manage it with full traceability.
The workflow could look approximately like this:
↓
Determine System State
↓
Context-Aware Assistance
↓
Edit Configuration
↓
Schema Validation
↓
Git / Review
↓
Controlled Implementation
Responsibility for the change remains with the designated individuals and established processes. However, the technical workflow can bring together significantly more information and provide greater safeguards for recurring tasks.
What Changes for Experienced System Programmers
Polaris is often discussed in the context of new employees and the mainframe skills gap. This is understandable, but it describes only part of the potential value.
Experienced system programmers also spend a considerable amount of time on tasks that can be at least partially standardized. These include searching extensive documentation, comparing systems, reviewing configurations, and tracing previous changes.
If Polaris simplifies these activities, it could also change the daily work of experienced specialists. Their expertise will still be needed, but it can be applied more effectively to situations requiring technical judgment and decision-making.
This is particularly interesting from a knowledge transfer perspective. Some of the expertise accumulated over years of experience can be incorporated into configuration rules, validation mechanisms, documented changes, and automated checks. New employees would then work in an environment that already embeds part of this accumulated knowledge in its underlying processes and structures.
This is likely to be a more realistic approach than expecting an AI assistant to replace an experienced system programmer.
Polaris Fits into a Broader Development Across IBM Z
Project Polaris is not an isolated initiative. IBM is pursuing several parallel approaches to integrate IBM Z more closely into modern operating models through APIs, automation, and Infrastructure as Code.
In a September 2026 update, IBM explicitly positioned Polaris within a strategy focused on more automated and AI-assisted z/OS operations. The update reaffirmed the four Polaris pillars: Configuration as Code, AI Assistance, API-first Architecture, and CLI Modernization. At the same time, IBM connected the initiative with Infrastructure Management for IBM Z and LinuxONE, as well as additional automation capabilities.
This points toward a development in which mainframe modernization increasingly extends into system operations. In recent years, the focus has often been on modern IDEs, Git-based development, APIs, and CI/CD for applications. Polaris now brings some of these principles to tasks traditionally associated with system programming.
In the long term, this could help organizations align development and operations processes on IBM Z more closely with the practices used across the rest of their enterprise IT environments.
Where Caution Is Still Needed
As of autumn 2026, Project Polaris remains in technology preview. IBM describes the program as initially private and available only to a limited number of participants, with broader access planned for a later stage. Features may change or expand during this phase, or they may be implemented differently in a future product release.
It would therefore be premature to begin aligning existing operational procedures with a future Polaris architecture.
A more sensible approach is to examine the underlying principles and compare them with the organization’s own z/OS environment. Companies can already assess how configurations are documented, which changes are traceable through version control, where manual checks are performed, how dependent operations are on individual specialists, and how well z/OS is integrated into broader automation processes.
Such an assessment will remain valuable even if individual Polaris features are ultimately implemented differently from what is currently shown in the technology preview.
An Interesting Development for z/OS Operations
Project Polaris provides an indication of how IBM intends to evolve z/OS administration. The platform itself will not lose its distinctive characteristics or technical depth. However, new ways of interacting with it could emerge, incorporating many familiar practices from modern software development and infrastructure automation into everyday operations.
Configuration as Code establishes a foundation for version-controlled and reproducible configurations. Git improves the traceability of changes. Schema validation can detect certain errors earlier. A common API layer simplifies the development of additional tools and integrations. A modernized CLI provides a more familiar interface for administrators with UNIX and Linux experience. Finally, MCP gives the AI Assistant a way to connect its responses with information from the actual system environment.
It is the interaction between these components that makes Polaris technically interesting.
For organizations operating large z/OS environments, it is therefore worth following this development closely while also reviewing their existing operational processes. The question of how much knowledge is already embedded in repeatable procedures, and how much remains accessible only through the experience of individual specialists, can be answered independently of Polaris.
With Project Polaris, IBM is attempting to create new technical possibilities in precisely this area. If the announced concepts can be successfully implemented in a production-ready form, day-to-day work with z/OS could change significantly without sacrificing the platform’s proven strengths.