Accelerated Mainframe App Delivery Demonstration Using PopUp Mainframe

Just in the demonstration, um, we're gonna show full support of a modern mainframe CICD pipeline. Uh, we're using IBM, um, an open source based DevOps stack. We will show how quickly it is to stand up and shut down a popup, uh, virtual mainframe in minutes.

Um, we're gonna showcase the fast track and snapshot and reset an instance to, to show you how quickly you can recover and repeat your testing. And, um, we're also gonna show, um, bit of Ansible and, and that's all about, um, improving automation and empowering the teams with self-service operations. And just quickly, the, the demo application is, is the similar ones we showed last year.

Well, same name Next Gen Bank, and that's a web-based ui. It's using Zeros Connect, uh, to the backend, and it's got a mixture of our old friends Cold War kicks and DB two. Um, just just so you understand, the, the backend for the next gen bank is running on a popup in dev test.

In a real world example, that would be, it would be production on a mainframe for, so you get, you get the idea of what we're trying to show there, so into, uh, the demonstration. Um, so before we start, the first thing thing we need to do is stand up a virtual mainframe environment to use. So we're gonna invoke an instance of the popup mainframe or pop up as we call it.

And you can see, um, we are actually standing the exhibition up in the Azure Cloud. As I said, we've got the two types of pop-up, as you saw on both sleeves. Um, one is for the X 86 hardware and the cloud, and the other is runs on Linux one.

And Linux said, uh, for the reasons that we've discussed. So they both provide the same ability to provide a virtual z os on demand. And for Azure, it takes around nine minutes to install.

So now we're, we're I ping logging onto a familiar, familiar TSO and we're getting into ISPF in a safe, happy space. So, um, now standing up a popup Z edition, um, this is actually a lot easier and quicker to install. Um, apart from us having to sign the license key, do we like to protect our ip, but it's literally running a couple of commands.

And then again, um, you can just log straight into TSO, um, and, uh, you see there, and again, exactly the same ISPF. So now, uh, now we've actually stood the environment up. Um, we are gonna, um, show you how we're gonna make a change.

So, uh, you could then install your applications by migrating that data in config, or if you've already done that and you've, and you put it into Git, then you would just check it out and build it from Git. But here, um, we're showing, um, we're showing our next gen bank system, um, and, and, uh, we've built this sum this sample application. Um, and we're gonna show the trans customer transaction history here on the UI in as sending order, um, oldest first.

So we're gonna show, um, there's a new request in from a user who wants to see that changed around, which means the transaction history needs to be sorted in sending order. But before we make the change, we are gonna show you, um, how we can take, um, a snapshot of the entire Z os environment so we can return to any snapshot with the self-service capability. And so this means you don't need to worry about potentially breaking the environment, um, to do this.

So this is just us literally, um, checkpoints done it. It literally takes a couple of seconds. Can you give it an arbitrary name to run the checkpoint?

Sorry. You can give the snapshot an arbitrary name. Yes, You can.

So I thought I saw that's what's happening up there. Yeah, yeah. So you can give it a name and then you can, that goes into a database.

So you can then choose which one you wanna go back to and you label them in a, in a sensible fashion. Yeah, Me, I like to label them just a random string of, of time code numbers down the millisecond precision. 'cause that really is useful later on, you need to get out more.

Yeah. Name it Steven. It just Next, next time, next demo.

It Would work for with a P Anyways. So here's our ZOS delivery pipeline. Um, indeed, any pan line pipe pipeline, excuse me, you're planning to adopt will run on a popup mainframe.

In our example, we're using a standard IDE to do the development. And then, um, we're doing a series of build and unit test steps before deploying the code and running system tests. Um, of course there could be other phases in your pipeline.

Um, there could be, um, there could be the security verification, but here and now we're gonna show the code chains. And the first time we do, it's gonna be in VS code. So the developer checks out the code from the GitHub repository, and then they're gonna modify the query to retrieve the rows in descending order, then commits and pushes the code back to the GitHub repository.

