PurePerformance - Open Mainframe, Zowe, OpenTelemetry: Modernizing the Mainframe with Jessielaine Punongbayan

Episode Date: February 26, 2024

While the mainframe is powering the world's most critical system the words "modern", "open source" or "generative AI" typically don't come to mind. So lets change this!To do that simply tune in to our latest episode where we have Jessielaine (Jelly) Punongbayan, Sr. Technical Support Engineer at Dynatrace, telling us why she is excited about the modern Mainframe and how it brought her from the Philippines via Singapore and Czech Republic to Austria. We learn about all the open-source projects and communities she is involved in such as Open Mainframe or Zowe that make it easy to connect the Mainframe with the modern tooling of today's development environments. Jelly shares her stories about the role of good observability, how it connects the distributed and the mainframe world and how it enables development teams to build more efficient systems. And what about AI? Well - you have to tune in and listen to the end!Here the links discussed in the episodeWriting a COBOL program using VSCode: https://medium.com/modern-mainframe/beginners-guide-cobol-made-easy-introduction-ecf2f611ac76 Using CircleCI to perform automation in Mainframe: https://medium.com/modern-mainframe/beginners-guide-cobol-made-easy-leveraging-open-source-tools-eb4f8dcd7a98 Using OpenTelemetry to capture Mainframe Insights: https://medium.com/@jessielaine.punongbayan/re-imagining-mainframe-insights-through-open-source-tooling-79dd4c937114Dynatrace support for Mainframe: https://www.dynatrace.com/technologies/mainframe-monitoring/

It's time for Pure Performance! Get your stopwatches ready, it's time for Pure Performance with Andy Grabner and Brian Wilson. Hello everybody and welcome to another episode of Pure Performance pretty well. I feel though it's a little bit of a mixed up situation here because I hear Andy talking in the voice of Brian and Brian talking in the voice of Andy. How is that possible? Do we use artificial intelligence to fake our voices? Yeah, actually for our listeners, they don't know if I right now am Andy using a Brian voice emulator and vice versa. That's a great, great question. It's deep fakes. It's the conspiracies. It's, yeah, it's all that, right? That's all the rage here.

Well, we'll say, we'll keep the audience out of suspense. I'm really Brian and that's really Andy over there. But now you can't trust us because, of course, we would say that if we wanted you to believe it. And so you're all out of luck. Anyway, I was trying to think of a way to bring up the topic today, Andy, but I was at a loss. So I'm going to rely on you to work your magic to find some sort of way to cleverly bring this up. So now that the pressure's on, I'm expecting some really amazing way for you to bring us to this topic of today's podcast.

Well, if you think about it, in the last episode, which was our 201st episode, we talked a lot about automation and also AI, artificial intelligence. We talked about JetGPT. We talked about co-pilot and things, kind of like technologies of the past, but also not of the past, of the current, of the present and the future. They will impact our future. But today we want to take a step back almost. Travel in time? Travel in time almost. Because today we want to talk about a technology that has been around for a long, long time.

We'll talk about the mainframe. We've talked about the mainframe in previous episodes. I believe we had Christian Schramm and I believe we had somebody else as well. I don't remember. We had at least two episodes, I believe, on mainframe over the years. But it's about time to refresh our memories. It's about time to talk about mainframe. It's about time to talk about why people that are starting fresh in the industry are actually interested in the mainframe. And I think, Brian, we couldn't have found a better guest than Jelly.

Jelly, who is also a Dynatrace colleague. And Jelly, if you do me the favor, sorry for it taking that long for us to actually allow you to speak. But now the floor is yours. Jelly, please introduce yourself. First of all, who you are, what you do. And then really maybe start with the question, why are you in Mainframe? All right. Well, hi, everybody. My name is Jesseline Punambayan, and you can call me Jelly, of course. That's my nickname. I am a technical support engineer for Dynatrace. Mainly, I'm supporting Mainframe technologies and as well as open telemetry and alerting.

