Mainframe Mage

Jonni Bidwell reconnects with mainframe guru John Mertic and somehow ends up talking about Doom and cheesecake…

Jonni Bidwell reconnects with mainframe guru John Mertic and somehow ends up talking about Doom and cheesecake – oh, and the Open Mainframe Project.

John Mertic is director of program management for the Linux Foundation’s Open Mainframe Project (www. openmainframeproject.org), an effort to bring open source knowledge, and of course Linux, to mainframe computing.

Hip youngsters today may not be aware that every bank transaction and every flight booking all end up being processed on mainframe machines. But it is fact. Also, despite processing all this valuable data and often having hundreds of CPUS and thousands of gigabytes of memory, no one (that we know of) has ever hacked a mainframe. Thanks to Zowe, one of the Open Mainframe Project’s key efforts, a green-screen 3270 terminal is no longer the only way to access mainframe data. You can use SSH, cloudy REST APIS or even a Javascript-powered desktop. And you don’t need to know COBOL either, but it probably helps. There’s a lot of momentum towards training the new generation of mainframers, and the Open Mainframe Project is pivotal to that.

We last met John in LXF252 in bonny Scotland. This time around we were at the Open Source Summit in Lyon, back in September 2019. Do check out the project’s page because a lot has happened since then. Besides being the Linux Foundation’s main mainframer, John is also director for its Academy Software Foundation and ODPI (a non-profit dedicated to taming the big data, and in particular Hadoop, ecosystem) projects.

Linux Format: Can you give our readers a quick summary of what the Open Mainframe project is all about?

John Mertic: The Open Mainframe Project is now four years old, and it’s designed to be the focal point of open source in the mainframe computing environment. The mainframe has been around for decades – y’know, 50 or 60 years now – and the computing architecture founded by IBM is pervasive across the Fortune 500. So transportation, insurance, industry… really anywhere where you need computing that’s extremely transactionable, highly scalable, top-end performance and immensely secure. This is the only computing architecture on the planet that does all of those. This project works with pulling together and becoming that central point for all of the open source activity that’s happening in this realm, whether it’s specific to the platform, like Zowe, or for projects looking to support the platform, such as Linux.

LXF: I gather that three new projects have just joined the Open Mainframe Project umbrella. Can you say a bit about those? JM: Sure. One of them is called Feilong which is an interface between Z/VM, which is the native mainframe hypervisor (similar to KVM, for example), out to tools like Openstack and the other cloud stack environments out there. It’s actually a new from the ground up. There were some original open source tools that were sort of pulled together hodge-podge stylee, to make this happen. Now this has grown into its own set of tools built with Python, developed inside IBM and donated to the project. Now we have organisations such as SUSE contributing to it, along with Velocity Software and other key contributors. The idea is just building this out to a general-purpose library for interacting with Z/VM over time.

That’s one of our new additions. Another of ‘em is called Zorow, the Z open repository of workflows. There’s a tool that came from IBM called Z/OS

Workflows that’s designed as a systems configuration language, which is built in XML. The idea of this project is to look at how can Sysops and mainframe engineers collaborate on these workflows through newer technology.

What it found is that many of these workflows are common across organisations. There’s nothing that’s proprietary about them. So what better way to improve the quality and proliferation of these workflows than to have an open source project built around it? IBM has already ceded and contributed

WHY WOULD YOU WANT A MAINFRAME? “Transportation, insurance, industry… really anywhere where you need computing that’s extremely transactionable, highly scalable, topend performance and immensely secure.”

several of its sample workflows to it. Rabobank has also contributed and there’s already some growing interest among other IBM mainframe customers in contributing as well. Basically, we have these workflows that are all available under an Apache 2 licence that any organisation can pick up, use, contribute back to, improve… you know, all the great things about open source.

The other one is called Tersedecompress. TERSE files are common in the mainframe world, and this is a project that’s building the tooling for working with those files outside of the mainframe environment. So if you had a TERSE file from a mainframe many years

ago, you can use this on architectures outside of that, because it’s all written in Java. So you don’t have to go and do your TERSE manipulation on the mainframe itself. Those are the new three projects, and there are a couple more coming that are down the pipe relatively quickly.

LXF: I guess access to mainframes is still a problem for a lot of people, in the same way that access to quantum computers is still a problem for a lot of people. Yet people still manage to figure out new quantum algorithms. So are there initiatives to provide mainframe access to more people who are interested in it? Can I just set up an account somewhere and SSH into a mainframe?