And then by checking it in the CICD pipeline is automatically triggered by the, by the code check-in. This pipeline uses GitHub actions, which in this example, builds the code using the I-B-M-D-B-B facility. And then it's conducts, uh, a series of unit tests using the open source tool, cobble check.

And you can see the results of the unit tests here, which have all been successful. And then it's gonna push the compiled binaries into an artifact repository. Artifactory.

Um, these binaries are then deployed onto a different ZOS instance using IBM deployment facility WY deploy, where we're gonna run integration tests using the Glasser open source testing framework. And unfortunately, you can see the Glasser test packs have reported an error. Um, and you can see the failure there.

And looking in, in our original ui, we can now let see that the balances are now blank. As it turns out, the developer has overlooked some logic, which was there for testing purposes. In situations like these, it's very used to barely go back in time to a previous state.

And we start from there. So again, we're gonna use a fast track, and very simply, the developer just can run a command, um, to rewind the entire ZOS system. And we're now back to the previous state, and we can see the transaction history as it originally was in as sending order.

Um, so now we want to go and fix the logic error, and this time we're gonna use IDZ to do the, um, development. So they can choose their own development tool, or it could either be an RSPF if you wanted it to be, and you could trigger the pipeline manually. It doesn't really matter.

Um, so now the code has been fixed correctly, and we're gonna commit the changes back into GitHub, uh, which triggers, uh, the pipeline again, and the pipeline's gonna run again. And this time, uh, magically, uh, and for the developers' benefit, they've all, all the steps have passed. And now if we go into our ui, we can see the order of the transaction history has been changed to support the user request and it's been successfully developed and tested.

And the valid data is now in descending order. So then what would happen, right, because this is still in, so is, is there a way to automate, I don't Even, correct. Yeah, so that pipeline, so that pipeline was just handed in the beginning part of, uh, the developed unit test process.

So in a typical DevOps, after that, you could then use exactly the same pipeline, uh, to promote, say, into a system integration test that could be in a physical mainframe using the same exact same pipeline as software using db DB deploy. So we help organizations do their end to end, uh, route to live DevOps. So you can use this where you're doing, where you're repeating frequently and you are recompiling and rebinding.

It's much better to be doing it on a virtual popup than using, uh, vital, um, you know, MSU on the physical mainframe. That's a really great point. So it's, so you really, if by using this, using this technology, you only the the last compile would need to be on a real physical system because again, that's one of the license stipulations.

You, you must, um, only run code that you've compiled on a physical mainframe, not on a popup, but the previous 20 compiles would be on a popup at no cost. Yeah, because you're getting, in terms of your msu and then Things like user acceptance testing and performance testing presumably goes on the final LPAR as well. Performance testing, correct.

Um, would definitely be, because otherwise your hardware emulation, it would perform differently. Um, so you'll be comparing apples and pears, but you could use popups for doing say, SQL performance and seeing how queries are running. And you could see it going faster and faster by, by doing it again and again.

So there is some performance tuning you can do, but, um, just understanding what performance work that is. Um, but yeah, we've, uh, you could have, uh, you know, you could, that you could go straight through to live and it could be a final approval before it's promoted live using the same DevOps tool chain. Yeah.

So you can, you can do that. Um, so you, you, you saw how we deployed a mainframe code change using automation, and now we're just gonna show you how you can streamline operations, um, and simplify management using Ansible playbooks. 1 release.

And so we've done a lot of work here with popup, uh, to help clients, uh, simplify the management of them. Um, and you can, you can use an existing Ansible orchestration node or you could actually run it on the popup if you're completely new to Ansible. So we, we've got the, the node, um, on the popup, and these come with a se popup comes with a series of Ansible playbooks, um, that are ship, ship with a popup.

And we also make them available in a GitHub repository we give to our clients. So we're developing all of the time and they can just take new versions or take new playbooks. Um, so in this one, uh, so, uh, you don't need to have any raef skills or, um, knowledge to better use this.

