Steve Will Discusses IBM i Architecture
Steve Will, chief architect for IBM i, on the good and the bad of writing a program in 1979 and being able to run it on today's system without recompilation.
By Paul Tuohy12/05/2017
Paul Tuohy: Hi everyone. Welcome to another iTalk with Tuohy. I'm joined today by our chief architect, Steve Will. Hello, Steve.
Steve Will: Hello, Paul.
Paul: So we've had a few iTalks now in the past.
Steve: Yes, indeed.
Paul: Too far apart, usually.
Paul: They’ve been too far apart, we’ve talked about many things, but today what I want to talk to you about, and it's going to be strange. I want to talk to you about architecture.
Steve: Oh, chief architect. Architecture. That sounds like a good topic. [Laughs]
Paul: Yeah, it's about time we got around to this. So yeah. Well I think this stemmed―I wanted to talk to you because you've started doing a session now on this about the architecture.
Paul: And I know when I saw it first of all, I saw it mentioned in one of the agendas and I sort of went, "well that's a bit strange, like everybody knows the architecture. Why is he talking about it?" So why are you talking about the architecture?
Steve: Well I go to lots of different customer events and usually when I do, I have the opportunity to briefly mention the core parts of the architecture that have been around for a long time. Now if I'm just talking to a client executive, they just need to know why we have that architecture, but when I do in front of a user group, people who've been around this platform for a long time, I'll often get stopped by some wise acre in the audience who will say, "well the IBM i architecture is just the System/38 architecture." While I understand that―there are certainly core elements that are still there architecturally―we have had to evolve the architecture of this machine throughout the course of the last 30 years in order to continue to be the kind of business platform we are today. And I think people tend to forget that the things they take for granted today haven't always been in the machine, and so I want to describe to them how much more powerful IBM i is because we have advanced that architecture, and how much more we can do. Because when people think of us as just what the AS/400 was in 1988 or just what the System/38 was when it first came out, they are not giving us as much credit for the things we can do today. They don't really realize that to do that we actually had to change the architecture of the platform significantly.
Paul: Okay so let's start. I mean okay because I'm one of those. I'm probably one the wise acres at the thing so I've been with platform since System/38 and before―since before―okay, I'm old.[Laughs] So before '79, I mean I've been working on―I worked on the 38 when it first came out and seen it all the way through. I know that the concepts of things like single level storage and the integrated operating system we have with the database and everything like that―that that was―I mean there is this thing that other platforms are still talking about wanting to do―
Paul: And we've had it since '79, I think―very proud of that and I think it's a great, great thing. But you're right. As we were talking about this beforehand―and I think you saw the expression on my face as I was going, "oh yeah, oh yeah." Okay so what is different from the AS/400 or that 38, that original architecture? So you say "oh, it's developed." So how? I mean, what are the things?
Steve: Well of course I'm not going to give the whole presentation, but let me talk about a couple of things. People, for example, don't recognize that when V1R1 of AS/400 came out with its single level store, we didn't have to deal at that point with languages that had pointers as part of the language. So RPG and COBOL were there―and of course within the language, in the complied version, they dealt with pointers―but those were not things users had access to. And so while single level store was nicely protected if you were going through compilers, once we had a language like C where pointer arithmetic is core to the language, we now had to protect single level store differently than we ever had to before. Now users are doing pointer operations. And so from V1R2, we had to invent the security level 50 and being able to do hardware storage protection. So already from the very beginning we aren't the same single level store that we were and we are not the same protection we were before. That's just sort of the first big example. Very importantly, as applications wanted to do different things from the original monolithic applications, but we didn't have some of the things that new applications absolutely depend upon. So the three big things that I talk about in my presentation―they certainly aren't the only things―but the three big things I talk about are IFS, a hierarchical file system. QSYS.lib is there and it's still important and we use it a lot, but applications in general these days assume you're going to have a hierarchical file system. That never existed on the original AS/400. Could you imagine if we were still trying to survive as a platform and we didn't have that? You couldn't move any kind of application or write today's modern applications. Then the next thing was threading. We didn't have anything like threading. That's exactly what all the UNIX’s were using and POSIX standards were being created around the idea of doing threading and languages were assuming that there were threads. So you've got to have threading. Then once you start doing those kinds of applications in those languages, well those users they started thinking well I have as much unlimited temporary storage as possible. Well not in single level store, you don't. So we had to, you know, create a capability for people to have that kind of language application. So we had to do teraspace so that they could assume they had space that they didn't really have. So these kinds of advancements didn't exist in the original AS/400. We had to evolve the application―or evolve the infrastructure―and during that course of time, we had to entirely rewrite portions of the operating system to make it happen. Architecturally it sort of looked above the MI like things didn't change, but they really did.
Paul: Yeah, it's―yeah. It's like, when you've been talking about these things―and I think part of the problem for those of us who have been on the platform all the time is that all of these things have just sort of seeped in. It will come out in release. So it's announced, we go "oh yeah, that's interesting," and when you find yourself now, you just assume they've been there all the time.
Paul: But actually when you were talking about the IFS, I remember that excitement on 3.1 when the IFS came out because before that, we just had shared folders―
Paul: Which of course was a shell game but that was really library and objects underneath the covers. It was just using the standard thing and the true hierarchical file system coming in with the IFS so then how much of the code―of the actual original AS/400, I mean―how much of it is still there?
Steve: Well you know I was thinking about this. I―maybe, maybe the operating system has 5-10 percent of the original code still there but the―let me take you through a couple of key points in our development. When we shifted from the CISC processor that we had to the VT/RS7 RISC implementation that we did, the entire lowest level of the operating system everything below the MI had to be thrown out and rewritten so that we could sit on top of the platform, the new platform: the new RISC platform. I mean that's 40 percent of the architecture right there that had to be reimplemented in a new language so that we could do that. And that's just below the MI. Above the MI, because we had to implement things like threading and so on, we had to change that. Plus the operating system now could take advantage of threading. So you can't start with something written in a PL language which didn't have threading and take advantage of threading. Now that we've got things like applications―like Domino that run on top of us―or web serving. Web serving has to have threads all the time. We had to rewrite so much of that. So like I said: maybe 5, maybe 10 percent of what was originally in V1R1 might still be running on this platform, but by and large it's been rewritten. Sure, the base architecture―object based, single level store―that architecture is still there, but it had to be advanced and enhanced in order to be able to do the kinds of things applications do today.
Paul: Yeah. I'm now getting scared. [Laughs] I'm sitting here going, "this isn't my system anymore."
Steve: Oh, no. No. It's still the system and it's exactly what you're saying. You know, we enhance, people got excited about these new capabilities but by and large, with a few minor bumps in the road, we didn't cause disruption. That's why people think, "oh, it hasn't changed since then." It's so important to our architecture and our marketplace that we not cause disruption. I became chief architect of this platform the year before the 6.1 release―so the year before we came―we became IBM i. At that point, we were developing the retranslation that was doing to happen in 6.1. Again, a whole set of architectural changes we did to improve the performance of ILE, to improve the performance of teraspace to improve the integrity of single level store within the operating system, and all of those things happened at the time we became IBM i: meaning, there was never an AS/400, there was never an iSeries, there was never a System i that had these new architectural elements to them. And yet, people these days assume they've always been there. That's great that people see us as an evolving platform, but it's important to recognize that we continue to look at what the next thing is we're going to have to do: Advance the architecture without causing disruption.
Paul: So the other thing interesting that we talking about―so now like the tools that you're using to develop the operating system, so that―I mean the old PL. I remem―I've never seen it, okay. I never want to see it―
Steve: You're right.
Paul: With that but honestly I always remember that that there was this great arcane thing that people worked on, but now they're doing like what? C? Java?
Steve: They're doing C, C++ and Java, most of the operating system these days. Below the MI, it's almost all C and C++ being used. We use Rational tools, just like we tell our customers to use, and then above the MI, it's often C, C++ and Java that we use to develop things that are above the MI layer. So yeah, there may still be some PL sitting there somewhere that people have to maintain and enhance every once in a while.
Paul: So has the integration of sort of that AIX in there, our Q shell and all of that, has that had a big influence in any way with all that goes on?
Steve: Oh, absolutely. The move to incorporating an AIX environment within IBM i―PASE, we all know it as PASE―has allowed us to bring in pretty much every open source technology that we've put on the platform outside of Apache. Apache runs outside of PASE, but everything else is within PASE. That architecture was a huge change to be able to put alongside the MI, to put alongside above MI part of the operating system. Yet again, everybody assumes it's there. It's all part of that same architecture with single level store. Surely we found a way to integrate that, but again without that, we couldn't do most of the modern applications that are bringing new developers onto the platform, new application types onto the platform.
Paul: Yeah, it is one of the things that I've been finding fascinating recently is that when I've been―because again I―I'm sorry. You work at a level that I don't understand. Okay so when I look at it from above here and I'm seeing things that I know are PASE, I'm sort of going like, that has to be using all of that UNIX stuff that's in there but it is somewhat integrated with the i/OS side of it―
Steve: Right. Exactly.
Paul: That's there and the way that connectivity works, I just find that fascinating. It's a good thing.
Steve: It is. It's a very good thing and it's one of those things that people―I think should appreciate about the fact that we didn't stay our own unique platform, but we converged with UNIX. You know we got a tremendous benefit from being on a POWER processor that can run i with our tag pointers, doing AS/400 stuff, okay―but that same processor can run UNIX and we found a way to integrate those two things together so you didn't have to worry about it or you didn't have to actually have two different platforms to gain that benefit.
Paul: Yeah and also that other people have taken it so far―Zend, for example, with their PHP server and the way they do the same.
Paul: The integration between the two.
Steve: Yes, and one of the biggest applications on our platform is SAP. The SAP set is written in Java, which is all implemented in PASE. So we continue to have a great SAP platform because we have that.
Paul: Yeah, and of course on that integrate―yeah. Yes.
Paul: It's―okay. Now I'm getting [unintelligible] [Laughs]
Paul: So you mentioned―so you think the three biggest things: the IFS, the multithreading and terraspace.
Steve: Terraspace. Yeah.
Paul: And they were the big game changers.
Steve: They were, yes. Without those, we couldn't do what are modern applications. Then if you went to the fourth one, if we didn't do PASE, we would no way to get all this new open source on affordably, and that's critical. We need to spend our resources―for example, getting the next database enhancement that is going to help everybody in their IT shop. We couldn't afford to do that if we were also having to port all of this open source stuff directly to the original architecture of the platform. PASE allows us to bring it over very easily. We can spend our resources doing what we do best, things like Db2 and security.
Paul: Yeah. That's interesting you say that then because isn't that an extra complexity, because of the fact that the operating system is this integrated operating system, that part of your concern has to be as you do all of this stuff, you've got the databases sitting in there as well as part of your OS.
Steve: Indeed, and so we when we look for open source that we want to bring to the platform, our key architectural elements that we have to make sure get connected and integrated are our database access, because we don't ever want it to look like our database is something extra, something you have to work to connect to open source and our security model. We need to make sure that people can be sure that even when they're using a new kind of language that may have come from a UNIX environment, they can still get the benefit of the security model that has always protected our customers.
Paul: Yeah. I want to come back to this thing, the longevity, because what we are talking about here when we're saying about this view that we have that you know, everything was just there all the time. Because of course you guys have done such a good job on sort of keeping everybody being able to move forward―
Paul: So it's the thing that I've always described as being the great thing about the system is that as all of these new things come in, your software just keeps running.
Paul: Okay and apart from the 3.0―maybe at 3.1 and maybe at 6.1―we might have had to recompile our programs, I think what a lot of people don't understand is that on other platforms like UNIX, this is a fairly standard thing.
Paul: You're going up a grade on your operating system. Recompile everything.
Paul: You have to okay, but you would have seen the uproar at 6.1 from some of the customers going, "What? Recompile?" [Laughs]
Steve: Indeed. What?
Paul: Okay with that, I mean I tell people I have a System/38 library that I wrote in 19―a little program I wrote in 1979 that runs on a system today with no recompilation.
Paul: Okay with that and people say "wow, that's great," but unfortunately, isn't that also the curse of the system?
Steve: Oh, yes. It's what people called the double edged sword, right? Because if people know that they can continue to carry those old―but probably valuable―resources forward without doing recompiling, then they have this tendency to get a little lackadaisical about whether they're going to enhance things. That does somewhat affect the perception of the platform. If they can run old stuff, it can be perceived as being old. So we try to point out both that "yes, you can run those things that have been compiled 30 years ago and never recompiled, but if you recompile and advance, there are so many more opportunities for you to add value to your business, to your application." That's what we want to make sure people don't lose sight of. Yes, you can use that core architecture that always existed, but we've advanced beyond that and you ought to look at taking advantage of those.
Paul: I think you should start putting things in the operating system that make the old stuff start to run badly, slowly, indirect bugs going in. Just a little suggestion.
Steve: Okay, well, I appreciate it.
Paul: Okay so just before we go, what's the latest game you've been getting into?
Steve: Well I am really excited these days about playing the new Nintendo Zelda game with my wife, that's really fun. But on my free time with my friends, we've been playing a game called Dominion, which is a card based strategy game, and it's super fun to play. And then there's this cooperative game called Forbidden Desert, where we call work together to try and make sure that we can all survive because we've been stranded in the desert. I really like that because I love cooperative games. I love working with people to accomplish the end result of survival or something. So yup, that's what I've been doing recently.
Paul: Okay so Steve, thanks for taking the time to talk to us.
Steve: You bet. Always good.
Paul: That's it for this iTalk, everyone. Tune in again for the next one. Bye for now.