So why am I in mainframe? Well, that's a very long story actually. So I started my career in mainframe exactly after graduating. So there is this programmer trainee that is opened by a local bank in the Philippines. And it's like I can go there and just train what applications that they have. So basically, we can choose between visual basic and mainframe. And they taught us COBOL at that moment. And I truly enjoyed developing in COBOL because simply it's really new and as well as it's super simple.

There's no like you don't need to memorize functions because it's technically in English. And so when they asked me if what department do I want, I chose mainframe. And from there on, I actually fell in love with mainframe. I fell in love with the processes. It's really hard because you need to find different ways on how to handle things compared to modern technology that you can just download a package. In mainframe, you need to be resourceful. You need to understand what you are really doing. You need to understand the system. You need to understand what you are really doing. You need to understand the system. You need to understand your code. You need to understand other people's code. And you need to

find, let's say, creative ways on how you can get what you wanted, how to achieve your project. And that's what I like about Mainframe. And then after that, it gave me an opportunity to go to different countries. I moved to Singapore to be a COBOL consultant. And then I moved to Czech Republic to join IBM as a mainframe support engineer, mainly for the systems, the IBM mainframes. And then I went to Prague to be an application developer where I work for open source mainframe. So there's this

new project, fairly new project, or maybe five years now. It's called the Open Mainframe Project and it's an open source project where it creates modern tools like, you know, let's call it a candy wrapper for mainframe. So it creates this wrapper where you allow VS Code and you allow CLI, you allow this desktop application and web services and stuff like that. You can actually use microservices to access your mainframe through these modern tools. You can use Jenkins now, you can use CICD, you can use Circus AI, whatever it is that you want. And we've worked on this project for, or at least I've worked on this project for two years or maybe three.

And then I moved to Dynatrace to know about AI and to know about monitoring and stuff. And I consider Dynatrace also contributing to modernizing mainframe in general. So yeah, well, yeah, that's why I'm in mainframe. Because I think mainframe is very interesting. I mean, the journey that I had is very interesting. I think you made a really interesting comment in the very beginning when you said, you know, mainframe is complicated because you have to know a lot of things. And I believe that is something we see, let's say, in the cloud-native world, maybe. I mean, the cloud-native world is also very complex.

But on the other side, you can quickly create code. We can quickly create something without knowing really what is happening behind the scenes. And so you can end up with a Hello World program that needs a container of several hundred megabytes and you wonder what has happened why how is it possible that I have a simple app that is only doing some console log output or even some simple operations and it feels like I have to download the

whole internet to actually get it running right and that's the that's because you know we made it very simple and easy and hiding the complexity. And there's a lot of generic tools that are then pulling the whole world into my dependencies. So how long did it take you to, I think, what do you think, how long does it take somebody

to understand the mainframe well enough to actually start writing code that provides business value? So it depends on your goal. So for me, my training took maybe like six months for me to be able to understand the whole, let's say, banking system and as well as how to write the code. And you start off with just writing reports and stuff like that. I think mainframe is very, let's say broad.

It's very big. And up until now, I've been in mainframe for at least 15 years and counting. And I still don't know everything about mainframe. It's impossible to know everything about mainframe. You know, it's impossible to know everything about mainframe. There's a lot of departments that you can understand. There's a lot of things that you need to connect to, especially now that they are modernizing it with APIs and, you know, a lot of web services.

So it's really hard to understand everything about mainframe. So for me, it takes really hard to understand everything about mainframe so for me it takes a lifetime to really learn mainframe and you know to fall in love with it every single day i guess you know andy the two things i took away from your your opening statement was number one given the choice between mainframe and visual basic yeah i probably would have picked mainframe as well but but the really interesting thing and i i think this came up on one of our previous podcasts too is that there's a side there's this need for people to enter the mainframe you know for for younger people to

