Rethinking Mainframe Modernization: From Migration to Strategic Transformation

Hey, everyone. Welcome back here to Tech Drunk tv. I wanna introduce you to my next two guests.

First of all, let me first introduce Mark Helm. Mark is the principal product manager at BMC. Mark.

Welcome to Techstrong. It's great to have you on here. Great to be here.

I've been, uh, involved in the mainframe for decades and as a developer and now in product management, uh, VI comp and BMC. And right now is the most exciting time for the mainframe I have ever seen in my entire career. Just with things going, it's a real renaissance.

It really is so great to be here to talk about. You know what, I think it's the most exciting time to be in techno. I like you, I've been involved in tech for decades.

It's crazy time to be involved in mainframe in everything it seems where rein the world is shifting right in front of us. Uh, an interesting stat, I I actually saw a recent survey item from BMC that more people, more younger people are working on mainframes now than almost ever, right? It's not just people like Mark or me or Tony who, you know, have our, you know, well, you have great Tony.

Be happy great year, but at least, at least you have it. Um, Yeah, but You know, it, it's all, it's all in here. And, and so, um, it, it's a great time to be in it.

So it really is just like such an exciting time. And, and, and one would think, well, mainframe, what are they doing with AI and everything else? Well, we're gonna talk about that, but first, let me introduce you to our next guest, and that's Tony Anter.

Tony is a DevOps architect, an evangelist at BMC. Tony, welcome. How are you?

Give us a little of your background. Uh, doing great, Alan. Thank you for having me here.

So, unlike Mark, I've been in technology for decades, but I've only been on the mainframe for maybe five to 10 years. Before that, I was fully distributed, uh, full stack Java guy, you know, e-commerce, internet, web, and I sort of got into the DevOps space years and years and years ago. And then from there, I, I'll be honest, I sort of fell backwards into the, into the mainframe and haven't looked back since.

I've only been here. But I like to bring, uh, a distributed mindset and a DevOps mentality onto the mainframe. I think it's the best platform.

And like you guys, I, what an exciting time to be alive in, in the mainframe space and in general, we get to be here at the birth of, of AI and see what it can do. And, and to your point, yeah, you wouldn't expect to take mainframe and AI and put them in the same place, but I think mainframe is poised to be a heavy contributor into the AI renaissance we're gonna see in the IT world. I agree.

Agreed, man. Definitely. So, you know, it's a funny thing.

Look, Tony, like you, I backed into the mainframe world. Well, second time I was in the mainframe world out of it, and then I backed back into it just when I thought I was out, they pulled me back, back. Godfather in, Gotta throw the Godfather Inly.

Now we've got an obligatory godfather in there, but, um, but you know, through DevOps, much like you through DevOps, because man, DevOps, DevOps ignited mm-hmm. Mainframe there, it brought the mainframe into the modern IT stack again, even though it never really left, it allowed us to do, you know, things like running Java and I mean, it always had containers. Mm-hmm.

But, you know, modern containers, modern kinds of stuff, and, and really, you know, systems of record, systems of engagement and being able to run them one in the cloud and one on the mainframe and making 'em work together. Applications that panned both sides. But it was funny, all through that, there was always an a small minority of folks who said, oh no, we gotta throw your mainframes for, right?

Yeah. We've invested, you know, 10, 12 billion more dollars in this, but let's throw it away to go run on, on some virtual machine or something. And, you know, and these applications and, and you know, I remember telling people, penny for penny dollar for dollar and beat it, nothing is as secure as reliable.

Correct. When you want rock steady mission critical, critical infrastructure. Why?

I mean, why, why you don't throw out what's not broke. Yeah. So, you know, mark, we're gonna, even though Tony and I are, you know, contemporaries of yours, right?

You, you have more time in mainframe than us. Why don't you, why don't you lead that one off? Right?

You know, I, I think mainframe really got into a rut and you mentioned like DevOps and, um, I actually wrote, oh, 10, 15 years ago, a column on it that the mainframe got sleepy and we were developing like the eighties or nineties, and we were just stuck into, that's it. And the distributed world in the late nineties, early two thousands were doing these amazing things, and the mainframe people just ignored it. And suddenly it's like the mainframe woke up with DevOps and started implementing all those practices and has done a pretty good job of catching up to it and be, and not being so dismissive and of other platforms.

