THE LINUX FOUNDATION PROJECTS
Blog | I Am A Mainframer | Mainframe Connect | Podcast | Uncategorized

I am a Mainframer: Niall on Mainframe Security, Learning by Doing, and the Future of z/OS

By | October 20, 2026

Join host Steven Dickens in this episode of I Am a Mainframer featuring Niall from Vitality, a mainframe security consultant building his career across RACF administration, security engineering, ESM migrations, system programming, and mainframe consulting.

Niall shares how he entered the mainframe industry through BMC Software’s Mainframe in Training program before joining Vitality, where he works with major retailers, insurance companies, and banks. He discusses his journey from a newcomer who was curious about the mainframe to a consultant focused on continually expanding his technical skills.

The conversation explores the importance of hands-on learning in mission-critical environments, the balance between experimentation and production responsibility, and why mainframe professionals should keep developing beyond a single specialty. Niall also discusses RACF, ACF2, Top Secret, ESM migrations, security assessments, documentation, runbooks, and the value of building well-rounded expertise.

Niall offers a thoughtful perspective on AI in mainframe work, explaining why he is cautious about relying on it for learning while acknowledging its usefulness for programming support and everyday tasks. He also highlights the need for more visual mainframe education—showing people how RACF and security tools work rather than only describing them in text.

He shares advice for early-career professionals to stay curious, volunteer, learn by doing, and understand that mistakes can become valuable learning experiences. Looking ahead, Niall reflects on the future of mainframe computing, the growing power of modern systems, the possible convergence of mainframes and supercomputers, quantum computing, and how hardware limitations can inspire innovation.

Watch full episode here:

OR

Transcript-
Steven:

Hello and welcome. You’re joining us here on another episode of the I Am a Mainframer Podcast. I’m your host, as always, Steven Dickens, and we’ve got Niall from Vitality. Hey Niall, welcome to the show.

Niall:

Thank you very much for having me.

Steven:

We’ve got two Brits, so buckle up. This is two Brits talking. I’ve seen people pronounce it ‘Z-O-S’ rather than ‘z/OS.’ For the next however many minutes, everybody gets a name around it. We invented the language, we learned it, and you’re calling it what? So now tell me—let’s get the listeners and viewers oriented. What do you do at Vitality, and who are Vitality?

I know the ever-wonderful Mark Wilson, and I’ve known him for years. It would be good to get everybody oriented so we can use that as a jumping-off point. He’s also a previous guest on the show.

Niall:

I actually started my career in this industry just under five years ago—it will be five years in November. I had my job interview at the BMC Software office in Bromsgrove, where I met Mark, and I worked at BMC for 18 months.

During that time, I was looking for guidance and asking myself, ‘Where should I end up? What’s the ideal journey?’ As you touched upon, there aren’t many people in this industry who probably don’t know Mark. It’s hard not to have some of his influence rub off on you.

I ended up wanting to go down the security path. That became my chosen discipline. I started as an associate consultant on a trainee scheme called Mainframe in Training. Eventually, Mark started his own company, Vitality, and I was the fifteenth person to join.

I left BMC Software and joined Vitality. I eventually became a full consultant, and I’m still on the path toward becoming a senior consultant, and hopefully one day an architect. Maybe one day  I’ll become the equivalent of Mark Wilson—minus the distinctive background.

Steven:

That’s a regional joke we’ll leave alone.That’s okay. Mark’s accent gets stronger, and mine gets closer to Mark’s. Let’s leave it at that. We’re from the same part of the world originally—the Black Country.

Niall:

Exactly.

Steven:

Mark and I have shared history and background.Fantastic. That’s a great way to jump into this conversation. Tell us a little about how you got onto the mainframe. You’re at a mid-career professional level now, I would say. How did you find the platform and get involved? A lot of people who listen to the show, and many of the guests I’ve had, are just starting that journey. You’re probably five or six years ahead of them, so tell us about that journey.