You could just use a file to put in the username and the playbook would, um, do the rest. So here we're defining a, a new user, um, a new starter called, uh, Trump D and, uh, they're just logging onto TSO and we've also, same as creating, we can remove users. And this is someone that's decided to, uh, leave us and join someone else.

And we run the similar, um, playbook. Um, Biden Joe is leaving found pastor you why and Joe ever a running application. So it's, And so there we go.

So just, that was just a very quick example, how we can put, put the, the operations into the hands of developers and that using Ansible playbooks, those can be joined up in other DevOps automation pipelines. So your creation and remove user could be joined up from your ServiceNow, whatever and be through end to end and just to find operations. Um, shutting down popup, um, is, uh, is really straightforward and easy as well.

Um, so it's a bit like, um, wanting to tell your children to switch the lights off when they leave the house. Again, users can shut down, uh, the popup in a very straightforward way. Um, and that is great for, um, not leaving environments idle and, um, just, uh, help meeting your sustainability objectives.

Alright, so just, just to recap, um, what you've seen, uh, I'm gonna return to the pipeline diagram once more. So what you saw is a, is a fairly commonplace and simplified application development process. Um, and this has all been running on the popup mainframe environment.

You can also use the pipelines to install full applications on demand from Git. And we work with our clients to do that, to put their, their applications. So if they just need to, um, uh, create an environment on demand, they can pull the application out and maybe the batch also from installing the GI and Artifactory and produce that into an environment.

And you can also use the pipelines, um, to perform DBA kicks and IMS like admin tasks. Um, so whereas before you need to page out to other members of the, of the mainframe team to do specific work, you can have the pipeline do that, um, do that work. So that really empowers the developer community and gives them the freedom to get, get on and deliver.

Um, and this, and within project teams, if you can reduce the project team size down to one or two, that's massive. We're gonna reduce the costs of, uh, development projects. You saw how quickly we installed a popup and how straightforward it was to bring a brand new technology stack, um, up and running and the opportunity to completely modernize the way you work.

Um, and that wouldn't disrupt any other users in the organization using existing dev test LPAs 'cause that that can be a challenge to actually install new software and do new things in a, in a, where resources are really, um, at a premium and you just can't also find resources to install software. Um, we also saw how easy it was to checkpoint and roll back. And this provides a powerful, resilient way to test out changes without the effort of delay of environment set up work.

And we showed you, we, we pretty much showed you app dev reimagine. As with a popup, it's easy to begin your DevOps journey from a standing start 'cause you get all that software in straight away in the, uh, the immediate install. So I mean, that was from an app dev perspective, but I think pop-ups and we've worked with a number of clients to remove technical debt and either doing code refactoring and batch refactoring, um, because it's very straightforward, um, to just keep on Undertaking tasks and if they're not working and just re rewind that out and start again.

Um, and, and quite often it's very difficult for organizations to decommission old software and con config. But if you know you need, uh, to get output of 20, uh, 30 results, um, you can keep on taking away until you still get that same, that same result and just reducing down your environment. Another, another key, uh, advantage of popup is by using the modern tools and ides you make the mainframe accessible to non-green screen users.

Um, and that's, that's really, that's really helpful because there's so much other knowledge in the enterprise, um, that don't have mainframe skills. They could be understanding test automation and you can use those skills now to by using the, the glass of testing framework and bring that other knowledge into mainframe without actually having to hire mainframe specific test automation experts. So it really, it really opens up, um, the, the mainframe to, to other users within the organization.

And that's gonna further drive down costs if you can use those, uh, those other commodity skills. So there's, there's, there's bit significant movement in, as far as I understand, in, uh, among main framers towards DevOps. Mm-hmm.

Longstanding, well, I think it's appropriately methodical and cautious as opposed to what I might call the Silicon Valley approach of let's dive in and find out later if it's problematic. But my point is, um, that that's still within, let's say the mainframe paradigm. This is a breakout from that.

