Rosalind Radcliffe

Hello, and welcome to this session. My name is Rosalind Radcliffe, and for those who don't know me in the room, or maybe somebody who hasn't heard me speak, I am an IBM Distinguished Engineer, and I'm responsible for DevOps for enterprise systems. But if you know me, you'll know me as the mainframe person, because that's generally what I talk about.

I do do other systems. I've been at IBM 31 years, and have worked on just about every system. I've done user interface work, done lots of different things, and worked in systems management. So I've done a lot of different things in the industry, and I've worked with lots of clients. In fact, there are very few large clients that I haven't worked with, so it's been fun and a lot of opportunity to learn. But in this session, I want to talk about what we've been doing to the mainframe to hopefully reset your thought processes just a little bit.

So first, let's talk a little bit about what happens in a second, every day in the world. If you see this, 63,000 Google searches in a second, 71,000 YouTube views, you might think those numbers are significant. Might. Maybe. Until you look at this. And just for clarity's sake, that is 4 billion in a second. And just for clarity's sake, that doesn't include the highest transaction processing systems that are run in the world. So it doesn't include TPF, which means it doesn't include the airlines, railroads, and some of the reservation systems. Just for clarity.

The other thing that's kind of important when we think about this: if you think about when you get up in the morning, how long before you use a mainframe, you might be surprised. Because your phone, in the back end, probably something is running. Every time you swipe a credit card, take your choice, you are going to be using a mainframe in the system.

I work with a company in the Netherlands that likes to talk about the fact that their systems are a little bit critical. If they had a problem, 40% of the Netherlands' GDP would be affected. That's running on their mainframe systems. They're a bank. They're Rabobank. They happen to be the largest bank, or one of the largest banks in the Netherlands, and they do the instant payment systems. So if we think about this, these systems do a lot.

But if you think about the mainframe, I suspect... Okay, go forward. Go forward. Somebody in the back will make it go forward for me. Go ahead. Can you move the screen forward since it's not moving? Thank you. Is this your view of the mainframe? Is this what you think of when you think about the mainframe? You think about a green screen, and from what I've been told recently, dark mode is actually back in vogue, so maybe it actually-- Oh, sorry. Here we are.

If this is what you think of when you think of the mainframe, well, let's think about this instead. The mainframe hasn't been that green-screen system for years. The mainframe is the most modern system from a hardware standpoint that we have, and it's able to run the most modern technologies and do lots of things. In this particular picture, we're actually focusing on the high-transaction-throughput systems of CICS or IMS, and if you don't know about those, I'll be happy to talk about them later. Those run on our z/OS system.

The mainframe also happens to run Linux. So you can also run a Linux environment on this highly reliable system. And if you're running Linux on the system, well then, I have to say Linux is Linux is Linux, basically. Whatever you're doing on any other platform can obviously also run here, other than the fact that it's slightly more secure. And I'll get into that in a little bit.

The other thing that people say is the mainframe isn't part of the current world because it's not open source, and it has nothing to do with open source. Well, other than the fact that originally when Z first came out, it actually was open source. It might have been the first open source operating system before we went to object code only for the lawyers getting in the way. Actually, I think it might have been.

But here we go now. If you think about it, open source is a critical part of the environment, and people want to be able to contribute. And so this past year, in August, we announced -- the consortium announced as part of the Open Mainframe Project -- something called Zowe. Zowe is an open-source environment run on the Open Mainframe Project that has been contributed to by a number of vendors. Additional vendors, I am sure, will join this project to provide a set of open-source interfaces into the system, to give you additional modern ways to access the system.

So it's not that old, locked-off system. It actually hasn't been for years, but it is even less locked off: open-source capabilities to allow you to use REST-based APIs to get at the system, to provision services, a new modern browser-based interface to the system, as well as a set of CLI capability that allows you another way to access the system. This is an open-source community. Go out to zowe.org. You can go see the work being done. You can contribute to it.

Standard open source. There is a build pipeline out there, and it's either there now or it's about to be out there, so that you can build your software for z/OS and build it on the pipeline. You don't necessarily even have to have your own Z environment. You can work on a Z, contribute to the pipeline, and the pipeline's there and available so you can update and provide additional function.