Niall:

It’s been quite eye-opening. I was like many other people who hadn’t started their career on the platform. I thought, ‘Mainframe? I don’t think I’ve heard of it that much. Is it really used that widely?’

Although I would argue I was slightly more open-minded than most people, I wasn’t thinking, ‘It’s legacy. It’s dead.’ I was very much of the mindset that maybe there was something to learn and something to discover.

Steven:

That’s worth focusing on, because it comes across in many of the guests. I’ve been doing the show for seven or eight years now, and I’ve lost track of how many people I’ve interviewed. Students and younger professionals often come on saying, ‘I’ll check this out and see what it is.’ They have that curiosity.

I’m interjecting in your answer, but it’s interesting that there are people who want to find out for themselves rather than simply be guided by what others tell them.

Niall:

I think it’s indicative of people’s curiosity. We live in an era where more and more content is fed to us and tailored to specific algorithms. This is an industry populated by people who like to think outside the box. They like to find things out for themselves.

I’m always thinking, ‘Can I do this in JCL? Can I do this in REXX? Can I use Carla? Can I use whatever tools are available?’ I don’t necessarily want to be told the answer. I want to try and find out for myself.

Steven:

That’s what makes it a career platform in that way.

Niall:

Absolutely. Although you can’t tinker too much, because if you break a mainframe, at least it needs to be available. There’s a real issue there.

Steven:

You’re right. There’s a balance between being a tinkerer and a person who finds things out independently, and doing that in one of the most highly regulated, mission-critical environments.

Someone like Mark has built a career by being that kind of tinkerer at organizations such as Citibank, Wells Fargo, JPMorgan Chase, or Barclays. It’s a dual mode, if you will.

Niall:

It’s a fine balance. There are many times when I want to investigate something else, but I’m working on a client’s system and have to pause. I have to use our internal Vitality sandbox instead.

I experiment there and try to break things, and then I tidy everything up. That lets me put into practice what I want to learn without doing it on a client’s system. I can’t say, ‘Sorry about the downtime—I was testing something on your production system.’

Steven:

I know what Vitality does from Mark, who has been doing this for 19 or 20 years. Tell us a little bit about Vitality.

Niall:

There are really two sides. The first is the consultancy side, and then we have our software and related work.

Within software, we have products that support activities such as ESM migrations and storage migrations. That’s a team I spend less time with because I’m a consultant.

With consultancy, we run services and support contracts for major retailers, insurance companies, and banks. In my case, I work on security engineering and RACF administration, and I’m leaning more into system programming so I can build the foundational knowledge I would ideally have developed earlier.

Vitality has consultants in all sorts of specializations. We have DBAs, CICS professionals, MQ specialists, IMS professionals, and more. We’re already past 80 people if you include contractors, which is pretty good for a company that has been operating for only four or five years.

Steven:

What do some of those projects look like? You mentioned security. Is that penetration testing, migrations to new versions of RACF, or all of the above? What does a typical day look like for you and your clients?

Niall:

I recently moved away from one client, an insurance company, where we ran a security engineering service. It was mainly RACF administration rather than deeply technical work, but I still oversee support for colleagues running that service with some of our newer staff.

I’ve moved on to a higher-level security engineering service with a major UK retailer. I’m also supporting ESM migrations. For example, I previously delivered ACF2-to-RACF training to help people understand the differences between the two systems.

Now I’m working on a table that acts almost like a cheat sheet, showing the equivalent commands between ACF2, RACF, and Top Secret. We never know when someone may move from RACF to ACF2, from ACF2 to Top Secret, or the other way around. We need to make sure people have the skills to understand those systems.

I work on documentation, runbooks, guidebooks, and security assessments. I’m also updating spreadsheets used for assessments. We can add streamlining, color coding, and checkboxes—for example, whether a check requires ZSecure. If a client doesn’t have ZSecure, we can filter out those checks and immediately know that they need to complete 80 checks instead of 86.

