Modernizing Mainframe Tools   


Systems programmers need to share complex information with their team and automate tasks to bring agility to the mainframe in a DevOps world. I was part of a design team tasked with redesigning the browser based mainframe management tool, z/OSMF, to help novice systems programmers overcome the z/OS learning curve.

z/OSMF Before and Command Line Tools

In 2004 IBM created “z Operating System Management Facility” (z/OSMF), a web-based GUI to enable users to manage their z/OS mainframe environment. Navigation required indepth knowledge of z/OS tasks and did not follow modern web conventions. In addition z/OSMF lacked functionality. Users could not create lists of frequently searched for data sets or files within z/OSMF, they had to use other command line interface tools.

The previous version of z/OSMF v2.1 with a side bar navigation and lack of indication that the user is logged into z/OSMF. Images of command line interfaces used to install operating system fixes and organize files.

Redesigned z/OSMF Desktop and Lists Feature

I redesigned the navigation to make it more intuitive and to surface important information and tasks based on the system programmer's experience level. I also designed the ability for users to save collections of frequently used file and data set queries within z/OSMF reducing the need to switch to the command line interface and increasing efficiency.

The revised login page for z/OSMF v2.1 and desktop concept that utilizes visual cues to help the user navigate. An image of the new favoriting experience for saving file and data set queries within z/OSMF.

The Challenge

IBM’s first mainframe computers arrived on the market in 1952, they took up an entire room and were sold without any software. The technology has advanced and now mainframes can support thousands of applications and simultaneous users. Mainframes process 30 billion business transactions per day, including most major credit card transactions and stock trades, money transfers, manufacturing processes, and ERP systems. The early visionaries who brought the mainframe into their organizations are retiring, and automation and novice system programmers are trying to fill their shoes. The challenge is how to teach novice systems programmers the skills and knowledge to take over in a condensed time frame.

Trying to get some new blood, so that when we retire we can get somebody to take over the work.
z/OS Systems Programmer, 32 years of experience
My Contributions

I was part of a team that included another UX designer, a visual designer, a researcher, and lead. I was the primary UX designer on the redesign of the navigation, applying service process, and the file and data set favoriting experience.


Despite the complex problem space, knowing where to start was easy, the user. We interviewed senior and novice systems programmers. At this point in the process, research was our main focus so everyone on the team contributed to research. I wrote interview questions, interviewed users, synthesized results, and provided recommendations.

Our 36 user interviews revealed the primary pain points for knowledge transfer and learning skills in the z/OS domain. This research was the foundation for the redesign of z/OSMF and helped prioritize the work to deliver a better product.

Limited mainframe experience

Novice systems programmers don’t know the baseline for how the mainframe environment should operate, making it difficult to identify errors and issues.

“They don't teach mainframe tools in college or university so we have these people who've never logged onto a mainframe before.”

z/OS Systems Programmer, 30 years of experience
Lack of resources for troubleshooting

Troubleshooting problems within z/OS is an arduous process because there is a lack of resources available to the system programmer. The most common obstacles we learned about were:

  • Some users have closed networks and cannot access resources beyond their firewall
  • The z/OS culture values security and is reluctant to disclose problems and solutions in open forums
  • Errors are presented as codes and those codes need to be looked up in technical manuals
Prioritizing automization over teaching

Some senior systems programmers are focused on automating tasks to increase agility and utilization of the mainframe, rather than knowledge transfer.

“In the future everything would be automated, including the application of fixes, and the entire z/OS environment will be managed through z/OSMF. Every task we do, we want to simplify it. We want it documented and self-checking.”

z/OS Systems Programmer, 25 years of experience
Tasks can't be completed within z/OSMF

Novice systems programmers need to learn multiple tools to complete a single task because z/OSMF lacks functionality.

ISPF 3270 terminal

ISPF menu for interacting with the z/OS operating system

SMP/E tool

SMP/E tool for installing products on the z/OS operating system

TSO/E command line

TSO/E interactive command line for z/OS operating system

I can't find basic or introductory information. You have information on your website [IBM Knowledge Center], but if I'm looking for an introduction, I'm only going to find details and technical terms and less explanation about how it works.
z/OS Systems Programmer, 3 years of experience

Scoping and Prioritizing

There were multiple touchpoints in the z/OSMF experience that could be improved to make it a better tool for systems programmers. I created this site map to help our team strategize.

Complex Problem