It's been really exciting to see the mainframe be revitalized by this. And I think it's the younger generation coming in and bringing in new practices and saying, you don't have to do things like this. You don't have to treat new people coming to mainframe.

Like it's a hazing ritual and you have to work like the past. And I think I see the AI as being that same type of thing as DevOps was. It's just that another injection of excitement and change and that you can do all these things in the mainframe.

Agree. Yeah. I mean, I think Mark hit it right on the head there.

It's like people stopped innovating in the mid to late nineties and just froze. And then when I, you know, when the, when I started leading transformations mm-hmm. As you said, like when we backed into the mainframe, I came into it with a perspective of why can't you do this?

Explain to me, Mr. And Mrs. Mainframe developer, Mr.

And Mrs. Mainframe, cis prog, explain a technical reason why you can't automate your builds. Why you can't automate your deploys, why you can't automate testing, why you can't do any of these things that your distributed counterparts can do.

And the answers I got were, well, we've never really done it this way. It's just not how you do it. You just don't understand.

I never could quite get a, a technical reason. And from there, it grew. And I think the days of DevOps being some mystery on the mainframe are gone.

I think now it's just like on the distributed side, it's table stakes. Agreed, agreed, agreed. But, you know, people focus on the applications, but sometimes we reme we forget what underlies that application.

And that's data number one. And number two, very important business logic, right? It's the logic Yep.

Behind the application that provides a lot of that value. When you look, you wanna talk about technical debt. When you look at the business logic that is preserved and codified, if you will, right?

It's the, it's the, it's the tribal knowledge in many cases from, from companies who have been using these mainframe applications for decades, the idea of tossing them out, babies with the bath water, right? For the sake of modernity, let's say, or whatever else you wanna substitute modernity. It just makes modernity better.

I, you know, I'm, you're making fun of my funny French accent here, but, um, but, but you understand what I'm saying, right? Mm-hmm. It, it just doesn't seem to be Right.

Reasonable. Well Exercise. No, and you're, you're exactly right.

And that's something that I've been really following for a long time, is you mentioned the business logic is trapped in there, and there's been a movement of people say, let's just move it to Java. And I'm like, well, first of all, you don't understand it. How can you do that?

So what we have is an approach we call the A BC method, analyze, build, and convert. So first step is having people be able to analyze and understand those applications, because you're right, the business logic's there, but new developers don't understand them, and there's a fear of change. They're afraid to work with them and to exploit them and use them.

So first step is analyze it and then refactor those applications breaking apart because they're usually monolithic cobalt programs, tens, hundreds of thousands of lines. That's not a modern architecture. Rearchitect them.

And that makes it easier to work with. And then you could look at maybe converting, But, but Mark, I, I don't disagree with you, but to the point, and, and we saw this during COVID, right? We started during COVID, all of a sudden the call went forth.

We need cobol, uh, program is 'cause the, you know, the unemployment application in New Jersey didn't work anymore or something like that. But changing that, right, right. Changing it off for COBOL then was that was like switching the engine in the car in the middle of the race.

Yeah. And we need to stay away from those kinds of, you know, gun to your head transformations, let's call them. Well, I mean, I think that's why, Right?

It needs to be an incremental Yeah. I think that's why we came up with the a, b, C methodology, right? Because we are not about just jumping off the mainframe just because, right?

You have applications that have been around since the seventies, eighties, written in the early nineties. The people that understand them are gone. I know you, you're trying to move something to, to use your race analogy, you're trying to switch out the engine in the middle of the race and you don't even understand engines.

Right? Right. So at the end of the day, you need to understand what you have.

And I think even the most, um, uh, even the biggest mainframe zealot will tell you there are workloads running on the mainframe that shouldn't. There are workloads running on the mainframe that really fit for purpose, should not be running on the mainframe. But to your point, for your data, for your business processing, for your batch, you can't beat it.

You cannot beat it. Maybe someday you will, but right now you can't. So the biggest companies in the world aren't staying on the mainframe out of love, out of love for IBM, love for cobol, love for any of it.

They're staying there because they get the biggest bang for their buck. Right? And in order to, to convert that, you're going to have to understand it.

And you're gonna have to take a, a, a slow boil approach to how you do this. You're going to have to break these, these massive monoliths down into smaller chunks, understand them, build them, and then convert what is necessary, right? To your point, don't throw out the baby with the bath water.

