developerWorks Interviews ... Dave Rhoderick and John Thomas on the mainframe computer, today recorded 4-6-2006 LANINGHAM: This is the developerWorks Interviews podcast series. I'm Scott Laningham, developerWorks podcast editor. This time we look at the place of the mainframe computer in IT today and what it means to today's software developer. Our guests this time are Dave Rhoderick, mainframe evangelist for IBM Software Group, and John Thomas, a software engineer at IBM who has been transitioning to the mainframe. Until recently, John had worked entirely on non-mainframe technologies, so I'm sure his perspective will be of interest to a lot of developers out there. Joining me on the question asking side is developerWorks editor-in-chief, Michael O'Connell. Gentlemen, thanks for joining us today. RHODERICK: It's great to be here. JOHN: Yeah, looking forward to this. LANINGHAM: Let's kick this off. I think it's very obvious that the first thing we should touch upon is the general state of the mainframe, or maybe I should even ask, where does it appear to be in its life cycle as technology, and is that place generally understood? RHODERICK: Well, Scott, it's true that the mainframe is a mature technology, but it's still very much modern technology, and it keeps on reinventing itself. And I think as we see new things happening in computer science, you will see the mainframe often is at the forefront of implementing these computer science concepts, whether they be Java or the latest hardware technologies or anything to do with Linux. Mainframes have been doing Linux for several years now. So I think the mainframe is very much at the forefront of modern computer technology. JOHN: Not just that, Dave. It turns out that a lot of the technologies that the mainframe has are technologies that some of these so-called modern platforms are copying to some extent. You know, I started looking at learning about mainframes and I find that a lot of things that are there are what you normally think of as leading edge or modern technologies. And the mainframe already has this. LANINGHAM: Do people know this in general, though? What's the perception as opposed to reality? Is it opposed to reality, I should ask? RHODERICK: Yeah, I think the perception is -- I think a lot of people aren't aware of what mainframe capabilities are. And they often look at the latest and greatest technology in PCs or Unix and thinking that that's the state of the art, whereas in fact, I mean take virtualization, for example, that's something we've been doing on the mainframe for decades. And it's only really becoming a viable technology in these distributed platforms. And although they're doing great things there, the mainframe still beats it by leaps and bounds in terms of the granularity and the sophistication of virtualization. JOHN: Yeah. Coming in as someone from a non mainframe background, I was pretty impressed with something like VMware or Microsoft's Voice for PCS, a mechanism I can use to run multiple operating machines on my one machine, my laptop. Come to the mainframe and look at VM, and I'm just blown away at what it can do, how easy it is to create new machines on the fly, copy machines, so forth. This is stuff that's rock solid and exists today. OC'CONNELL: So, John, is it fair to say you were pleasantly surprised a few months ago when you started? JOHN: Oh, yeah. I have my reservations when I was asked if I wanted to look at the mainframe. I said, I'm not so sure about this. But when I started looking at it, more and more I find that there are all these, you know, really exciting pieces of technology, whether it be with respect to the infrastructure, whether it be with respect to the hardware or the software or with programming. Constructs in programming that I sometimes sort of assumed were part of the newer generation of programming constructs like J2EE or .Net. Most of that has already been developed and put in place on the mainframe. So definitely pleasantly surprised. RHODERICK: John, would you say you had a prejudice against the mainframe before, or why did you have these reservations? JOHN: Probably because I had started off and I was in my career so far I've always dealt with Windows-based or Linux-based systems, and it was a very defined world -- drag and drop, point and click, what you see is what you get kind of world -- that's been my mind set and I've developed in those platforms. And for some reason I think I had the perception that mainframe was just all very old fashioned, some kind of cryptic commands and cryptic green screen environment, with very arcane technologies to deal with. RHODERICK: So the green screen and SPF and JCL and all of these sort of rather as you say arcane acronyms are things that put you off but I think you found since then that in fact there's a very modern development environment. JOHN: Yes, plus I was surprised too -- all of those things are there on the mainframe, all of those things that you mentioned ISP, green screen, JCL, et cetera. If you don't want to deal with the green screen environment to develop your applications you don't have to. I came across this product from IBM. It's called WebSphere Developer for z. Actually an Eclipse-Based product that allows me to do a lot of this in the interactive GUI based manner that I'm familiar with that I'm used to, so I can use this tool. It's a work station tool. It allows me to do multiple things multi task, switch back and forth across windows. I am not -- I'm not using a green screen terminal. I'm using this tool. I can do compiling, virtual debugging, step through code that's running on the mainframe. It's just like dealing with any other development platform which I found was very surprising. When I develop a Java J2EE application that's going to run on WebSphere or I create a C# application around .Net, I expect a certain way to do that. And developing for the mainframe I find that it's very similar. I'm using this tool and it allows me to do all of these things in an intuitive graphical manner. RHODERICK: Which languages can you program in to do? JOHN: COBOL and PL/I are the so-called traditional languages for the mainframe. But you can also use Java. You can use C. So you can use modern languages like Java also. LANINGHAM: David, you know, while we're on this issue of technology, you know old versus new and those perceptions, what about performance issues and costs related to performance issues? Isn't that an area where the perception is you just gotta pay real big bucks to get this performance, which can be pretty high end performance, or is that an issue today? RHODERICK: Not really. The point I would make, I guess, to start with is many companies already have mainframes. And the mainframe, people don't really -- I guess not everyone understands what a mainframe is. Perhaps an easy way to consider what a mainframe is, is to go through a little thought exercise that I dreamt up a while ago, which is if you were running a lot of distributed systems and you wanted to reduce the cost of them, how would you do that? Now, if I was a CIO or CTO, this is how I would go about doing it. I would take all these distributed servers and I would move them into one big room. Because that would allow me to start saving money immediately. I could save on facilities. I could save on air conditioning. I could save on un interruptible power, the ability to do reconfigurations quicker and easier. I would even be able to save on sneaker soles and that sort of wear and tear. Then I would standardize on the same hardware and software. So if it were PCs I'd try to go to one vendor. I'd try and go to the same operating environment. That would give me efficiencies on support, maintenance acquisition and sort of some more savings. Thirdly, I would then automate systems management. I would try and get everything to be easier to control, prioritize the workload, distribute work better through an automatic system. That would save a lot of labor, would save also potentially duplicate operating system, middleware costs and a lot of memory, because if I could actually save on the number of images I had, I could save on the amount of memory I'm using. I would then consolidate on to one machine so that I could actually start sharing things easier and have blazingly fast in memory networking speeds. Then I'd start doing virtualization to increase utilization and simplicity of management. Now I'm getting ready to run a whole bunch of different business processes on one system on demand. I would be able to do service-oriented architecture much easier because all these things would be sharing the same hardware and software. So I'd be able to workload management much easier and extract every ounce of capability. And finally when I put all of these things together into one big multi-service system, I'd be able to justify improved quality componentry. So I'd be able to get better memory, better CPUs, better chips because I'd be able to -- because I'd know it was worth it because I'm putting all these systems together and it makes sense now to improve the quality. When I've done all of that I've actually got a mainframe. That's actually how I get to a mainframe. The mainframe is designed basically to do all of these things together. And then we've saved a ton of money by doing so. So the thing is people often think comparing a mainframe with one distributed system or adding them all up, they don't realize there's a lot of hidden costs out there that you can save on by doing the sort of steps I just outlined. LANINGHAM: That's a great explanation , Dave. Thanks. Now John, you're making this transition to developing on the mainframe. Are the skills difficult to acquire? I mean, what was the reality for you in moving to the mainframe? JOHN: Yeah, I did have that perception. To be frank, there was definitely a learning curve. There's definitely a threshold. But once you get over that threshold it's relatively smooth sailing. I'm still learning. So of course I can't claim that I've mastered the mainframe, no. But the way I approached this was I went about learning the basics of the mainframe. So what do you mean by a data set? What do you mean by JCL, not that I want to use it? What is it? What do those letters mean? So I went through some time, maybe a month or so, just you know learning the basics of what the mainframe was. And I was not rushing through it. Just took my own time to sort of absorb this. And then I started playing with it. I started playing with the mainframe system, with the privileges that I was allowed. So I played around with some COBOL code. I played around with the CICS application. I played around with administration of the CICS application, just simple things to get my feet wet. And I realized, especially with CICS, like I mentioned earlier, a lot of the concepts that I had come to sort of associate with J2EE and .Net, things like containers in J2EE, something that manages your resources or the logical separation of presentation layers and business logic layers. I had somehow always thought that these were some sort of modern bleeding edge concepts. I found that all in CICS. You can separate your separation in business logic layers. You can do containers. You can -- declarative programming in the sense you're not hard coding your file name or your file location; you're programming, your business logic is separated from those artifacts. All of these constructs -- I actually began to like it. I said wait a second, this is actually very cool and I can do this in a relatively painless fashion. Of course I need to know the basics. But once I know the basics I can do it. And the tooling that I mentioned earlier, WebSphere Developer for z allows me to do the development pieces in a manner that I'm comfortable with, without having to learn cryptic green screen commands. So, yeah, overall it is -- the perception has changed considerably once I started playing around with the technology that's available. O'CONNELL: So in fact you were able to on one hand learn the skills needed without too much effort. It was less painful perhaps than you anticipated and at the same time you're able to continue to use your prior skill set instead of just set that all aside -- JOHN: Right. O'CONNELL: I guess it's two different misperceptions that may exist. LANINGHAM: Dave, what about demand for these skills that John's talking about? Is there a -- what would you say to developers out there that are pondering this but wondering, is there a market for these skills? RHODERICK: Oh, yes. Well, that's a good question. But basically we are continuing to shift lots of mainframes. In fact, it's a nice steady growth. And we're improving our market share in the high end server category. We have a lot of customers consuming mainframes, and a lot of them are now looking to use new technology like WebSphere on the mainframe and there is a lot of requirement for skills, like John's, where you have both distributed and mainframe skills. That's a real sweet spot now. Customers are really keen to hire that sort of skill set. So I think it's a very attractive proposition if someone was to have both of those skills. JOHN: Dave, do you think I should ask to my management and ask for a pay hike? RHODERICK: Yeah. O'CONNELL: You have some job security, sounds like. JOHN: Right. O'CONNELL: You said in earlier conversation that something like 90% of some business's revenues is based on mainframes which certainly means it's not going to go away any time soon. RHODERICK: Exactly. A lot of the core business out there that customers still drive is based on mainframe applications and transactions. LANINGHAM: I know there was one other thing that we had chatted about bringing up and touching upon and that was the idea of Web services and exposing mainframe apps and obviously there are a whole lot of mainframe applications out there. What about that in terms of the real value of all that we've been talking about here and where things are headed? RHODERICK: Let me just say -- I'll introduce the idea and John you can perhaps tell us exactly how you can do it and how easy it is. But basically I think the latest ideas, which are pretty well agreed upon in the industry and within our customers, is to integrate the existing processes with new ones, the best way to do that is rather than to reinvent the wheel is to take what you already have and make it easy to consume in modern architecture. And the way we do that we call is service-oriented architecture. It's been something that we've been talking about for several months now, if not years. And the mainframe turns out to be able to do this extremely easily, as John has already started experimenting. JOHN: Yeah, I've actually been building a process, if you will, it's a business process that I'm trying to build. It's a choreography, if you will, where certain things happen in sequence and certain things happen in parallel and they all come to a conclusion in order to accomplish a business task. And what I'm doing is I am taking existing CICS programs, existing IMS programs and sort of wiring them together. Instead of having to rewrite everything from scratch, what I'm doing is taking an existing CICS program and turning it into a reusable service. And there's tooling to do this. Tooling is pretty intuitive. Once I turn it into a service I can then wire it into business process. And there are tools to do this. There's a graphical tool in WebSphere Developer which allows me to take CICS, turn it into a service, wire it to another single service. Wire it to another Java service and have my overall business process laid out. My choreography laid out. The tooling to take CICS and expose it as a Web service, it's actually pretty intuitive. It's actually as easy as, you know, right click, the COBOL file, say generate Web service assets. And it generates those key assets like the WSDL file and related XSL files and there's a deployment step where I deploy this. And I'm ready to test it. I'm ready to go. It's actually pretty easy to use. And the CICS run time itself supports Web services. It has a SOAP engine, it knows how to process the Web service as headers, it actually supports WS security, Atomic transactions, and it's up to the latest Web services standards. You can use it today. LANINGHAM: That's cool stuff. I know this is a conversation that we could continue for a great length of time, and maybe it's one we should come back to, because I'm sure there are some, probably some other misperceptions that we could debunk and other exciting areas that we could go into that we didn't even cover today. But I just wanted to thank you both for spending time with Michael and I. It's been a really interesting discussion. RHODERICK: You're welcome, it was great. We enjoyed it. JOHN: Yep. LANINGHAM: Let me do it again just because you guys don't know who is going to talk first and you're trying to be polite. We started with Dave. Why don't I say this and, John, why don't you say a little something if you want to then Dave and Michael and I'll say good-bye. I'll do it again. So I want to thank you guys for spending some time with Michael and I today. This is a really interesting discussion. JOHN: Sure. It's a pleasure and it definitely was new to me doing a podcast. So looking forward to doing more of this. RHODERICK: Yes, Scott, thanks very much. It's really interesting to talk to you and talk to the podcast team. Thanks. O'CONNELL: Thanks a lot, John and Dave, we hope to talk to you again soon. Thanks guys. LANINGHAM: This has a been a developerWorks Interview with David Rhoderick, mainframe evangelist with IBM Software Group, and John Thomas, a software engineer at IBM who has been transitioning to developing on the mainframe. For more information, visit the IBM systems/eServer zone at ibm.com/developerworks. For Michael O'Connell and everyone at developerWorks, I'm Scott Laningham. Talk to you next time.