The redesign of z/OSMF was complex for multiple reasons. The first challenge was getting up to speed on the z/OS technology. The next issue was scoping the project to deliver value to the customer in the next release, yet design progressively enhanced experiences for our users over the long term. To accomplish this we had to align with the many stakeholders who contributed functionality to z/OSMF and get everyone on board. Lastly, our team was part of an overall transformation at IBM to adopt design practices and an agile development approach and we had to work to institute new practices along the way.

An overview of our sprints including creating a style guide to lay the groundwork for future concepts

Applying Recommended Service Updates

Applying Recommended Service Updates (RSUs) is a crucial task for systems programmers to keep their environments functioning and secure. It is a time consuming task that senior systems programmers would like novice systems programmers to take over, but it can be complex and z/OSMF should provide assistance.

Applying service on a z/OS system is complex because:
  • There is a high volume of updates everyday
  • Updates contain Holddata that needs to delegated for review by systems specialists
  • Updates need to be vetted on the test system then rolled out to the production system
  • Updates may require a system IPL and taking the system down requires careful scheduling

This is an example of the recommended service update data viewed in the tool, SDSF. Each update contains unique data that systems programmers need to review prior to installing system updates.

Understanding the Process

I lead a design thinking workshop with subject matter experts to look at the different uses cases for applying recommended service updates and the tools currently used.

The steps involved in reviewing hold data and installing recommended service updates, and pain points for the user.

Questions and Assumptions

A key element of the workshop was surfacing questions and assumptions so that we can design a tool better than the existing tools.

We looked at the assumptions and questions we had for each persona involved in the recommended service update process.

Why this is a challenge for novice systems programmers

Applying service on a z/OS system is complex because:
  • The user needs to spend a lot of time decoding documentation to avoid costly mistakes.
  • Naming of updates is not consistent (i.e. A vs IO when doing a web search).
  • The IBM Knowledge Center is not updated as frequently as PTFs are released so finding help to do the decoding is difficult.
  • Need to know how to navigate SMP/E and ISPF.

“What we need SMP/E to help with is installing the maintenance, packaging the maintenance and distributing the maintenance. IBM could develop a tool that would serve 90% of the customers if it did this.”

z/OS Systems Programmer
Using z/OSMF to simplify applying RSUs

I worked in collaboration with sponsor users and subject matter experts to develop concepts and see if z/OSMF could be a central location to process the Holddata and assign it to the systems specialists. This element of the project was shelved but I made recommendations based on the user research for future work.

Favoriting Files and Data Set

One of the primary goals of z/OSMF is to simplify the job of the systems programmer by combining the function of multiple tools into one interface. Our team worked to enable file and data set manipulation within z/OSMF. I worked on building a favoriting feature so that users could organize and quickly access important files and data sets.

Current Tools

I interviewed users to learn about their frustrations with their current tools to favorite, bookmark, or organize data sets.

This is an image of lists in the tool PDSMAN

What the user needs
  • To find files and data sets without remembering path names
  • Quick access to frequently used data sets
  • Read the names of the data sets at a glance
  • Organize data sets and files by task

Use Cases

It was essential to map out the all the use cases to ensure the feature worked, but also what to build after the MVP.

This maps accounts for the different uses cases within the favoriting action across both files and data sets.


High-fidelity wireframe for the manage favorites panel.


Many z/OSMF users valued the option to save favorite data sets and organize them into collections.

“I’d use this, especially if I’m doing things in z/OSMF, this will help me out a great deal, only staying within z/OSMF.”

z/OS Systems Programmer


Working on z/OSMF has been a valuable learning experience. Here are some of the key insights and skills I've developed from this project.

Comfort with Ambiguity

Mainframes are complex systems, and designing software tools for this environment can be challenging because you can’t know everything. My work on z/OSMF has taught me to be comfortable with ambiguity.

Challenging Assumptions

One of the more difficult parts of this project was to challenge the team’s assumptions and examine what value we were providing to the user by creating a web-based application, versus improving on the TSO and ISPF systems already in use.

“I’m not a big fan of web-based tools. They are slower and more fragile. One of the things that I like about mainframes is that you have this simple interface.”

Systems Programmer, 8 years of experience

Security Is Paramount

One of the chief assets of a mainframe running z/OS is security and all products created for this environment need to reflect this priority. Many of the design decisions I made were shaped by security concerns and building trust into the user experience.