Understand it. And I know that's a hard rub for a lot of upper management to hear, but that's the truth. You want, you want the most risk averse approach that you can take.

And we think we've come up with that. We think we've come up with a methodology that gives you the ability to understand what you're doing before you try to do it. I, I, again agree this A, b, c, analyze, build, convert.

But I think the important thing we need to remember, 'cause people, people make this mistake all the time. It's all or nothing. It's all or nothing.

It's such a Mistake. A hundred percent agree with you, Alan. Yeah.

Mark, you're shaking your head too. What do you, I mean, we see this play out, Right? Right.

All or nothing is, it scares me. It's extreme risk. It's that incremental approach, deciding which things, you know, you may say, I have this logic here that we change all the time, and I have a whole pool of people who can work in Java, comfortable at Java.

I want them to do it. Okay? Find that, first of all, in this massive application, find that business logic, pull it outta that program and maybe convert that.

But the rest of it still runs cobol. And it's fine if it hasn't been touched in 10 years, don't touch, change it. Leave it, leave it there.

Only convert the things that make sense to convert, refactor those things where you change them a lot. So it just makes more sense and it's a lot less risk. And you get a lot of, uh, value right away just from the understanding, rather than we're gonna take six months or a year and change it.

It's like as soon as you put these tools in place, you have immediate value. Yeah. And I think you have, I think also, Alan, to tap onto what, um, what Mark was saying, I think you have a lot of misunderstanding.

I think you have a lot of people who have now inherited the platform due to retirements, due to, due to, you know, your SMEs leaving and their com It, it's what it, it, it's, I I don't wanna call it confirmation bias, it's familiarity bias. They're familiar with the, with the cloud, they're familiar with the distributed systems, they're familiar with open source. So that's the direction they want to go.

And that's fine. That's a good direction. I've been that direction.

It it, it works out in a lot of cases. But again, you have to go back to what are you trying to do? The value of systems is data.

The value of systems is, is the data that it controls, the data that it owns and the business rules that affect that data, right? The platform, the, the logic, the um, the uh, uh, the code. It's all I, I'm gonna use the word again, table stakes.

It's all table stakes. It's what you do with that and it's how you make your money as an organization. That's what's important.

I, again, good, good points, guys. I wanna bring up something else though. And it's at the nitty gritty of this issue.

I first ran into it when I, I was doing, I was hosting a, uh, a podcast for the Open Mainframe project from the Linux Foundation and, and great organization, right? Love project, Zoe, all of that, John and, and me. And uh, mm-hmm.

Uh, I forgot the woman's name. May I believe who, who runs marketing. They're great people.

We did a, I did it for over a year and a half, two years about, and we had several panels like this around mainframe modernization. And here's what I found out, and I'm giving it to you as an outsider. You guys are inside on this, right?

But as an outsider, for too many people, especially for a company that got bought by another company, and I don't know what they're doing with their mainframe business, but for too many people, mainframe modernization was code for rip it out, right? They didn't wanna say, we're gonna rip out the mainframe. They said we're gonna, we're gonna do mainframe modernization.

And, but yet for others, mainframe modernization was more along the ABCs. It was more along, well, let's, let's be selective and build a better architecture. Let's transform not just modernize, but let's do transformation.

But not, not just a rip it out to rip it out sake, not some sort of risky migration. And we'll see if this can handle that kind of load. But you know, Tony, back to what you said, yes, there are some things that maybe we could do cheaper, better, faster on, on, not on the mainframe, but there are a lot of things we can't And, and knowing the different, it's like the old thing.

Just because you can doesn't mean you should. Right. Right.

And I, I mean, I, this is a problem in the community though, right? There's, there's a lot of us out there in the mainframe community who when they talk modernization, are talking extinction. You know what I mean?

And I, and that's impractical. I think it's, it's bad business, it's bad logic. It's, it's, it's just not the right thing to do.

It's skipping steps and going right to a conclusion. You've already, in your mind, and like Tony said, it's a comfort zone and you say, alright, we're just gonna get rid of, I don't understand it, it's just there. I'm not gonna look at it.