So there’s a little bit of everything. I try to keep my finger in all the pies because it’s important to become as well-rounded as possible. You could spend your entire career working only on RACF administration, but you might miss a lot and eventually reach a plateau.

I don’t want there to be a ceiling. I want to keep learning until I retire. So I’m trying to become more involved in UNIX, non-RACF ESM work, penetration testing, and audits. Unfortunately, we’re very busy right now. We’re a small company, but we’re getting a lot of work. Sometimes I need fewer contracts so I can spend more time learning instead of just delivering.

Steven:

That’s always the balance, I suppose.
Of course it is. We’re 10 minutes into a podcast about technology in 2026, and I haven’t asked about AI. What kind of host am I? What’s going on? Is there a disturbance in the Force? You’re speaking to clients and working on projects—what are you hearing about AI?

Niall:

It’s interesting. I might be one of the few people who has appeared on this podcast who is much more wary, or at least slower, to adopt AI than others.

Personally, I love doing things myself. I’m trying to get back into metalwork and woodwork while working on my house, and I love being the person who created the end result. I appreciate the journey almost more than the destination sometimes, so I don’t use AI that much.

I’m also wary because of historical issues such as hallucinations, where the data was collected from, and whether the source is legitimate. There have been many controversies around AI tools.

That said, the company I work for has a major trend toward using Claude in particular. Many people praise how helpful it is when they have issues with programming languages such as REXX, JCL, COBOL, CA, Python, or C. It has also been useful when working on near-semantic migration tools or storage migration tools.

Our company is adopting it, and there is real interest. Personally, I don’t use it as much. I mainly use it for simple tasks that are less about gaining knowledge. I won’t necessarily ask where to find information or request an answer, because I like knowing which documents to consult and how to find the answer myself.

I’m more likely to use it for things such as scheduling, sorting emails by priority, or deciding which meetings are most important.

Steven:

One question I’m exploring is whether AI can serve as a 24/7 mentor for the next generation. You’ve probably thought about that a little. Can you only learn from a human mentor?

Niall:

That’s a good question. In my experience—and I know Mark would probably say the same thing, with more than 30 years in the industry—you sometimes have to make a mistake to learn.

Sometimes you have to experience a moment like a callout at 2 a.m. I had an issue a while ago when I was IPLing a system and realized I had the wrong parameters. I had taken them from a maintenance or development system rather than production. We were in the middle of the IPL, the system had been shut down, and I suddenly had to ask: where are the load parameters?

Moments like that teach you that you need to know your processes inside a  nd out. I’m never going to make that mistake again because I experienced the panic, and I don’t want to go through it again.

That’s the difficulty with learning by doing. Another problem with AI is that people often receive text-based answers. I think there’s a real need in this industry for more visual content.

IBM’s documentation is exhaustive and excellent, but it is very text-heavy. We need more content that doesn’t just tell people how RACF works, but shows them.

Steven:

Exactly. You want to see it rather than just be told.

Niall:

Yes. Many people prefer films to books because they provide a visual stimulus. It’s easier to understand what something looks like when you can see it.

It’s easy to describe RACF. You could describe a dog by saying it has four legs, a tail, a nose, two ears, and sometimes floppy ears—but someone might imagine a cat. That’s the same problem with RACF. What does it look like? How does it work?

Instead of simply telling someone how to run a LISTUSER command, show them. Don’t just describe the output—show it. Show what happens when you run the command as-is, and compare it with viewing a user ID in zSecure.

That’s where people often struggle. They need to know, ‘How do I do this?’ or ‘What does this look like?’ An answer may tell them, but they still need to see it.

That’s why my slide decks for GSE UK this year are going to focus much more on green-screen demonstrations. We need to show people how the technology works, rather than only explaining it. A picture tells a thousand words—or something like that.

Steven:

I could talk to you about this for hours, but the producer will make sure we keep it short and sweet. As we start to wrap up, there are a couple of questions I always ask. If you’ve listened to the show, which I know you have, you’ll know what’s coming.

You get to go back five or six years to your younger self, just coming out of college. What advice would you give? We have a lot of younger listeners who may not even be at college yet but are thinking about what comes next.

Niall:

That’s a difficult one.

Steven:

You might say, ‘Buy Bitcoin’—that’s another one.

Niall:

Start investing in the housing market.
I think it’s difficult because I mentor several students, and I’m still mentoring some now. The answer changes depending on the student’s needs.

But the important thing is to be curious and to put your hand up and try. You don’t always have to succeed. As I said earlier, sometimes the journey is worth more than the destination.

If I bake a cake and it burns, I’ve still learned something. I may feel bad that the ingredients were wasted and that I could have bought a cake from the shop, but now I know I need to lower the temperature or reduce the cooking time. I understand what goes into making a cake.

In the UK, we have something called the Air Cadets, which is almost like an RAF community club for young people under 18. I was part of it when I was younger, and so was Mike Davidson, an IBM Champion. There are many of us.

I teach the cadets, and earlier this week I taught them cooking. One of them burned what they were making, and I asked, ‘What have you learned from this?’ That is the important part.

Sometimes it’s disappointing not to have something you can eat or a physical trophy at the end, but you learn by doing. If you take shortcuts, simply Google the answer, avoid reading, or never try and fail, you don’t always learn.

So my advice is: stay curious, try things, put your hand up, volunteer, and see what happens.

Steven:

That gives me an insight into how you’ll answer this final question, which is fascinating. I’ve asked this question for several years across hundreds of episodes, and it always gets fascinating answers. Crystal ball: you get to look at the mainframe five or ten years out. Where do you think we’ll be? Where do you see us?

Niall:

I think there’s a website called Moore’s Law Is Dead, and I sometimes wonder how accurate Moore’s Law is today. I think about having the same computational power in half the size, or double the computational power in the same size. It makes me wonder what we could be looking at with future mainframes.

I don’t think we necessarily need smaller mainframes. They’re reasonably sized now, especially compared with decades ago, when they were about the size of a fridge. With all that computational power, the question is: what do we do with it?

One interesting question that students ask is the difference between a mainframe and a supercomputer. It’s a really good question because the mainframe is now so powerful. Could you arguably say that it falls under the supercomputer umbrella?

I wonder if we’ll see more blurring between what is considered a supercomputer and what is considered a mainframe. I also want to see what happens with quantum computing and whether quantum capabilities become part of mainframes over the next five or ten years.

I was talking to one of my colleagues about this a couple of hours ago, and this is a slight tangent, but it connects. One of my favorite things about old video games was that they had hardware limitations.

Take games such as Resident Evil or Silent Hill. They ran on PlayStation 1 hardware that couldn’t load very much. In Silent Hill, the developers used fog to hide things appearing in the background because the memory was struggling to load them as you approached. That fog worked perfectly for the horror setting. It makes me wonder how development will change if we remove all those hardware restrictions. Sometimes the fact that you can’t do something makes you think outside the box 

Steven:

Drives innovation.

Niall:

Exactly. That’s the thing I wonder about. Innovation might actually stagnate as capabilities increase and restrictions disappear. A notable example is RollerCoaster Tycoon, which was created almost entirely in assembler. The developer thought it would run faster if it were coded as close to binary as possible, because less processing was needed to translate it into machine code. I just think examples like that are fascinating. So I do wonder what will happen, but I feel more confident knowing the group of people this industry attracts are so innovative. I think that quells my fears.

Narration:

Thank you for tuning in to the Mainframe Connect Podcast and this episode in the I Am a Mainframer series, sponsored by Phoenix Software International. Like what you heard? Subscribe to get every episode or watch us online at openmainframeproject.org. Until next time, this is the Mainframe Connect Podcast.

Share