A lament for the mainframe

Last week I left my job at IBM as team lead for the team porting Swift to z/OS. I didn’t want to leave, but my daily commute was more than five hours and I had to make it four times a week, so I wanted my 20+ hours back.1

As strange as this may sound, I’m going to miss working with z/OS. It’s strange because the interface that z/OS presents to the user is, at best, archaic. To be honest, I thought it was terrible. But there was something there that kept me interested. The fact that it supports three addressing modes (24, 31(!), and 64 bit). The insane backward compatibility. The sheer importance of the things that are deployed on it. The sense of history that surrounds it. It’s awful to work with, but there is a je ne sais quoi to it that I didn’t want to get away from.

The sad thing is that I was working on an open source project within IBM and by not working at IBM anymore, it’s very hard for me to continue contributing to the project. This gets at something that really pisses me off about z/OS: there’s practically no way to actually use it. And for that reason it’s almost surely going to die.2

When I announced I was leaving I tried to find a way to contribute to the project after I left. From a code standpoint, there’s not much in my way since Swift is freely available. However, there’s the issue of actually running the code on the system you’re targetting. Sure, I can use the architecture manual for codegen, but the problem is not codegen, it’s system integration. This is where the Swift for z/OS team spends most of its time.

If I want to (legally) run z/OS for personal use, there are three options I’m aware of: IBM System z Personal Development Tool (zPDT), IBM z Systems Development and Test Environment (zDT), and (zTrail). zPDT is $3750 USD a year plus the cost of the hardware key. zDT is a minimum of $4780 USD, but you’ll probably end up spending $10K. zTrail is free, but is laughable: you have to access it using Windows Remote Desktop and it lasts three days.

Rest assured I will not be spending that kind of money as a hobbyist to get access to a system with, arguably, one of the worst interfaces I’ve used in systems computing. Putting Eclipse on it doesn’t help.

But IBM is a sales organization, not a tech organization. As such, short term concerns drive decisions. So providing free access to z/OS likely isn’t going to happen any time soon. The pride that keeps mainframes going won’t last and I can’t see programmers who are forced to work on it actually wanting to stay there. z/OS is remarkably alien in comparison to most (all?) contemporary computing setups, and it’s not going to win over anyone if no one is ever exposed to it. And saying “Western civilization runs on the mainframe” isn’t good enough.

I’ll do what I can, but this is probably the end of my z/OS experience.

May 16, 2017



Why the long commute? Co-location policy instituted after I joined. It wasn’t something I signed up for.


Yes, the death of the mainframe has been predicted many times before. That’s not what I’m getting at, exactly. Mainframes will live on for a while as actual running systems. IBM may even sell a few. But the selling points of fast transactions and security won’t matter if you’re relegated to working with COBOL and Eclipse. It’s developer poison. And it’s not like the capabilities of a mainframe hardware require mainframe hardware.

Send comments to with the local part being comment

Last modified 2017-05-16