JM: If you’re wanting to test drive Linux on a mainframe there’s the Linuxone Community Cloud available (see https:// developer.ibm.com/components/ibmlinuxone/gettingstarted). Another thing we’re working with and hoping to fully announce (hopefully later in 2019 or early next) is one of our university participants, Virginia Commonwealth, is making available their mainframe. That’s going to be part of the backbone for some of the build infrastructure on Zowe and some of our other projects as well. And we’re working with them to also make some of this hardware available, especially for z/ OS usage (that’s really been a lot of the stickler points because it’s a commercial operating system). So being able to provide some of that access is going to be helpful as well.

LXF: You mentioned Zowe (I do like these fun spellings).

JM: Ha ha! As a group we’re actually working on not having so many of our projects start with Z

LXF: I like them. Zorow’s pretty good JM: And it has a cool logo too.

LXF: I gather it’s tricky to trademark a common name, so it couldn’t have been Zoe, or Zöey (and I’m sure Zooey Deschanel loves mainframes too). Anyhoo, could you tell me a bit more about Zowe (the interface between Z/OS running on mainframes and the open source tooling running everywhere else, not the film star) and how it’s evolved since last we talked?

JM: I’d say this past year has been spent firstly working on the integration part of things. Because you had three different companies – technologies that were all complementary to one another, but they’re also distinct technologies working and pulling together. So we’re starting to see that unison.

The project did a 1.0 release last year, so that’s the first full release of the framework. They’ve taken the next step over [last] summer of building a conformance programme because they saw it’s really important to have a defined commercial ecosystem around Zowe. And I think we have at least a dozen or so offerings from around four different companies that are Zowe-conformant. They’re designed so that they can interact with the base Zowe. You can bind any of them, they can all hook together and they don’t all step over each other. So there’s some really nice pieces there that have been coming together nicely.

The other thing, I think, is that this community is focused on its support lifecycle. So right now they’re working on building a Long Term Support (LTS) release strategy. The interesting thing – and I think this is true of any open source enterprise, but especially of the mainframe – is that you have customers that are not going to want to adopt a technology unless it’s rock solid.

By the same token, there’s also a push to still be innovative. So they’re working on that two-release train strategy. How can we have a rock solid LTS train here that can be supported for many years, but at the same time give room for innovation, expansion and all these things to get out? And for vendors to pick up these things and start working with them so that they can make it into an LTS strategy. Those are a lot of the big initiatives that Zowe members have been working on.

LXF: I’ve seen that you can run a sort of virtual, web-based desktop on a mainframe now. That’s pretty outlandish. JM: Yeah, and the funny thing is you can run that, because it’s all Electron/ Javascript/whatever based, you can pull in other Javascript-based apps and do, what we used to call in the early naughts, “mash ups” if you wanna roll back the clock!

LXF: So so much. Actually, you used another good word before. Sysop (System Operator). That brought me back to my BBS days. Fond memories of running up huge phone bills. Sorry mum. Anyway, speaking of the dim and distant past, lots of the code that runs on mainframes is the same as was running 40 or 50 years ago.

JM: And it might still be running in another 40 or 50 years.

LXF: See, that’s probably quite hard for people to get their head around. In a world where even the most conservative Linux distro has updates for you every couple of days, and let’s not even talk about Windows update. How did these mainframe magi manage to get it right? JM: Well, we could go back to our previous conversation about the good old days when they made shoes better and all that. But I think this architecture, and this whole ecosystem, has immense amounts of legacy around how to build things with high security, high performance and high scalability out of the box.

And it’s one of the things I really admire about this platform: they hold very true to those principles with what they’re doing. Everything they build is done with that in mind. It’s been since 1964 when the first

System 360 mainframes were rolling off the line. They reign back to an era when people had a different set of resources they had to work with. So they had to be very constrained, and extremely smart and knowledgeable.

But I think you also had to see something of the end goal. I’ve been reading things about games that were built in the 70s and 80s, and it was the same sort of thing. Y’know, if you look at source code you’d see there’s some really wild things people did, but they were frickin’ genius and it amazing how they worked out. Things that you had to do because you only had so much memory to work with.

LXF: Yep it’s amazing how John Romero and everyone got Doom running on the 386. All kinds of two-and-a-half dimensional voodoo goin’ on there. Ooh and on the subject of cyberdemons… So now you can run not just COBOL (which by the way people shouldn’t slate on), but also Electron, Node.js and probably any other high-level language on mainframes. So what happens when people start running projects with labyrinthine dependencies and hard-tospot security flaws? How do you code check all of that? How do you make sure someone doesn’t ignominiously run the first-ever virus on a mainframe?

JM: That is a great question and I think it’s something that this community is still wrapping its head around. Because you’re exactly right. Maybe not even a virus, but they’re definitely quite concerned about the stability of running these sorts of things. It’s one of those things that I think is still a work-in-progress.

I will say that one of the things this community has spent a lot of time with is just understanding their dependency matrix, or tree, of what they’re shipping. Even across the whole of all the Linux Foundation projects we think about how to build out mature projects. The Core Infrastructure Initiative (CII) badge was created with a lot of that in mind. What is the whole landscape of what pulls together your software? What is your dependency matrix? What is your code lineage, or providence? All of those pieces. For a lot of the projects that we’re starting, this is the first time they’ve run things like static code analysis, for example. And the developers say, “Oh hey, I didn’t know I was pulling in this code to make this thing work. Maybe I need to think more about my dependency management.”

So I think this project is very aware of it. It’s always going to be something of a work in progress. But it’s a big thing and I think if you look a little bit at what the CII badge program is, it’s very much tailored into how do you build the right practices in, so that you can manage when these security issues and dependency issues come up. You’re not going to prevent them, because you can’t. Every piece of software that’s released right now has security issues in it. We just haven’t found them yet. The more important thing is how do you react, find and address them? How can we be aware and updating and doing the right things so we can mitigate as much as possible?

I think that sort of mindset that we put into a lot of projects as we drive them to graduation. And that’s the mindset that this project here has as well.

LXF: We mentioned blockchain applications last year, and possible applications in supply chains and things? Have you had any more exciting mainframe blockchain projects joining the party since then?

JM: Not a ton, although we did have one of our mentees that was working on a compliance engine. I’m not precisely sure of the details, but I know that they’re going to be presenting about that here today, so maybe you can go check that out.

LXF: What does the future hold for the Open Mainframe Project?

JM: We’re certainly seeing a lot of project growth. I think the mainframe world is realising that collaboration through open source is an amazing way to drive more innovation. So as I said, we have two new projects that have just been accepted into incubation, and there will be a couple that are likely to be considered soon after that. So we’re seeing huge growth. The way we’re looking at it is that we have to be

ON TAKING THE OPEN SOURCE APPROACH “That’s when you get to the value proposition of having shared research and development, when you have different people working on it and not just six of your engineers.”

careful that we don’t become the dumping ground of open source, that we’re actually progressively making things better.

There’s a huge effort on what graduation looks like, and how do we develop these into sustainable projects. One angle of that is diversity, and that’s really two angles. One is organisational diversity: we want all of our projects to have a multitude of different organisations participating in them. Because that’s where amazing open source happens. That’s when you get to the value proposition of having shared research and development, when you actually have different people working on it and not just six of your engineers. We’re

making sure that’s a driving principle of all of our projects, even at the board level. They want to see a multitude of different organisations, not just the same three or four across every project. They’d love to see 50 different organisations participating across all of our projects. If things are going really well that’s where we’re at, when we’re getting a huge swathe of the industry participating.

And the other angle is gender diversity. Because as we know the tech industry is not really good there. And the mainframe world is even worse. And here we also have the particular problem of an aging population. I think we talked about this last time. But this industry cares about its legacy – it wants to make sure that mainframes are around for the next 50 years. And the only way to do that is by having a diverse group of people that can carry it forward.

This group really does care about that. I’ve been a part of communities that don’t really care about what happens after they’re gone, but that’s not the case here. This was a little bit of the driving formation of why this project came together, because of how much it means to carry this forward. Those are the two big driving forces that we’re thinking about over the next year.

We have a mentorship programme that we’ve been running, and we’ve been expanding it. We now have at least two universities that use the guts of our mentorship programme as part of their class projects. We have one in Canada, and we have Virginia Commonwealth as well. And we’re looking to expand that. IBM has programs too, like Master the Mainframe. So there’s bits and pieces out there, and we’re seeing a little bit of convergence around what we’re doing, which we’re happy with.

But by the same token, we’re looking at the broader picture and we want more people touching this technology. We aren’t necessarily concerned with developing solo mainframers, but we want people who are well-rounded technologists. People who know that this is part of their arsenal. That they can see this box and not be like, “What the heck is this? I’ve seen something like this in an old sepia picture.” We want them to see it as something that they can work with and understand where it fits in. Because computing is heterogeneous.

LXF: So there is a lot of talk about small things at this conference, IOT and microservices, and then lots of slightly ineffable-sounding concepts like Cloud Native Computing. It seems at first like mainframes are the opposite of that, but everything has to tie together somehow, right?

JM: I had somebody today ask how edge computing fits into mainframes. And it’s wonderful that we live in a day and age where our computing menu is broad. In the US there’s a restaurant called The Cheesecake Factory. What it’s best known for is that its menu is a 50-page book. And it’s all pretty good too. I don’t know how they have cooks that know how to make all that stuff.

So basically now we have The Cheesecake Factory menu of computing choices, and you’re not stuck if you go with one. You can get those mashed potatoes with your pizza (monster!–ed), and you can have a piece of cheesecake at the end. You can do that if you’re crazy or hungry enough. We’re like that with our computing today. Edge is just another angle of the whole lifecycle of application data coming together. Mainframe can be that piece of cake that needs the high transactional part of your application. Whoever invented microservices, the mainframe world should be kissing their feet. Because it lets you say, “Look at the pieces of my application that absolutely need high transactional speed. I can push those onto a mainframe and do it so much more costeffectively.” And those pieces that don’t need a mainframe – well, maybe they can go onto a cloud infrastructure, or an edge piece. It’s a unique era we live in, and this push to heterogeneous computing, means that an architecture like mainframe can have so much more of a stronger role.

LXF: I think that I would like some cheesecake now…