The idea of Zowe is to help take the next step of bringing Z into this world. But it's important to recognize, in many ways, Z has been there for quite a while. This chart on the languages side is all about z/OS. Linux on Z is Linux, so all the languages that you know and love run there and there's no question.

z/OS itself, that system that people think of as old and have to run COBOL -- not that there's anything wrong with COBOL, just for clarity's sake. COBOL is a really good language, and all of those of you who don't agree with that sentence, it's probably the most easily understood language 30 years later. Think about that. You've got code that was written 30 years ago, and you can still read and understand exactly what it does because it's just English. I know people don't like it because it's just English, but it is simple and it does do business language very well.

But if you don't want to write in COBOL or PL/I, fine. You want Groovy? You want Java? You want Swift? You want Node? You want Python? It's all there. And any other languages that are really popular in the environment will start appearing. We have a Go beta that will come out more soon, hopefully. We have modern tools that run on the platform, so if you want to use your Git/Jenkins pipeline, go for it. There's nothing about z/OS that says you can't use the exact same pipeline that you run on other platforms.

And this is the other half of the fun. When we think about a system, we came out with a new single-frame system that actually sits in your data centers exactly the same way as all the rest of your machines. It's a standard 19-inch rack. Why does this matter? Well, it fits with the same hot and cold aisle. We switched it because it was backwards, and we took it from the non-standard, non-19-inch rack into a standard 19-inch rack so it fits into everybody's cloud data center. Why was our rack different? Maybe because it was there before, but whatever. The rack was different for no good reason.

One of the things this is helping demonstrate is we're removing all the differences from the mainframe that serve absolutely no purpose and bring you no value. The system provides a high scalable throughput transaction system. It has pervasive encryption. You can have full encryption on the machine without having to worry about the performance hit you would have to take somewhere else. It has all of that capability built in, but it was different. It was a different size. It was a different configuration. We had different tools. If you wanted to do mainframe development, you used mainframe tools, and if you wanted to do distributed development, you did something else.

So we're moving all of those differences so you don't have to worry about that anymore. Do the same thing, same process, same pipeline, same capabilities on the platform. This was a hardware way of making the statement: make it exactly the same. Software-wise, we've been doing that for a long time.

We also want to make sure that these languages and this capability don't just run on the platform. There has to be a reason for running on the platform. So if you're writing Java, why should I run it on Z? Why shouldn't I just run it on the cloud? Well, maybe because it runs better there. We spend a lot of effort and time. The same Java, same language, same app, runs on a different box or runs on Z. When it runs on Z, you have additional capabilities because of the hardware it's running on.

The first one is the hardest one to say. It's pause less. Not pauseless, but pause less. Java still pauses. But we've done the work to make it so Java pauses less. Why does that matter? If you have a transaction that you want to run consistently every time, it's really nice that Java garbage collection doesn't make it run slower some of the time. Pause-less garbage collection.

And because of the high encryption available on the system, you get the built-in encryption. You don't take that performance price. We provided additional capabilities and new instructions to improve the performance of applications as well. You get these because you're on the system. The other advantage: why would you run? Well, your data's sitting there. Something like 80% of the world's structured data still lives on your mainframe systems. If you want to access that structured data, having it sit right there makes a lot more sense.

The other thing, when we think about this system and the languages, you're doing a lot of processing on this platform. Machine learning runs on the platform. I can do my machine learning in cycle, so while I'm processing, it's available next to the data. I can have it access the same systems. When we think about removing all the differences that serve no purpose, you'll see we're optimizing the platform for what the platform does well. It does high I/O. It does high transaction throughput. It does machine learning in cycle, as part of the transactions.

So it's not that we're getting rid of the system. We're making it part of your enterprise DevOps pipeline, or at least that's the goal. And we have lots of different pieces to do that.

Let's talk about the modern pipeline. Once again, if I can get it to move. Here we go. When we think about this system, and we think about the modern pipeline, why can't I use Git? Why can't I use Jenkins? Why can't I use open-source tools? In the past, people would say, because it doesn't run on z/OS. Well, okay, then let's make it run on z/OS.

We have been porting tools. We have been working with open-source communities. We have been making sure that Git, Jenkins, Gradle, Maven, and those kinds of tools can be used in this environment. There are a few places where we don't have open-source tools yet, and that's because they aren't there yet -- and I said the word yet for a reason.