enter a mainframe because everyone's aging out and it's still alive and well and one thing you mentioned could potentially make it really attractive, and I think the mainframe community should capitalize on this, is it sounds like if you do mainframe, you can travel the world getting jobs in mainframe, just like you can probably very easily get in mainframe and and go live in singapore for a while like you said and go to these different places which i don't know i think that's just a really really cool additional piece to it um so anyone listening who's interested in mainframe and you like to travel you know go for it yes i agree so that's one of the main things that attracted me to mainframe when i was choosing my my teacher told me that mainframe is very in demand and you can travel within three years to go out of the country so and i love traveling so i thought that's a good idea you know maybe like i could get a visa and i don't have to worry about really paying for travel, saving for a year and then travel maybe to Asia for two months or two weeks or something like that.

But I could really live outside of the Philippines and then travel at the same time. So that's what I like about it. And it's because it's really you're in demand. Your skill is in demand everywhere. Hey, quick question on this um so i remember when i was in high school and i was in the 90s i also learned couple and uh back then they told us i mean obviously there was a big demand at the end of the of the millennium right with the year 2000. So it was all crazy. But people back then told us probably the mainframe is not going to last for much longer.

Now it's like 20, 30 years later, the mainframe is still in high demand, which means I assume if somebody tells me now that the mainframe is not going to last for much longer, then I tell them, well, I don't believe you. Especially I think we should encourage now with this podcast, also people that are considering a career in IT and still tell them that the mainframe is a good choice, like you are a perfect example for

that. But can you help me a little bit understand, first of all, do you see this as well? I think you can confirm probably what I just said, that the mainframe obviously, there's no sight that it's going to go away even in the next 10 15 years i guess i think so i mean that's i truly believe in that it's because mainframe is highly used with a lot of industries and it handles a lot of monetary transactions and monetary processes. And changing that is actually kind of hard. So if, let's say, one bank would change it, it will take years to technically migrate from mainframe to another, let's say, application or another process.

So in a way, if you go to mainframe, you still have like, maybe if you join, let's say, a really big bank, you have 10 more years to join mainframe, you still have like, maybe if you join, let's say, a really big bank, you have 10 more years to join mainframe and then you can transfer to another bank or something like that. But I believe what you said, it won't go away. Mainframe will always be here and it will always need people to process and to handle mainframe code. And then also, help know, help us understand because just as Brian said earlier,

we're both, while I have a little bit of coding experience in the mainframe, but it's like 30 years ago, I've not touched it since, except the conversations we had with our colleagues and with some of our customers. But you mentioned financial. I think we all know that, you know, as you said, financial systems are heavily backed on the mainframe. Is there innovation still going on? I mean, obviously, mainframes,

there's still new hardware being built, and I assume the hardware is optimized. But is there anything else going on as well on the mainframe side to modernize the mainframe? Yes. Yeah, yeah. Can you fill us in a little bit on what's happening here? So yeah, so right now I know with the hardware stuff, I know IBM just released their Z16. So it's like, let's say it's way more powerful and way more good in performance type of mainframe. So hardware-based, yes, there's innovation. In terms of software, yes, there's also innovation and software. And one of those innovations, besides Dynatrace, you can see that Dynatrace is very modern in terms of mainframe

monitoring. But besides that, there's also open source tools called the Open Mainframe Project. And under the Open Mainframe Project is ZOE. And ZOE is this hybrid modern mainframe bridge. Let's call it this one, like modern mainframe bridge that allows you to use modern tools to access your mainframe. So it uses this ZSMF APIs. And ZSMF APIs right now

are already included in your ZOS OS, ZOS 2.4, whatever it is, if you upgrade to ZOS 2.4, ZOSMF is already there. It allows you to have these APIs and these RESTful APIs can access your datasets or your system information. You can fire commands there whatsoever. And we have ZoE where it uses the ZSMF APIs and built a VS Code extension. So before, you use a 3270 terminal to access your data set. Now you can use VS Code. You can upload and whatever it is that you want to do.

