Some conference sessions you have forgotten by the time you reach the car park. This one we are still talking about. At this year’s Mighty Mainframe Conference in Zadar, Fiona King, z/OS Product Manager at IBM, and Tim Reiser, Senior Design Lead, walked us through Project Polaris.
The short version: it is IBM’s attempt to rebuild the everyday z/OS experience around the people who are new to the platform, without throwing away what makes z/OS worth running in the first place.
If you have onboarded a junior colleague onto a mainframe lately, you already know the problem they are facing.
What Polaris is
Project Polaris sits inside a wider effort that IBM calls z/OS Simplification.
Three ideas hold that effort together: make the platform easier for people who are new to it, align with the tools and conventions the rest of the industry already uses, and remove historical differences that add friction without adding value. It swaps traditional PARMLIB editing for configuration written as YAML, kept in Git and edited in VS Code, with Watsonx Assistant for Z beside you to guide and check the work. IBM set it out in February as a Statement of Direction (AD26-0150), a stream of early technical previews rather than one big release.
The stated goal is to cut the time a new system programmer needs to become proficient from two to seven years down to two to six months. The first preview is invite-only and arrives this summer.
The problem
Before any design work started, IBM spoke to more than 230 system programmers, from first-year hires to thirty-year veterans. A few of the quotes Fiona put on screen landed with the whole room. One new-to-Z engineer said they disliked the phrase “skills gap”, because they have plenty of skills, just not the old ones the mainframe asks for. A manager admitted the real problem with new hires is keeping them. And one expert said, plainly, that they are retiring soon and have no interest in learning something new.
Then came a number that explains the urgency.
Today it takes somewhere between two and seven years for a new system programmer to become proficient on z/OS. On a team where the senior people are counting down to retirement, that is a frightening runway.
IBM also mapped what the job really involves and landed on nine areas of responsibility, covering everything from installing and updating z/OS, through storage, security, networking and performance to problem determination. Most people carry three or four of these at once. The role is broad before it is deep.
Built for Chris
The design has three people behind it. Chris is new to Z. Alice is a mid. Zach is the senior who has seen everything twice. IBM was clear that the experience is built for Chris and pressure-tested against Alice and Zach, so that whatever helps a beginner does not quietly break things for the people keeping production alive today.
That is the philosophy in one line.
Lower the floor without lowering the ceiling.
The North Star
The headline goal even has a name, the NorthStar goal, which is a fitting choice for a project called Polaris. Cut time-to-proficiency from two to seven years down to two to six months.
Worth being clear about this. It is a target, not a result someone has already booked. But it tells you how far the rethink goes. They are not trying to make the current experience ten percent nicer. They are trying to turn years into months.
How they plan to get there
This is the part that will interest anyone who writes configuration for a living.
The most visible change is configuration as code, written in YAML. Rather than editing PARMLIB in its traditional form, you describe z/OS configuration in YAML, hold it in a config registry, edit it in something like VS Code, and store and version the files in Git.
The command line gets the same treatment. You log in over standard SSH and run commands much as you would on Linux. The CLI does not disappear. It stops being a separate dialect you have to learn from zero.
Sitting alongside all of this is watsonx Assistant for Z.
The agentic AI offers guidance, validation and best-practice checks while you work, instead of sending you off to a manual in another window. The framing was less “go ask a chatbot” and more “a knowledgeable colleague reading over your shoulder”. IBM is building a second agentic tool called Bob, with its own command-line shell. Like Polaris, it serves both system programmers and developers, with modes that reason about the system and modes that work on application code.
The two come at the platform from different angles and point the same way. There is also an AI-infused graphical interface built for productivity, and a conceptual model that leans on cloud thinking, so that where a perfectly good industry-standard term already exists, it gets used in place of the historical mainframe word for the same idea. A small thing on paper, a big thing for how quickly someone finds their feet.
What the demo looked like
The demo made it real, and it is the part worth retelling. Chris, the new hire, gets an email from Zach, who is out of office, asking him to start monitoring logstream activity on a production partition. A year-one task, handed to a year-one person, with no one around to help.
Instead of digging through documentation, Chris works inside the new interface. watsonx Assistant for Z notices that the SMF type 88 records, the ones tied to logstream activity, are not being collected on that partition. It explains which record type controls this, shows the exact change in YAML, and walks Chris through committing it to Git. Every step is visible, so he can see what is changing and why. And the change takes effect without an IPL.
If you get to see it yourself, four things are worth watching for: the AI giving contextual recommendations and catching mistakes early, YAML standing in for Parmlib syntax, each step being legible rather than magic, and the whole thing being version-controlled so you can audit or roll back.
Bigger than z/OS
One slide pulled back to show the full stack, and the ambition got clearer. The direction is configuration automation across every layer: infrastructure as code at the hardware and firmware level, in the spirit of Terraform; configuration as code for middleware and applications above, in the spirit of Ansible; and this new next-generation approach for z/OS itself in the middle. Polaris is the z/OS-shaped piece of a much larger picture about running the platform the way modern infrastructure teams already run everything else.
What do I think about Polaris?
What do I make of it? I like it a great deal, and I am holding on to a little healthy skepticism. Both belong in the same sentence.
What I like is simple. For years, the real reason the mainframe was hard to enter had less to do with the platform and more to do with everything stacked around it. Polaris aims straight at that. Faster insight into how a system fits together, configuration I can read and review like any other code, and an assistant that shortens the gap between a question and an answer. If even half of it works the way it did on the Zadar stage, the first year on z/OS becomes a different experience.
My one reservation is gentle, and it is not aimed at Polaris itself. It is about what sits beneath it. The new experience is a layer over z/OS as it runs today, so the system underneath still behaves the way it always has. What I will be watching for in the preview is how well that layer holds on a bad afternoon[AG6.1][KM6.2], when a change misbehaves and you have to step down a level. If a newcomer who learned only the modern way can still find their feet down there, this is a real step forward. I am optimistic that it can, and curious to see it proven.
Take the demo’s own example, a week on. Chris enabled SMF type 88 recording for that logstream in YAML. Polaris validated it, showed it green, activated it with no IPL. Done, on the surface.
Then the monitoring data dries up and the console starts throwing System Logger offload errors, because the Coupling Facility structure behind that logstream is undersized and its offload datasets are filling on DASD. Nothing in the configuration was wrong. The problem lives a level below the configuration.
This is where the two worlds split. Zach reads the IXG-series messages, knows type 88 tracks System Logger, and goes straight to the source: D LOGGER and D XCF,STR to check the structure, the LOGR policy for the offload dataset definitions, SMFPRMxx for how recording is set.
He resizes the structure or fixes the allocation and moves on, because he carries a mental model that runs all the way down to the Coupling Facility and DASD.
Chris was handed a clean YAML edit and a green check. If the new interface and the assistant follow the failure down into System Logger, the structure, and the offload datasets, then Chris fixes it too and the layer has done its job. If they stop at “your configuration is valid,” Chris is stranded at exactly the layer he never had to learn, and the afternoon ends with a call to Zach.
What gives me confidence is how IBM is approaching this. In Zadar, they were pretty clear: the parts that make Z unique aren’t going anywhere. What they’re trimming are the differences that never really justified themselves.
And this is just an early preview, shaped by feedback from the people actually using it. Shipping something small, listening, and iterating—that feels like the right move. So this isn’t really a complaint – it’s more like a bit of caution.
The kind of pressure that helps turn a solid idea into something truly finished.
Where it stands
Polaris is early. The first technical preview is coming this summer, invite only, with prerequisites, and IBM is openly asking for feedback to shape where it goes next. If your team wants to be considered for the technical preview and share feedback while Polaris is still being shaped, Fiona King is the person to talk to.
And if you would rather just follow along for now, the IBM Z Deep Dive Series runs sessions on the Next Generation z/OS Experience, which is an easy way to see where it is heading.
Our take, having sat in that room: this is the most serious answer we have seen to the question hanging over every mainframe shop, which is who runs this in fifteen years. It will not be the same people, and it will not be the same way. That is not a loss. It is the platform earning its next generation.