But what we're asking is, take a good look at it, run the numbers, and understand what loads should remain on the mainframe and for those, invest in understanding them and refactoring and selectively converting. And you'll get a lot more benefit with a lot less Risk. I think when we have these discussions too, Alan, I think the mainframe, and when I say, when I say the mainframe, I mean the collective us that is the mainframe needs to be real with ourselves that we have not done ourselves any favors.

Right? That whole, you know, rib Van Winkle thing we did from like 95 to like 2015 didn't help, didn't help the industry, didn't help the mainframe. And that's the reason why some of these modernization, why the modernization path has taken the way it is.

But we all know organizations and companies that are, what, 18 or 10 years into a two year plan to get off the mainframe. Yeah. And, you know, Famous flash words.

Yeah. At the end of the day, the mainframe is an awesome platform. The Z 17 is awesome.

It has AI built into it. They act with the Spire chips. They have the ability to run your LLMs and AI directly on the platform.

Now think about that. You have your, your AI inches, uh, millimeter, milliseconds, however you wanna measure that distance to your data, to the data. Not, not some set of data, not partial data, not, uh, hallucinations on the internet, the actual data, the customer data, the purchasing data, the financial data, the data that AI needs to make itself run.

Mainframe is poised to be there. And it is, it would be negligent of us, negligent of, of us as an industry not to capitalize on that and, and negligent of the organizations that are, that are looking at it. It may be a little bit of hard work and sure.

But it is still, to your point, the best platform fit for purpose for what it does, which is munging millions and millions and millions of records of data in a very small amount of time, very efficiently. So Tony, you opened the door, you let the, the, the genie out of the bottle. You mentioned ai.

I, I I noted the time because I'm surprised we made it this far without mentioning it. Well, we did, we mentioned it in the beginning, but in passing. So like everything else in technology, AI is gonna have a tremendous impact on our usage of mainframes on the next generation, if you will, of mainframe developers, of all developers, but of mainframe developers.

You mentioned the, the, the, uh, Z 17 already has GPU like capabilities built in. Mm-hmm. Of course, you know, when we talk about ai, the move is away from like training on A GPU to inference on, on chips, optimized for inference.

No reason the mainframe can't excel there either. But, you know, there's two aspects. There's the, there's the systems themselves and there's the people using those systems.

As we sit here today, talk to me about what role or influence AI has on each of those, and then collectively together. You want to take the, you wanna start off with that one Mark, and I'll chip in at the end, or, Sure. I, you know, with ai, the first thing that came out was the explain capability.

Mm-hmm. And for like 20 years, people were saying, could you know, I worked on analyzing code, could you analyze this and tell me what it does? And I'd be like, impossible.

Few years ago. Yeah, it became possible. And that's been amazing because now someone new to an application, maybe they don't know COBOL can understand it.

That is exciting as it is. And game changing as it is, is just the beginning of it. Because the next thing is really having personal assistance, things like MCP servers and agents to go in and anticipate the needs of a developer and go off and do tasks for them to really help smooth out any roughness they may have in working with the mainframe.

And that's gonna be a real big change to me. It's all about the developer experience. Yeah, and I mean, I think too, there's a lot of fear when you talk ai and I think you, it's good, you noted the time is how long it took us to get here, but I think there's a lot of fear when you talk to developers about ai and just, let's just be blunt, A lot of people think it's coming for their jobs.

A lot of people think that they're not gonna need engineers. You're not gonna need people. And see, I actually disagree.

I think that AI is going to be a tool that is going to revolutionize how we do our work in it. If you look back to the days when people used to make furniture by hand, you had to cut the wood, you had to cut everything by hand, you had to measure everything by hand. You had to take those hand drills and drill things by hand.

How many people would go back to those days as compared to using power tools? No one I can think of, right? And I think the same thing is gonna be looked at with ai.

I think AI is going to give us a, an ability to move faster, to go deeper, to understand more than we ever have had before in the IT space. And I think it's gonna be the thing that's gonna help get rid of some of the rub of modernizing your mainframe. It's gonna, it's gonna give you the ability to truly understand things that you've never been able to do.

See, what it's great at is understanding massive amounts of data, parsing it, collating it, and understanding it and coming to conclusions based off of it. And that's something that humans aren't good at. Just being frank, uh, my mom always said I was super intelligent and I was the smartest kid she knew, but I don't even think I can do this.

Right? AI is gonna give us the ability to be able to, to do that. It's gonna give us the ability to, to, to push this forward.