If you want to code using COBOL, you can do it in your VS Code. And the good thing about that is that you also can use all of these features of VS Code. And the good thing about that is that you also can use all of these features of VS Code. So if you're working on mainframe, let's say you're a full stack developer, you're working on mainframe and you're working on other things, you can definitely use VS Code to do all of your automation or all of your coding in there. There's also CLI. And CL CLI normally they target that to use with automation through CICD. So you can definitely include GulpTask, you can include Jenkins, you can have CircleCI, whatever it is that you want. I actually wrote articles about it as well. You have examples right now on how to integrate your mainframe through CLI and Zoey CLI as well. They

also have the desktop and the API mediation layer. And the desktop is mainly if you want to use a web rather than VS code. And you can access the 3270 as well through the desktop. And that actually frees you up with licensing for buying the 3270 terminals. So you can use the desktop. And this API mediation layer is like a layer where, because right now mainframe companies are doing some web services or adding a lot of RESTful APIs. And these RESTful APIs are really a lot.

Let's say for Kicks, there's ZS Connect, there's Endeavor as well, like with Broadcom, there's Endeavor with APIs. And you can use this API mediation layer to combine all of these APIs like a portal, like a swagger UI, and you can just access it through it. And with the mediation layer, it added more security because ZSMF, I think it's using basic authentication, but with API mediation layer, it uses tokens. So maybe it's just an added security. So in a way, for me, there are a lot of innovation right now

with different mainframe companies and as well as open source. OpenTelemetry right now is forming a mainframe SIG group so that they could acquire metrics from mainframe. And IBM, Broadcom, including us, I'm part of that group as well. We're working together so that we could get a lot of traces and metrics and we can use it through our application as well. We're working together so that we could get a lot of traces and metrics and we can use it through our application as well. Well thanks so much for Zoe. I know you mentioned this in the beginning, the kind of like the bringing the mainframe to the modern tools. But thanks again for re-explaining that Zoe

is really the project that provides access to the mainframe as far as I understand through APIs, through REST APIs, which now I think once you have APIs, you all of a sudden make it very easy to actually build tools on top that are using these APIs. Now, this brings another question to me, because once you open up kind of like a box by making it easy to access that box, and people will start accessing it more. Do you monitor? Do you observe it? So are these APIs observable so that you can see how many people are actually using Visual Studio Code? How many people are using the CLI through Jenkins? Is this an additional use case where you say,

I want to know who is now accessing the mainframe through these APIs? It is observable. It is. You can monitor it. But you need to, like, what I could think of

is that you can use open telemetry to do it. You can monitor it. You can definitely, I am not, I'm not aware of certain companies right now who's doing it. Probably they are building something on top of it to monitor those APIs.

But I cannot really tell who they really are. But I'm pretty sure OpenTelemetry, you can definitely use and monitor those APIs. I'm 100% sure about that. Well, maybe we should bring this back to the product team i would imagine it would also be important to at least from the non-mainframe side that's interfacing with the mainframe it would be important to monitor the usage of the mainframe because and i'm not saying this to throw developers under the bus in any way, shape, or form, but I think if people do not have an understanding of how mainframes work, what the cost factors of accessing mainframes are, there might be a temptation to just abuse the mainframe. Well, let's just call the mainframe at a minimum so that you can, especially with costs, right?

I imagine it's still a whole MIPS project, right? Or not project, but you know, so that you'd want to make sure that, you know, we're not having N plus one queries to the, to the mainframe and the same sorts of performance problems that we see everywhere. Cause it would just be too tempting to say, well, let's just call the mainframe. It's super powerful. It can give me what I need.

Do you know if there is, and this is a slightly different topic, but do you know if there is any sort of outreach or education to non-mainframe developers on best practices for interacting with the mainframe or are the people who are typically interacting with the mainframe aware of that to begin with? So let me repeat your question. So are you asking if there are trainings on how to code in? Not to code in mainframe, but best practices on, let's say you're a Java developer and you have to access that API. One of the things we heard in the last mainframe podcast is when you go to your banking app and you pull up your account information, there's a mainframe call behind there being done, right?