What happened in this space is we're trying to remove all the differences. I had a number of companies say, "Why can't I use Git?" Other than I already have a solution there and IBM sells one there. "Why can't I use Git?" And I went, "You're right. Why not?" So I went and got it ported. The idea is, if we understand what tools you need that are open source, we can work with the environment to get them out there.

If you look, you see Jenkins on this page. If you go to the Jenkins pages, you won't see that z/OS is supported. In fact, every now and then, they go break us. But there are people out there contributing to the environment to say z/OS matters. So we have it running. We run it. Every time a new release comes out, we go test it. We figure out what's just changed, go figure out how to make it work again, and then publish how to make it work again. Now, it's usually code page related.

It is amazing to me: the world has now understood code pages matter. I've always dealt with this ASCII to EBCDIC problem, and if you don't know z/OS, we still run EBCDIC. We will run EBCDIC, whatever. We have this interesting code-page problem. Well, now I've noticed that other companies have noticed this problem, except it's not ASCII/EBCDIC, it's ASCII to ASCII. If you look at the latest ports of Git, Microsoft has used the function that we added for ASCII to EBCDIC, and they've used it for ASCII to ASCII. Because the rest of the world, not here in the US, speaks other languages and has other code pages, and their code pages matter too. You need to convert into the right code page at times. Now, honestly, why doesn't everybody move to UTF-8? That would solve -- or UTF-16. That would solve the problem. But code pages matter, so we have to deal with that.

Every now and then, we have a problem with Jenkins. We, as an open-source community, can update it, make it work. We do. We have most recently fixed the last problem in z/OS. When I say we've been fixing problems, slowly but surely we've either been porting tools or actually solving a problem.

When you think about a z/OS environment, it's been around for a very long time, and we have some really good attributes about z/OS. Once you compile something, it will always work. This might actually also be the biggest problem with z/OS: that something you compiled 30 years ago still works. But okay.

Load modules still work. It's a load-module format. That load-module format doesn't leave the box. A load module runs, sits in a PDS, a PDSE, a partitioned data set, or a partitioned data set extended. It sits there. It can't go anywhere else. In order to make it go somewhere else, you use these magic Z tools, and you do some weird stuff, and then you put it back, and you cross your fingers. Well, no, and it always works. But here we are. How do I take this load module and put it in an Artifactory or a Nexus? It's this weird memory-map format, basically.

z/OS added a function to allow you to copy files that are load modules and put them in the hierarchical file system, the ZFS of Z. So now I can take that file, zip it up, and put it in Artifactory or Nexus. Brand-new function, brand-new feature. It came out this June. It's available in a ++APAR. Every single one of you can install it because it runs on any existing z/OS system.

I can now take my load modules, those little magic files that you built 30 years ago and haven't recompiled yet. Okay. You can still copy them to the ZFS, and you can put them in your Artifactory or Nexus, and you can have all of your application, if you want, put there. Or you can continue as we normally do, to only put updates there, because z/OS was the first environment that did microservices. Don't quote me on that.

I've had a company a while ago that decided, since each individual load module could be updated and delivered independently, maybe, sort of, they would call them each microservices. I wouldn't necessarily agree with that definition, but each load module can be delivered independently, so you have incremental updates in the system. You can take the incremental updates and put them in Nexus or Artifactory. We have samples out there available to show you how to do this. We've created another open-source project area sitting out in GitHub: github.com/IBM/DBB. We have samples that show you how to feed Artifactory or Nexus so that you can put your artifacts there and use the new function, and we documented how to do it.

So we have the ability to move off. I spent last week doing a demo of this, and I can always do a demo of the art-of-the-possible pipeline. I asked a question last week of a large number of Z customers, and my question was, "What's stopping you?" So in a sense, that's sort of my same question. This is possible. This is possible today. The most important thing about this possibility is this world makes Z part of the modern pipeline. It makes Z just another target in your environment. It makes Z just the platform that runs those things that need the qualities of service of Z, and you can choose to run what you want where. And it gets rid of the skills problem.