It's a, maybe a safe one, maybe it's not a breakout depending on how you define where the line is. 'cause you're emulating, you're, you're, you, you're, you're, I feel like you're really holding the, the, the frontier tight. That said though, um, aren't you encountering this sort of cultural issue as you, as you address this real problem, which is, you know, that that all sounds, I mean IIII understand that you're allowing non-cloud, you know, on-prem, you know, uh, IFL and, and LinuxONE implementations.

But nonetheless, this is now, like a lot of these examples are really exciting to me. Yeah. 'cause I work a lot in the cloud native and, and you know, DevOps spaces, but I could see it being rather alarming.

Um, and among a lot of your clients, and I'm just asking about the cultural clash and when With anything modernization, DevOps, there's always that challenge. So what is great about this is that you can put it in and then one or two people from existing forward thinking application team can go and do something really new and groundbreaking. And then it's all about playing that back to other, other teams, showing them what they can do.

And you know, I think deep down people always wanna work smarter and better. So if they can see making their job easier and taking out a lot of repetition, they will want to do it. But as, but as you say, you know, there's always, we often come across lots of na naysayers.

You can't do this and it's hardware emulation. It, it is not the same. Well it looks and feels exactly the same.

You're running the same code base, go and show some progress. And once you've shown it and played it back, everyone wants it. And so teams are bending over each other backwards to get hold of it.

'cause their jobs become, you know, there's so much, a lot of main mundanity about running bits of scripts and tests and all these sorts of things. If that can all be done by the technology, you can do deliver so much more change. So I think it is, so, you know, you do, it does have to be sponsored.

It does, it does have to, anything with DevOps has to be sponsored from the top. So funding does have to be available. That's what I was, and it does need to be change managed.

It needs to be change managed. Like anything that doesn't go away. But I think if you can show real tangible results, um, and then that's, that's the breakthrough when other technical people go, whoa, I want some of that.

And then you're there. It's, it's, I'm with you on most of that. It's that, yeah, it's, it's passing over that threshold.

'cause I I, I can see you pitching to management dev, uh, app managers and so forth and they're just eating it up and then there's that part of the process that is not necessarily visible to you where they're going back to the team and they're saying, I, here's something. And then what I call the gum snappers, which are the, which are these technical folks are sitting there just going, oh, well yeah, but here's the five things that I need to do every single day that obviously this is not gonna be able to do, is gonna do poorly. Like the, the naysayers that you don't necessarily get direct access to if you are, if it is being like change management and if it's being pushed through organizationally, then I hear you that you're starting to show examples and these gum snappers, compatriots are sitting there doing, look at all these things I'm doing and there's jealousy and there's, there's that, there's that acceleration.

But I, I feel this, I sense this potential resistance in your initial pitch, in your initial value. I think that can be helped by having younger members of the team that have always worked in this way. So introducing these more distributed type skills into the mainframe younger, you know, sorry, uh, in their twenties talking That as a feature pick stuff up, Which is now very quickly To all this innovation and stuff.

Yeah. The gum snappers. That's like, that's, that is a problem.

That's not a feature that's a problem. That to some, to some, to some of, um, older members. It could be.

But as we all know in the mainframe world, um, there is addressing that skill shortage. Shortage is imperative. And Yeah.

You know, I think, um, I think if you'd, if you'd to launch this product five years ago that had been that problem, if I've been coming to share for years, you, you see this environment, the age profile, I, I I, oh yeah. I dunno what the demographic data is share of probably Got it. But the demographics of this environment are changing and I think what the more experienced professionals, let's call them that are, are seeing, and we've talked, I've talked about it in a couple of sessions so far this week, they're having to be less resistive to change.

Yes. Because the demographics, you know? Yeah.

Whereas it was 10 old guys who could all just gang together and not do anything, can be very resistant to changes a block. Now there's probably seven of them that, but the three that have been cycled in over the last five years, they're younger and they're looking over their screen going, oh, what are they doing? That's cool.

And they're getting dragged along. So I think that demographic's changing. But, but I think that there's, there's two points to come back to, to your question.

There'll be different teams. So you get to the, the development team, they'll be all over this. The managers will be all over this.

The systems programmers will be all over this going, this is great. We don't have to do this anymore. They can look after themselves.