So you have your Java developers or whatever other languages who are writing those layers that are then accessing the mainframe. Have there been best practices, at least maybe not training, but at least published in some sort of way, to tell the Java or other language developers these are best practices when accessing the mainframe? Maybe treat it like a database if there's a cat, whatever it might be. I don't know what there are. Are there things that are bad to do that people have to understand when they're interacting with the database?

And maybe I'm stumping you here, it looks like, but I'm not trying to do that. As far as I know, well, definitely IBM provided some, let's say, guidance on how to access or to communicate with mainframe. But I haven't heard a lot of the things that you cannot do because in a way, when a Java developer, let's say,

interacts with mainframe, they normally go through either MQ or Kix. And all of these information are like mapped together. So imagine it like a JSON file. You know, there's always like a key value pair. And when you pass it to MQ, it translates it to a different format, but it's the same thing. It's like a key value pair. And then you transfer it to Kix and it will become a different language. So it's the same thing. But in a way, it depends on your configuration of your MQ and Kix,

but there's no limitation as to how you're going to communicate with Java or how a Java application will communicate to mainframe. I'm thinking more like in the realm of abuse, right? In the realm of abusing the mainframe. Abuse. Yeah, like if just like unnecessarily making, okay, it doesn't sound like there's too much. No, no, not really.

Not really because in a way, mainframe can handle billions and billions of transactions. So I have interacted with some of the customers that they said in one day they have 45 million transactions in one day in one of their production LPAR. So if you have 45 million transactions and maybe more, Mainframe can handle that. And that's why I think people are still on the Mainframe because they really can handle big transactions. And if you are like a Citibank or Bank of America, you have a lot of consumers or you have a lot of customers all over the world that uses your system and firing transaction everywhere in every minute. And the beauty of

mainframe in general is because it's tried and tested and they can literally handle billions of transactions every hour, every single day. Okay. So it sounds like there's not too many limitations or... Okay, that's great. Not so much. Not so much that I heard of, at least in my time, I haven't heard of abusing it because mainframe can handle it. How many transactions that you can do it. I got at least two big questions for you. The first one comes back to when you introduced your kind of career path, because you said back then in the Philippines you were offered to choose between basic and

the mainframe and then you got educated on it. If somebody comes in new on the mainframe now, what are educational paths or careers? Is this typically where companies that have a need for talent on the mainframe, they will basically educate developers or is there still other material out there? Are there university classes? I don't know. What is out there if I want to learn about the mainframe?

Yeah. So as far as I know, there are university classes that still offers mainframe. Not a lot. But there are, I know in the US there's like HBUs schools, or I don't know how they call it, but there are schools that offer mainframe classes. Right now, I know that the Open Mainframe Project is also creating this COBOL programming course and they have a separate mainframe education. So those are

two separate entities and one is just focused on COBOL and the other one is focused on mainframe information in terms of system, whatever it is you need to learn about mainframe. There's just course about that, like kicks, MQs and stuff like that. Yeah, and I believe that there's also a lot of inter-scale, like similar to Udemy, who offers a lot of courses. And IBM also releases a lot of courses regarding mainframe. So there are a lot of things that you can access if you want to learn. That's awesome. And then the other question now goes more into your daily work now that you have. So you said you're interacting with a lot of organizations that deal with the mainframe,

that have the mainframe, they operate it, they observe it. What are some of the challenges maybe that you see? What are the things, why do people use observability on the mainframe? If you say it's been battle tested over many, many years and it works fast. So what are the things that people find with observability and what are they doing with this data? What do they optimize? Can you give us some examples

on some of the things that you find? So I'm going to give an example with Dynatrace because that's what I know. So with Dynatrace in general, what they're doing is like an end-to-end observability. And that's something that mainframe doesn't offer in general, because if you have, there are observability tools in mainframe,

