As 1999 winded down to a happily hush-hush close, I had the opportunity to talk to former AS/400 General Manager Tom Jarosh, who, in the wake of the January PartnerWorld Business Partner tradeshow, became the general manager of IBM's new Mid-Market Server Division of the revamped Enterprise Systems Group. (See my Decision Support analysis piece on page 39 for more on that reorganization.) Obviously, Jarosh, like other AS/400 managers, can't divulge everything that is cooking in the Rochester Labs or the marketing plans being generated in Somers, New York. But he is interested in making a strong case for the AS/400 as the premiere midrange platform, and that is not going to change just because his title doesn't say "AS/400" anymore. I think this interview bears that out. (This article is an excerpt from a longer interview with Jarosh. It can be found in its entirety at www. midrangecomputing.com/mc/.)
Tim Prickett Morgan (TPM): Let's start with the number one thing on AS/400 customers' minds. Can you give me a sense of the processor road map going forward from here? Can you clarify what is going to happen over the next couple of years and give AS/400 customers a sense of what is coming down the pike?
Tom Jarosh (TJ): Well, I won't go very far. We have said that our next line of AS/400s, the next time we introduce some performance and price/performance into the line, will come with the introduction of the I-Star chipset family of PowerPC products. We have also said that this will most likely happen in the second half of 2000.
TPM: I've heard from Frank Soltis and a number of other IBMers that the plans were, originally, to have a 560 MHz chip followed by an 800 MHz chip.
TJ: That's not true.
TPM: Can you give us a sense of where the speeds are going to be?
TJ: No, I prefer, at this time, not to. We’re still doing testing and working on performance optimization, and I prefer not to go into the specifics. There will be quite a substantial improvement in megahertz as we go on in time.
TPM: I know that the Pulsar chip that the RS/6000 group is using is a pretty sophisticated chip—a lot more functionality like memory controller circuitry got embedded in the chip, and it has a lot more Level 2 cache memory. Is that the kind of design philosophy you’re taking with I-Star as well?
TJ: Yes. We are using a whole lot of new silicon—some of it on the I-Star chip, some of it in new memory and I/O controller silicon as well.
TPM: And beyond that, are we still on track to get to Power4 chips after I-Star?
TJ: Yes. But we may put in an incremental increase in processor speed before we get to Power4.
TPM: I’ve been told that we can expect Power4 by late 2001 or early 2002 and, depending on the needs of the market, possibly late 2002. That’s an awfully big window, but is that a fair assessment of when Power4 will come out?
TJ: Those are the rough, general time frames.
TPM: Can you give us a sense of how you will differentiate the very large AS/400s in the 7XX line and the smaller machines in the Model 170 Invader class? In other words, will there be a single I-Star line and a single Power4 line, or will you use some of the older chips in the low-end AS/400 models where you probably don’t need so much megahertz?
TJ: We’re looking at the alternatives available to us from a performance point of view and a cost point of view, and you can count on us having improvements across the entire product line as we always do. We will have a full product line, and there will be improvements from top to bottom.
TPM: For the SMP machines in the Apache and Northstar line, the AS/400s and the RS/6000s have been kept roughly in track. Is that your intent going forward? The Pulsar represents the first time there wasn’t an AS/400 version when a PowerPC SMP machine was announced. Will the AS/400s not keep in synch with the RS/6000s from here on out?
TJ: No. We won’t lag. At different times, AIX and OS/400 will enable different processors based upon those unique markets and holes in those markets. We do share a lot of technology. I wouldn’t say that there is any built-in lag by design. It’s just who is ready for what thing at what time. They ended up taking advantage of Pulsar technology, and we will end up taking advantage of I-Star technology. It depends on the different development efforts. You can count on us to relatively keep up with each other.
TPM: I’m assuming that the I-Star is the first silicon-on-insulator server, and it looks like the AS/400 will get it first. IBM has said that it will have an SOI-based chip this year. The RS/6000 people have said that they will use a crank on the copper-based Pulsar, and the S/390 people are working on Freeway processors, which are just copper-based, so that leaves you.
TJ: Yes, that’s true. AS/400 will be the first, and we’re pretty proud of that, too.
TPM: No matter what clock speed you get I-Star running at, it looks like these are going to be very, very fast machines. These are going to be very large machines. Certainly the I-Star is the kind of box that will engender an application service provider (ASP) market, and I think that there is the possibility of a very attractive offering using AS/400s as ASPs just because of the ease of use and scalability that we all know the mantras about when it comes to the AS/400.
TJ: You can expect us to capitalize on that opportunity.
TPM: I think that there are going to be a fair number of customers who, having lived through their Y2K nightmares, are going to say, "You know what? I think I’d rather pay $250 per seat per year, provided I can get the network bandwidth to link to an ASP." It may not happen in 2000, but it certainly could happen the following year.
TJ: That’s why we’re investing right now for the AS/400 in the ASP space, and we’ve already seen some success, actually.
TPM: I know IBM has made a number of broad ASP announcements in late 1999, but what is the plan for the AS/400? Are you going to take Business Partners who currently try to sell AS/400 hardware and try to get them to become ASPs for J.D. Edwards, Lawson, and so forth?
TJ: There’s actually two models that are developing. One is truly an application provider deciding to get into the ASP business as a dedicated operation, either that they run or that they outsource. And the second model is a wholesale ASP that really is more focused on building an infrastructure and running multiple ISVs’ application software. We actually have both varieties signed up. We’ve got an ASP center of excellence set up in Rochester, and we have a worldwide ASP market development team in place to develop that market opportunity. And we are putting into place dedicated sales resources that will only be compensated on their success in the ASP space. We are attacking it, and we expect it to be a contributor in 2000. But you’re probably right. It will likely be a much bigger contributor after a year of getting that market going.
TPM: I’m not even sure what the best metrics would be, but do you have any sense of the potential number of seats that we are talking about in the ASP base?
TJ: We’re just getting started with that analysis now. The concept has got to get proven. There’s some early adopters out there who are proving it.
TPM: What advantages do the AS/400 and OS/400 bring to the table compared with, say, using Solaris or AIX?
TJ: What’s made the AS/400 the success that it has been historically and continues to be is the fact that it is the best application server in the industry. This has been driven predominantly by its reliability and stability characteristics, along with the ability to add huge amounts of capacity without having to change anything in the underlying machine. These characteristics become all the more important when you are leveraging through an ASP model where one company has to make the decision on a platform and then they just sell network access to that platform. All of a sudden, those characteristics rise to the surface. So I think that this is the reason we are going to see lots of success in the ASP space.
TPM: Are you going to offer capacity-on-demand capability for AS/400s like Sun Microsystems and Hewlett-Packard are offering? It seems to me that capacity on demand
goes hand in hand with the ASP model because of the rapid growth that companies will experience.
TJ: Right now, we are working on individual customer terms and conditions to make sure that we have the right set of offerings, but clearly that will include capacity-on-demand types of offerings. We are doing it company-by-company, but, once we gain some experience with exactly what the ASP market is looking for, we will formalize these offerings into terms and conditions.
TPM: Will regular AS/400 customers be able to get capacity on demand, or is that something they are not yet asking for?
TJ: We don’t really have too [many] requests for capacity on demand. We can turn around the need for more capacity pretty quickly through our manufacturing sites. This is not something that has bothered a lot of customers.
TPM: Yes, but with that quick-ship upgrade, you still have to re-IPL the system and apply patches. If I were running a complicated site, I might prefer to have extra engines in the machine from the get-go. And then, as with the Sun and HP capacity-on-demand offerings, when I need more power, I download a key over the Internet to turn the capacity on, it kicks out an invoice, and I pay it.
TJ: No, we don’t have that. I don’t have a lot of end-user customer demand for that. It hasn’t been an issue for our customers, and, if it was, we’d solve the problem.
TPM: Jumping to another area, let’s talk about Java. The main problem I see with Java is that it is so open. So you get the AS/400 base to start using Java. How are you going to keep them on the AS/400 as opposed to another platform? Once they are in Java using open calls to databases, they can move to any box that supports Java.
TJ: They can, and that says that the AS/400 has to be successful on its own merits as opposed to being successful because that is the only place that RPG runs. And I have no problem competing in that regard. And to a large extent, that is the market we compete in now with packaged applications, and the same argument holds true. When J.D. Edwards or SAP run on UNIX, NT, and AS/400, how are you going to keep them on the AS/400? We’ve grown in this marketplace in spite of that. The same logic holds true for the Java environment. The AS/400, as a platform, given its characteristics and value proposition, will stand on its own as opposed to being in a non-open, proprietary situation where customers don’t have a choice.
TPM: I’ve heard from Intentia International that they have not only reached parity with Java NextGen and RPG ThisGen ERP suite, but that they are hoping that, when they finish tuning the software in the first quarter, thanks to IBM’s help, they will get the Java NextGen implementation of the suite running with lower response times and higher throughput on the same iron. This is a tipping point, I think, for Java.
TJ: We’re very happy with all the work that Intentia has done. The company has really been a leader in Java implementation
TPM: Will there be a time when you will add Java-specific instructions to the AS/400 chips to try to give the AS/400 a boost when it comes to Java performance?
TJ: No.
TPM: Do you have any sense of how many of the 1,000 Shark shipments IBM has made were on the AS/400?
TJ: Relatively few. It’s not something that we push very aggressively. We’re looking forward to Fibre attachment of that later on [Author’s note: This means Fibre Channel attachment, not using fiber optic wires, which the AS/400 has been using for years.], and, again, there is not a huge demand for it. As we get into the environment in later releases of having switchable address spaces and really having switchable disks be more viable on the AS/400, it will play a larger role.
TPM: What is switchable address spaces? I don’t quite understand that.
TJ: The ability to manage single-level store within a cluster of redundant, backupable environments. It is one of the technologies that we are working on.
TPM: If single-level store is one address space for main memory and disks, obviously you can’t have two AS/400s arguing over which controls that address space.
TJ: Right. But if you had a failure situation, you would want to make sure that you had all that information available.
TPM: Is that a V4R5 release, or is that farther out?
TJ: We haven’t said anything in the marketplace about any release numbers, Tim.
TPM: I know that. I’ve been told it could be either V4R5 or V5R1.
TJ: It will be in a future release, and we haven’t made any announcements.
TPM: I’m kind of curious if you are ever going to, for lack of a better way of saying it, take a more-direct sales approach with the AS/400 line.
TJ: We are going to focus some more of our attention on Web or tele-Web sales. This will not at all impact sales in the channel. We’re not moving away from Business Partners at all as the primary means of selling. In fact, to a large extent, what we’re trying to do as a first step is to make the relatively simple feature addition to the AS/400 processor—low dollar items like adding memory, disk, or other adapter cards—more user-friendly and implementable over the Shop IBM site; take what is, to some extent, a nonproductive set of sales activities away from our own reps as well as those of Business Partner reps and have them focus on more sales activities where they are really required.
TPM: Forgive me for not knowing, but do you push whole AS/400s through that channel, which used to be called IBM Direct, or what you are now calling Shop IBM?
TJ: You can buy AS/400s over Shop IBM, entire systems if you want, now.
TPM: Do people do that? I suspect that they don’t.
TJ: Not too much. We’ve got the Dedicated Server for Domino fairly prominently displayed. We’re working on some more easy-to-use configurators. One of the things we’ve got to get through is making sure we’ve got good configuration capability in that environment, given the fact that the AS/400 is still a configurable box. So we’re working on it. You should not expect to see any major, major shift in distribution strategies in 2000 or 2001.
TPM: About this time last year, IBM was talking about a native Apache Web server for the AS/400. I haven’t seen it out on the www.apache.org site, and I’m wondering what ever happened to it.
TJ: There is a version of the Apache Web server that is available that was generated by our custom technology group. It is not the final product that we will have integrated into WebSphere. But we do have development efforts underway to integrate the Apache Web server into the WebSphere offering.
TPM: Is that in a future OS/400 release, too?
TJ: Yes, it is.
TPM: When IBM first announced that it would be supporting Apache, we were told that, over time, the Apache Web server, once tweaked to support the different platforms within WebSphere, would become the default Web server for IBM. Is that still true, or are you going to let customers choose between Apache and Domino Go and HTTP Server for AS/400?
TJ: We’re still working through that. We rarely leave our customers hanging high and dry, but, certainly, one of the issues that we have to deal with is transitions in those environments, protection of customers’ investments, and so forth.
TPM: You can’t really talk about Apache without talking about Linux. They seem to be married. IBM’s S/390 mainframe group is putting Linux on mainframes. RS/6000s have Linux support, and Netfinities have it by default. Can we expect to see some kind of native AS/400 Linux support either through the Integrated Netfinity Server or running in OS/400 logical partitions or through adding Linux application programming interfaces and binary support within OS/400? Is there a compelling need to do this? Are AS/400 customers asking for it?
TJ: The answer is, people are not asking for it and there is not, at this point, a compelling reason to do it. Our approach with the AS/400 is to interoperate with peer Linux servers and to support Linux clients. That’s the path that we are on. If we were to do the next step, you might see Linux on the Integrated Netfinity Server, but we have no current plans to do that. We are going to continue to listen to our customers to decide what the right thing to do is in that regard. And we don’t have any product efforts—maybe a little advanced tech work—on providing Linux within a partition or anything like that kind of capability. It is just not something that there is a lot of demand for. You have to ask yourself, "What is the incremental value?" You could put together an argument that says, "They have the ability to run UNIX runtimes on the AS/400, and it does provide incremental value if it gets you some application content that you couldn’t get to run natively on the AS/400."
TPM: In the case of Linux, the AS/400 has more applications available (with the exception of the Apache Web server and the Sendmail email messaging server), and no one wants to run Linux workstation applications on an AS/400 anyway.
TJ: Exactly. So, for Linux, you are not getting incremental applications over and above what you either have or what you could get through a UNIX interface. So what is it that you want? That’s the reason that there is not more work underway on that.
TPM: But I think that a certain number of AS/400 customers, depending on how educated they get and how courageous they are, will be interested in doing Linux on the INS. I guess that they are not prevented from running Sendmail on Linux today.
TJ: That will be particularly true when we have more-powerful Integrated Netfinity Servers, and that is coming as well.
TPM: I’m trying to figure out if there is a way to create an open source AS/400 community.
TJ: Watch this space. You should expect to see us start down that path. We’ll start slowly, and I think it will be considered to be a little of an experiment, but I think it will be healthy for us.
LATEST COMMENTS
MC Press Online