And I think it's going to bring a renaissance on the mainframe if we play it right, if we do the right thing. And again, I'm talking about the collective we not the three of us, Alan, that's great as we are. So, You know, it is, it, it's going, I think have a huge, a huge impact.

But there's two elements. And Mark, you touched on it a little bit. I think the first part is from an educational point of view, you know, Tony, you referenced, look, we got some applications where the people wrote the applications along God, we don't even understand how it was written, why it was written.

It's just that it works. But with ai, we actually have the ability to put that code in there and say, explain this to me, right? And all of a sudden, you know, now I can see, say the blind man, right?

You, you understand that. Now that gives you the ability to edit it and work on it and improve it. That's one use case.

Another use case is though just a whole new generation of developers, whether they're writing these new apps in COBOL or next version, COBOL or Java or something else, it, it's going to give us the ability, you know, to make that mainframe dance, if you will, right? Maybe in a new rhythm that it hasn't danced in before and maybe better able to say, Hey, using ai, look at the, look at my business logic. Look at my goals here.

What should I keep on the ai? What should I move off the ai? How do I make 'em work together?

I think, again, this is gonna really help not hurt in spite of, and I agree with you again, Tony. People are afraid there. It's, it is about is it gonna take my career away?

But I think those are the kinds of use cases we want to see here. Wanna see? Yeah.

I, I think it is. And I think that, again, you're dead on Alan. Um, I, I think that it is going to give people, and I think it's gonna give new life to people that thought their careers were over.

I mean, we talk about the great, you know, the, what did the, the great resignation, I've heard it called the silver tsunami. I've heard it a hundred different names for it, but I think it's going to give us the ability to weather that and continue on with the mainframe. And I think it's going to make the mainframe more open and more approachable than it ever has before, which has been the biggest problem of the mainframe.

To Mark's point, I believe Mark said that earlier, coming onto the mainframe in the old days was like a hazing ritual. You know, it was like, how much pain can, can, can we put on you and see if you still survive and get through the other side? Yeah.

Go. And now, now you know, it, it's modern tooling, it's modern practices, it's modern development practices. And with ai, now I can take those monolithic applications and understand 'em in a way I've never had the ability to before.

And, and we're only talking on the app dev side, apply AI on the operations side, on the ability to predictively understand where things are gonna go, where issues are gonna come up, where we're gonna have problems. And that's a whole other side of this coin we haven't even explored Uhhuh. Alright?

It's augmenting Teams, right? Yes, it is. It's augmenting teams and you know, there's this whole, whether you buy into it or not, about virtual coworkers and all of these things.

And in that way it does augment it, guys. I mentioned earlier about the, the worst time to do a modernization of a mainframe map is when there's a gun to your head, or you absolutely have to because things are broke and people are screaming. I wanna bring up the concept of evergreen modernization, right?

Where we're in, let's call it, you know, Tony, you are the DevOps guy. I'm gonna ask you to go first. Continuous modernization, let's call it, where we're not modernizing right now because something's broke.

We're modernizing it because we have the cycles and it's a good thing to modernize. What do you think of, you know, and by, and by the way, it's not like a one-time thing, it's a, it's a continuous modernist or continuous modernization, if we could call it that. Um, what do you think about that?

Yeah, so I have, I've always, so I did a talk on this years ago about, you know, continuous integrate, continuous improvement, continuous innovation, continu what, continuous whatever. I think that it is, my mantra has always been your never done it. You every day you wake up and it's rinse and repeat.

Meaning even when you get something that's good, give it a little bit of time and it's gonna be not good. It's gonna be things, you know, it will have passed it by. So I think this idea of continuous modernization is the exact approach we should take, number one.

So we learn from our lessons. So we learn from the fact that we don't go to sleep again for another 20 years and wake up and see if, if we're still relevant or not, number one. And I think number two is you need to constantly be tuning, constantly be, uh, um, striving for a hundred percent with the understanding you're never gonna hit it.

You're never going to get to a hundred percent modernization, a hundred percent test coverage, a hundred percent. Um, uh, efficiency. You're always going to have to be tweaking and tuning and end of the day, I mean, I don't know about you, Alan, I don't know you, mark, but that's why I got into this game.

I, I got into it, knocked to push a button, wake up every day and like, you know, in lost every 33 minutes, I gotta push a button. I got into this because I get to create cool new things all the time. And that's, that's how I look at it.