but it's more on infrastructure monitoring. But with Dynatrace, or at least with modern tools right now, they offer this end-to-end observability. And it's actually really beautiful because right now you can check whatever happens, let's say in your mobile application, you use an API and then fire it through mainframe, you can see it and you can see the number of users

that are using your mobile app, and then how many users or how many count the request count for your API. So in a way, there's this opportunity to, let's say, innovate your code or you can see like, ah, in this process, maybe we're accessing the db2 we watch more like unnecessary access in this part maybe we could optimize it or maybe we could we could separate it and then you know have two different processes in here so that's that's the innovation or at least that's the beautiful thing that i'm seeing right now in terms of observability and mainframe and brian i guess this is some of the stuff that you tried to

brought up earlier, right? I know we have our own little jargon when we talk like the M plus one query problem. I think, Jelly, what Brian, you meant earlier, are there situations like this where in the distributed world as a developer or even in the mobile world, I'm making calls to the mainframe that can either be avoided because I can add a cache layer in front or can be optimized.

And I think that was some of the things that we were also trying to find out. And it seems that this is exactly the reason why people are using modern observability. Yeah. And I think they should. I mean, it's a great thing to have this hybrid access to mainframe because I truly believe that mainframe is very useful and it's a standalone thing that if you have mainframe, it's very useful for you, especially for big enterprises. But I also believe that it's not just mainframe. You need to modernize it. You need to have an opportunity to make it part of this modern world, of this modern tooling.

And so I am a big advocate of mainframe modernization because I like hybrid. I think there's an advantage of using mainframe and there's an advantage of using modern tools. And if you combine it together, it's a very powerful thing. And that's why I like about it. Yeah, I think the really cool thing too is that back when I started at Dynatrace in 2011 and we had our Gen 1 stuff and the mainframe agent, we would talk to customers and they would have mainframe and they'd be like, we don't even walk past the room where mainframe is.

Like, you don't touch the mainframe. If the wind blows too hard, the whole thing is going to collapse. It's the backbone, right? And now you're talking about open source projects, you're talking about APIs, you're talking about getting observability in there. So what you're highlighting is exactly what's enabling you to have that hybrid approach.

And I imagine there was probably a lot of fear initially in the mainframe community of just even touching the servers and, oh, we have to upgrade the OS. Are you crazy? But it seems obviously with the demands, with the mobile banking, I believe, probably drove a lot of that innovation because it had to be able to handle that. As we say, if you sit there and keep refreshing your balance, you're hitting that mainframe and it's got to be able to handle it.

So it's really awesome to see that transformation. Yeah, I agree with you. And up until now, there's still a lot of, let's say, doubts. There's still a lot of, let's say, doubts, you know, there's still a lot of fear. But I think for me as a mainframer, I do my part with enablement, with just sharing my experience. Because, you know, I think in a way, if I share my experience, some people will connect with me and they will try to understand in a way that I understand it. And then maybe they could think of a new way on how to do it because they know something that I don't.

And so it's like a domino effect that if I just share my experience and then somebody will share the experience as well. And then maybe, you know, it will spread out like wildfire and then mainframe modernization would be a thing in the future. I just want to recap on a couple of things. So for me, the cool lesson learned is while I've been told 30 years ago that the mainframe will not be around for much longer, 30 years later we're here and you just tell me that the mainframe has opened up to the modern world, quote unquote, modernizing the mainframe, opening up through easy to use APIs, therefore integrating into the modern tool stack, opening up the mainframe

for many more people. I think that's great. There's a big shortage, I guess, in really talented people. There's a lot of educational material out there, fortunately. So folks, if you're looking into a career change, if you're looking at this mainframe thing, it's definitely something that will not only pay the bills, but also, like you, allow you to potentially travel the world from the Philippines to Singapore to the Czech Republic, and now you ended up in Austria.