The security folks are gonna have kittens. 'cause they see, they see in their mind their mainframe data going off the platform. Mm-hmm.

Keeping it on the IFL. That's a, that's a big positive win. Big game changer.

But Sunday I sat in an IBM closed door session and they're talking about simplification. How do we make this platform easier to manage? And you've got these, all these old crusty guys going, no, no, no, we are not doing this.

I was sat at the back of the room and I just wanted to stand up and say, it is not for you. You've just got to help make it simpler. So the folks coming in beyond you can do it.

This is not for the old trusty folks. Yeah. This is for the next wave of mind framers and mind of developers.

And this will make a huge Difference. And it's so funny you said that, mark, I was thinking exactly the same thing. I was thinking the great thing about if they were to use a popup, then it doesn't matter if they, they stuff up IDMS or do something horrible, you just rewind it back out.

It doesn't matter. So fortune really follows the brave with this technology, and you don't, and there's no, there's, you know, you sort of remove the risk. It's Self-sufficient.

And that's the thing that's, they don't have to go and ask. Yeah. Steven, who's the head of mainframe?

Can I have an lpar? They don't have to go to Jeff, who's the data storage. Right?

Can you restore all those databases for me? Think Press Button done. This is the conversations we had with VMware 25 years ago when it first came out.

The exact same conversations of, you know, you can train people to do open systems, you can do all of these things and, and, and stop having to run inlines on a symmetrics. You know, so this was, this was the same absolute problem we had with mainframes, but it went away because there was so much value to being able to virtualize this and being able to, to, to make a difference in the organization. It must been Too slow for too long because it cannot, it's not allowed to move fast and break things because it's too important.

Important. Yeah. Well now you can, but this, you break it as much as you like.

'cause you can just restore afterwards. This, this allows 'em to just break it. I mean we, we've got youngsters in the business and we say we give them their own little l pass, but we back them up ourselves.

We haven't got all this technology, but we say to them, yeah, if you break it, you fix it. And by the way, if you want to restore it, that's how you restore it. Yeah.

You've just made it really easy for them. 'cause I mean, I know this is a DevOps play, but for me, this is a great systems programmer training tool and technique, techie playground for You. You also have the other end.

You, you talk about the old crusties and, and what happens you, because I'm assuming you can back this up on a daily base, do a backup on a daily basis, a snapshot on a daily basis if You wanted to. Well, you can, you can, yeah. You can back it up in multiple Ways.

Yes. What happens if, uh, if all of a sudden the main database is gone, cattywampus, you could bring that back from there. Maybe even a ransomware attack comes in, like all of a sudden you're bringing that back, using that snapshot and you're back up and running within, uh, half, one, fifth at a time.

Then if you had to deal with the ransomware. Mm-hmm. That is a future use case I've been thinking about on how you can, um, where you can, um, uh, you can back up, flash back up all of the, all of the volumes and then you can create copies onto popup from the flash and use that to, to restore.

And particularly for production fix. 'cause you can keep on replaying scenarios that way. So I've been thinking about that.

Um, anyway, let me, let me wrap up. Um, we focused on the technical tasks in this, um, with the demo. Um, and, uh, but we can see the potential benefits of using this.

And we've proven with clients that there's been a 400% improvement in time to market using this technology by doing this early testing. Um, and uh, it's great for CIOs, um, sustain sustainability initiatives. We can shut down these environments and one of our clients on, uh, running the environments in Azure just by having them down two hours, hours a day, save the license bill as well.

So it has a sustainability and the cost saving if you're running in Azure. But again, switching off, switching these environments off anywhere is a pretty new concept for mainframe. Um, so, uh, yeah, we truly believe that pop-up mainframe revolutionized mainframe delivery by providing teams with, uh, immediately available fully functioning mainframe environment.

Um, and just reproducing more of them and to meet your use cases becomes really straightforward. And as I said, I think it's a, with what we've done with Fast Track is uh, definitely a game changer for environmental environment management and environmental management as well with through sustainability. But thank you very much.