I don't know, maybe that sounds a little too much like a gift card, but, um, that's how I look at continuous modernization. And my mantra is, you're never done. If you're done, then it's time to quit.

Fair. Mark. You agree, disagree, or wanna distinguish Tony's answer.

I I totally agree. It's, yeah, it's, Tony said earlier, you know, they have these big projects and those just fail. So if you say we're gonna modernize and we got this big project, that's not gonna have a lot of success.

But if you say to the developers, make things better every time you touch the code, you know, it's the backpacker in me that you leave that site better than when you came. Pick up any piece of trash you find. Same thing for developers.

It just becomes part of how they work. And every day in every little way, making their code better as they're in there. And when you make a change, it should be better.

And that should be part of the code review. How did you make this better? Did you improve a comment?

Did you break something apart? If you have that as part of you how you work and it's in your DNA, then it just happens naturally and it's a much better approach. So you're always modernizing your applications.

It isn't just one big project and we're gonna turn it on and turn it off. Continuous Modernization. Yeah.

I want you to, I want you to think about this like, like an oyster, right? You have to think about this like, like an oyster. And an oyster gets a little piece of sand down in there and it's an irritant, right?

And that modernization is gonna be a constant irritant, but if you work it over time and you do it, the oyster turns that into a pearl, okay? And that's what we're shooting for. We're always gonna be creating that pearl based off of the, the, the irritants that get in there.

I know that's a weird analogy, but it's one that always comes up when we talk about this. That's excellent analogy. We'll Run with it.

Um, guys, we're, we're low on time. I, I want to ask just each of you, you know, there's so much, some of us who, you know, working on mainframe, like Mark for decades, some of us have left, come back, left, come back. And then some of us are new to mainframes and maybe we're even new to technology.

How do you, how, what, what's your recommendation to stay on top of the game? What resources from BMC would you recommend to people to, to stay on top of this? To, to, you know, be at their front line, if you will?

I'll, I'll go ahead and go. I would think that well, Alright, good, Tony, we'll let you go. We can get mark the last word.

Yeah, no, that's fine. That's fine. Mark should have the last word.

Um, to me it, I've always been a, a, a believer in learn your fundamentals, right? Learn your fundamentals, understand how to write code, understand your patterns, understand your platform, and the rest of it will just come to you. Uh, if we treat mainframe like it's some, then well, let me back up.

I think we've been treating mainframe like it's special. Like it's some kind of different thing for too long. If we go into it with the idea of the, of the, of the standard fundamentals that we have for development and programming, then we can fit it into the mainframe.

So somebody new, learn your fundamentals, learn your patterns, go out and do your education. BMC has a whole set of education out there that you can use, that you can learn. You know, go out and, and understand.

Understand the platform and what can be done with it. Don't be, don't be, uh, shackled by what was, you know, what's already there. Think about what you wanna make of it and then do it.

I and I think Mark can bring this land, this plane now. Yeah, and definitely, and I would add that you should follow us on, um, LinkedIn like BMC or Tony or, or me. Um, because we update you on things so often I find that people are not aware of all the improvements we've done, all the APIs, all the things with ai.

They, they could fall back into that Rip Van Winkle sleep and you really wanna keep awake. So follow us, go through like our documentation, our blogs, uh, the videos and keep up to date. We've done amazing things in AB and date, a product that's been around for over 40 years and it really is set up to do a whole lot of web hooks and APIs, but if you're not aware, you don't know about it.

So really follow us and look to each new release to see the things we're putting out. Good advice, good advice. Well, mark, Tony, you know, this was the longest 15 minute interview I've ever done.

I think we're over a half hour, but it was well worth it. Lot of great information in here. Uh, really important stuff.

Thank you both so much for coming on. I appreciate it and we hope you've enjoyed it. You know what, any questions, as Mark and Tony said, look them up on LinkedIn.

Go to the BMC website. Don't look at the Modern Mainframe podcast. That's something that we put out all the time.

Another good one. Yes, yes. The Modern Mainframe Podcast, right?

We DevOps dozen finalists. Um, go check it out. Check it out.

You know, mainframes aren't just for me, Tony and Mark and people who look like us, they're for you. And go check that out. For now though.

This is Alan Shimel for Textron. Thanks everyone. Have a great day.