A lot of cool open source projects that you mentioned. Also I would love for the listeners to provide blog posts because you mentioned earlier you wrote blog posts about integrating the mainframe I believe into Jenkins, is that what you said? I wrote something about integrating with CircleCI, yes. CircleCI, yeah. I think that would be great that we're adding the links to the description later on. Looking further ahead,

now we have 2024, right? I mean, the world is talking more about AI and the impact of AI on our industry and our world and society. But if you look forward, what do you think, what excites you about the next coming years, especially focusing on your era and the mainframe? Where do you see yourself and the mainframe, I don't know, in five to 10 years from now? Is there anything exciting coming up? In my own vision, what I like about mainframe or what I see about mainframe is more on embracing maybe this AI thing. Because I know that there are a lot of works regarding generative AI and mainframe.

So those are ideas. And I hope that in 10 years from now, there will be POCs or maybe, I don't know, some great applications created with the use of AI, especially in observability. I also want to see open telemetry to grow more. And maybe, you know, Dynatrace would integrate open telemetry and mainframe in their applications. So I also would love to see that. But mainly my vision is that, or my hope, is that people will try out the open source tools for mainframe. They would see the beauty of it and also advocate for it. That's my hope. Maybe one more question that will help you in your day-to-day job. As said i think you mentioned you're a technical support engineer that means you have to deal

with people that call in and say something is not working right what is the one thing that people people keep let's say complaining about or calling you about that you would wish they would know so that they can fix things themselves or just something where you said hey i would wish that more people know about this one trick or this one thing so that they can help themselves instead of always picking up the phone or creating a ticket so most of the time that what i hear is that ah i will just communicate with the mainframe team. I don't know anything about this, but I will talk to the mainframe team because they know more about this. So what my wish is, is that, you know, they would try out this integration of modern tools.

Because basically the people that I talk to already knows about modern tools. And now once they integrate with this, they would be able to, let's say, see how they could actually take advantage of innovating mainframe in their processes in terms of automation in general. So they don't really have to be scared and just rely on, ah, the mainframe team knows about this. But I would want them to learn more about mainframe through the use of modern tooling, because you can do it right now, and integrate their day-to-day activities and their automation through this modern stuff. That is my hope. I don't know. activities and their automation through this modern stuff. That is my hope. I don't know. It sounds like Mainframe, based on what you're saying there, is very similar to database, right?

There's the DBAs over there. We just tell them there's something and there's the Mainframe. And you're just hoping Mainframe just becomes part of the common thread amongst everybody and it's not this mysterious like,'s, we'll send Joey to talk to the mainframe people because they like them, right? Exactly, exactly. Because sometimes it feels like that in my team as well. Like, oh, mainframe, Joey will handle it. I don't want that.

I want it to be like everybody knows about it. It's like, you know, I don't know, AWS or Azure, everybody knows about it and they're interested to know about it. So that's my hope. Cool. That's awesome. Celi, did we miss anything? Did we miss anything that we need to mention to educate our listeners on modernizing the mainframe to anything that you want to get off your chest? So, well, nothing really. I think we talked about a lot of things. So we thought about a lot of the projects that I've worked on,

or at least a lot of the projects that I want to share with everybody. But I think the last thing that I want to call, or at least a call to action to our listeners is that, you know, just try it out. I urge you to investigate because I know that most of your listeners are not mainframe users. So I urge you to check out the open source, open mainframe project, check out the VS Code or the CLI if you want to, if you know about JavaScript or if you know TypeScript, start there and try to extend it, try to create applications. Maybe if you have some ideas of automating, you can try it out. You can try the CLI and automate your process in mainframe.

And then at the same time, I urge you to share it. Please share it through blog posts, share it to podcasts, share it through conferences, because the more people that talk about mainframe modernization, the better. I would love to hear a lot of, let's say, young developers or young IT engineers to talk about mainframe and discuss about modernization or discuss about innovation in general. That's my request. Have you ever tried to put in a CFP, a call for papers to a conference like KubeCon over DevOps? Not KubeCon, but most of the conferences that I pass is mainly mainframe because most people don't know about it. So if they see mainframe like, nah, no.