Because I will tell you that if you're using this modern pipeline, no matter what the IDE is -- take your choice of IDE -- if you're using this modern pipeline, I'll bet those kids aren't going to run away from COBOL because it's the modern tools. And actually, I've been able to prove that. The session before this talked about gamification and challenges. I have an easy way to get newer developers to learn COBOL. It's a really easy thing: "You can't learn a language, COBOL." Hear the word "can't" in that sentence? You know how many times the next day somebody comes up and says, "That's just English"? Just for clarity's sake.

PL/I's even better because PL/I is even more like a programming language. And when it comes to assembler, I get very little pushback, because that means they're getting to do the most advanced things. They get to work in the core. They get to do the most advanced things. So that's not the problem. This is the problem: make somebody look at ISPF.

For those of you that don't know me, I started in ISPF development. I'm the reason why you have the menu bar across the top and the command line in the wrong place. That's my fault. Got it? So I'm allowed to pick on ISPF. There's no reason for it. There's no reason you have to use it anymore. With a combination of Zowe, with a modern interface, a modern browser-based interface to z/OS, and with modern pipelines, you can remove that need.

The other thing about this pipeline: you might tell me that's great for developers, but I still have all these system programmers. I still have this problem. I've got to do my CICS changes. I've got to do all the other changes on the system. Well, I can use this same pipeline for my infrastructure changes. JCL flows through this just as easily. I can create Groovy scripts to allow my user admin to be done. I can create users. I can do all of those kinds of things.

There's a customer that presented recently that created a system image, a z/OS system image, using a Jenkins and Git pipeline, using Groovy scripts to create their infrastructure so they could IPL a new z System. Now, that's okay. That's a little unusual, but why not? Infrastructure as code applies just as much to this platform. So modernize the way you work with the system, and the system won't be so different.

So what do I need help with? The second one is, why not? What's stopping you? What's stopping you? What's stopping the world? Do you know, do you understand that the modern world works on the z/OS, and what's stopping you?

The other one is also very important to me, and I want to know: what are the open-source tools you use in your pipeline that you don't have access to that you would like to have? Because we do port open-source tools. We do work to get open-source tools ported. With the Zowe initiative, we have more access to make that easier for others. But what other tools? Is there something else that's stopping you that you don't see on the list that you really want to use in your deployments? Ansible might be one of them, and if you really want something like Ansible or something else, let me know.

I'm accessible around the world. I'm around all week. I'm on Slack. I'm on Twitter. You probably, if you're paying attention to Twitter, have seen me tweeting this morning. But I'm accessible and available to answer whatever questions and take that feedback about what's available. In the last two minutes, are there any questions?

Q&A

Question: Have you seen any real-world examples of this whole pipeline that you talked about?

Rosalind Radcliffe: So have I seen any real-world examples? One, yes, IBM. So the CICS team is probably the most advanced. They've been using RTC, not Git, but they have a modern pipeline with Jenkins fully functioning. They're 13 years into their transition. The CICS team can build a CICS build in now. They do it every night, but they could do it every few hours, so that's not a problem. There are a number of customers that have transitioned. There's some that have stood up and talked about it. Rabobank is one of them. Rabobank has a full RTC UrbanCode modern pipeline deploying through their environment. They stand up and talk about it a lot. State Street has a modern pipeline. There are other companies that have a modern pipeline. They're not willing to talk about it, which always drives me nuts, but okay.

And then there are actually a few. We've got this little catch that Dependency Based Build Groovy wasn't actually GA on the platform until recently. So the Git-based solution is not as often in production, but we do have at least one very large customer that runs a very large business, that doesn't allow me to say who, that is running on Git and the pipeline today. So they have already transitioned. We also have some very large banks that are using Git as their SCM, so they have moved and transitioned. So there are a number that have moved to modern pipelines, and then even some that have moved to the open-source pipelines. So it's getting there.

Question: Is there a demo that's accessible for us at the pipeline that you mentioned?

Rosalind Radcliffe: There is a demo. There are a couple of them that are available on YouTube, and I will put the links in the presentation and get it updated so when it's posted you have the links to the videos. We also have something we call the z trial that you can go out, log on, get access to a z system and play yourself. So you can actually log on and play with a pipeline that's been pre-configured. And I'm out of time, so thank you very much, but I'm here to answer your questions. Thank you. Enjoy the rest of the conference.