No, but the thing is, right, if you think about it, and we keep talking about the banking industry that has been revolutionized in the last 10 to 15 years with building modern apps in front of the mainframe, those engineers, those architects, you'll find them at conferences like KubeCon because they're building the new stack on Kubernetes. So maybe that's a good opportunity for you and for everybody that, you know, spreading the word on modernizing the mainframe

to speak at exactly those conferences. Yeah, I would love it. I mean, if they would accept my my abstracts yes that i would love to talk to so then here's what we do i happen to be part of the cncf and one of the ambassadors you put in you put in a good you put in a good cfp for the um not for paris because paris cfps are closed but the next cubecon is going to be in Utah in November. All right. And there we need to go all in on mainframe

and on how to connect the Kubernetes world with the mainframe world. We should do that. Yeah, we should. I agree with that. I've got an idea for a slide for you. You have a slide with a passport with a bunch of stamps. I'm thinking like a 1950s U.S. travel thing where they would have these really Art Deco type of posters. Somebody on a beach with a keyboard terminal, like Jet Setter, World Traveler. Like, this is mainframe.

Because then people are like, oh, what's this? Because, you know. Advertising oh what's this right because you know advertising yeah yeah but andy this this brings me to a thought on you know with even to our product team if you want to bring this back right so in non-mainframe observability and performance has been rapidly expanding to cost centers right especially with this idea of cloud, right? The idea of let's, you know, the word I used before, abuse, right? People just spin things up and down, right? If we're getting to, if we get to the point with some of this observability and the open source stuff, pulling out the ability to pull out, and I'm assuming it's still MIPS is what

you're charged on. Has that changed at all? So if you can pull out the amount of MIPS you're costing per transaction, tie that back to the front-end developers who are creating those calls to the mainframe. That can be another way to look at cost optimization at mainframe usage so that they know I'm making a change here. It's going to make this many calls or cost on the mainframe. Now IBM would probably hate this idea, but it's going to help control, right? Because as people adopt mainframe,

as you and the other mainframers out there build this excitement that like, there's a lot of great things you can do at mainframe. Obviously the kickback is, the blowback is going to be now the mainframe cost goes up, right? So having that observability data to tie the usage, the interaction to the price it's costing will help minimize that impact or at least make it more efficient. And I think when we see that, when it gets to that point, I think we can,

because that's right now, that's the leading edge on observability right now, I think, is looking at that cost side of it, because that's beyond performance and all that. If we can get to that point on mainframe, I'd say that mainframe will come full circle back to the top, because it's going to be what we call a first-class citizen. It's going to be a main thought piece. But that would be awesome to see that get to that point. Yeah, I agree with you. I truly agree with you. I'm glad you don't fakely agree with me. Thank you.

Awesome. Brian, you want to bring this home? Well, that was my bring home. So oh, you mean just do our little... All right. all right well jelly thank you so much for being here today um we love it when we have these more less less frequent topics on because number one it reminds us about the importance of things like mainframe but also gives us and our listeners a chance to catch up on technology that hasn't been in the forefront so much so thank you you really a whole lot. I truly mean that. And for any of our listeners, there's going to be a lot of links in the show notes up on Spreaker, but also I don't know

where else they get aggregated. Please check those out. And if you have any interest in mainframe, definitely check it out because it could be a really fun opportunity to do something a little different, even just in terms of jobs out there, right? If you're thinking about the hot new markets being security, right? There's a lot of people, but like mainframe is out there. Mainframe is a coding language. It's not something completely brand new.

You just go on something different using your current knowledge, and you can go into that. Anyhow, thank you all for listening. We really appreciate every one of you, and we'll see you next time. Bye-bye. Thank you. Bye.