If you could hike onto the trail that leads into the HP 3000's future, you might want an experienced guide. HP's Winston Prather, the R&D manager for the Commercial Systems Division, qualifies in a way that few can match. Prather has been working with HP 3000s since he was in ninth grade, sometime before Gerald Ford left the office of the US Presidency. After putting in more than 20 years with the system, he's been in charge of HP 3000 architects and engineers during the past year, managing the progress of MPE/iX performance and connectivity. It seems a suitable stop on the performance trail of a manager who started at HP with MPE/XL 1.0, providing factory- level support on issues that often revolved around performance.
After the extensive HP announcements of late January, Prather will be the first HP 3000 technical leader since MPE/XL 1.0 to have his teams' work so closely tracked. Projects have been outlined with delivery dates more than two years into the future, setting the clock ticking on customer expectations. Prather, who came to HP in 1985 after being an HP 3000 customer, welcomes the shift toward customer needs. What's more interesting is his view that specific technologies aren't at the heart of solutions. The best choice, it seems, is the one that solves the problem most efficiently. Buzzwords like 64-bits and Merced might be high on analysts' lists, but they need to prove themselves as solutions. We asked Prather to tell us what 3000 customers might be missing without all those bits in their solutions ‹ and what the CSY lab members can get excited about as they turn onto a different path from HP-UX and NT counterparts.
What's the true value of a 64-bit capable operating system for customers? Is greater than 4Gb files enough of a leap for now? Is a 64-bit MPE/iX really worth it?
Performance and addressability are the primary benefits of 64-bit technology. What's important to look at is what problems are we trying to solve and what are the different implementation options for solving them. For example, with performance, we need to continue to provide significant performance increases for the HP 3000 in both the midrange and high-end of our product lines. What options do we have? We can continue to take advantage of the PA-RISC chips that are planned for the future, we could modify MPE/iX to take complete advantage of the 64-bit hardware, or do some combination of these. All of these alternatives will meet the performance needs of our customers. We have decided that for the next three-to-five years the performance needs of our customers can be met without significant dependence on 64-bit technology.What's the downside of having a 64-bit capable operating system introduced into a product line? Are there compatibility issues?You mentioned greater than 4Gb files. This is a perfect example of how there are many implementation alternatives we could choose. The problem is we need to have very large files. Again, we investigated a number of alternative methods to address this problem, including using the 64-bitness of the PA-8000 processor. We decided that the best solution was one that could be available to ALL HP 3000 MPE/iX customers, regardless of the specific hardware they are using, and therefore not a 64-bit technology solution.
Both of these cases demonstrate my attitude towards technology. It's an implementation choice, a means to the end, not the solution in itself. We need to keep reminding our selves to focus on solutions to problems, not technology for the sake of technology.
Yes. The primary issue is managing applications that run in a mixed hardware environment. Is this application compiled for the 64-bit version of MPE/iX or the 32-bit version? Backward compatibility becomes an issue.How did HP resolve these compatibility issues when moving from 16 to 32-bits while creating MPE XL?
There is one very significant difference between when we moved our installed base from 16 to 32 bits and our current situation. The MPE/V Classic HP 3000 architecture was out of gas. We needed a new architecture that could provide the performance levels required by our customers. The Classic MPE/V hardware and software could not meet the needs of our customers.Could the same approach work in a 32 to 64-bit migration?So, to answer your question, how did we solve this problem? We really didn't. We required our customers to upgrade their hardware to the new architecture to take advantage of the new performance levels and functionality. We did however, put a substantial effort into making our customers 16-bit development work forward compatible in the 32-bit world and provided as much as possible data compatibility in both directions. I think this level of software investment protection is unequalled in the industry, and we are very proud of this.
Again, our current situation is that we have significant performance and functionality potential in PA-RISC. We have shared the next 3-5 year plans for the PA- 8000, 8200, 8500 and beyond with our customers. We don't want to force our customers to replace their hardware and applications to obtain new functionality unless it is the only option.
Of course. Again, customers should not be forced to buy new hardware and be required to manage compatibility unless there is significant benefit.As technical leader of the HP 3000 division, do you personally wish that your engineers had an opportunity to design for the latest chip? Why?
I'm building an organization of engineers that are technologists but have a strong ability to blend their technical skills with a very customer-focused mindset. What excites our engineers is the opportunity to closely interact with the actual customers that will benefit from the technical implementations of solutions, not the individual technologies. So, do I wish they were designing for the latest chip? It's not really relevant.HP talks a lot now about how it's stopped being technology-centric. How does that change the work at the lab level?Now that HP has announced that 64-bit computing won't be available for HP 3000s, how will you retain the engineers who want to follow the latest technology? In general, what kinds of steps can you take to attract and retain the experience that has made CSY such a technical success?
First, I've got to correct your assumption that 64-bit computing won't be available on the HP 3000. What we have decided is to selectively use the 64-bit features of the PA- 8000 as we determine it to be the best solution to specific customer needs. One project that has investigated this possibility is the greater than 4Gb file component of the Vertical Growth Solution Team. Their recommendation was not to use 64-bitness as the solution because this would limit the solution availability to customers with 64-bit hardware. Other solution teams and components will obviously consider 64-bit functionality as a way to solve future problems.
Now, how do we retain the top talent in HP for CSY? By providing challenging opportunities to enhance their careers. As I said earlier, the ability to interact directly with customers, to be able to translate customers frustrations, complaints and compliments into product development plans, and then implement the solutions using a wide variety of technologies are very desirable skills. CSY is the one organization within Hewlett-Packard that provides this opportunity. Although the rest of the company is catching on quick.
Let's not forget, we've got some very exciting technologies that we are currently investigating and/or implementing such as 100-megabit networks, Fibre Channel peripherals and Java. There is all sorts of cool stuff in the works.
I'm really glad that you pointed out the success that CSY has had over the years. The HP 3000 community -- HP CSY, customers, third-party solution providers, and even the press -- really is very special. All of this focused around the most reliable, robust, commercial transaction processing machine ever created. But I guess I'm somewhat biased.
Again, it all centers around customer focused R&D. This basically means that customers are involved throughout the entire product creation process. I think I can best describe what I'm talking about with a story an engineer told me a year or so ago. This engineer had some incredibly fantastic ideas of how to make product ZXY bigger, better, faster, etc. They were working with a number of customer partners through our solution team process. The engineer presented his ideas to the customers and they said, "These are very interesting features, but I would never use them!, but if you really want to make my life easier give me a feature that allows me to..."Is IMAGE/SQL always going to need Allbase/SQL components? If enough customers asked for an alternative, is it possible to design a native SQL interface for TurboIMAGE?This engineer's approach to solving problems will never be the same. This is what customer focused R&D is all about. Listen to your customers, watch how they use our products, involve them throughout the entire development life cycle. If you can do this, when you ship a product it will meet customer needs. And guess what, they will be willing to pay for it!
At the moment, we haven't found many customers that have asked for us to design a native SQL interface to TurboIMAGE. Of course I would want to ask what problem are we trying to solve, and is this the best way to solve it? If the answers are yes then I would want to ask one of our solution teams to take a look at this and compare its priority with other solution components.What's the future for clustering HP 3000s? It appears that will be the alternative for customers who need more performance than a multiprocessor HP 3000 can provide. What changes to you expect from the Horizontal Growth solutions team's attention to Shareplex/Netbase?
I think you will start to see more customers adopting a horizontal application topology. Primarily because it provides flexibility in handling rapid growth in processing requirements, not to mention disaster recovery.There's a lot of attention on the new processor projects in HP, but performance is a product of many subsystems. What other areas are likely candidates for improvement on HP 3000s?The Horizontal Growth Solution Team is focused on two areas. First, education on how to take advantage of the Shareplex technology. Many customers don't understand the benefits of the product and how far the product has evolved in recent years. Secondly, the team will look for ways to increase the solution effectiveness. For example, one thing that has come from this solution team is the increase in the number of FDDI cards that we can support on the HP 3000. The team determined that increasing this limit would provide increased flexibility with Shareplex implementations, so that enhancement was funded.
Performance is an area where we always have ongoing investigations. Currently we are looking into areas such as decreased file lock contention, memory manager scalability for greater than 8-way multiprocessing, reducing the impact of transaction management checkpoints, TurboIMAGE scalability and improvements to directory services. We are also investigating compiler changes that would allow greater exploitation of the PA-8000 processors.Some customers talk of integrating MPE and HP-UX at some point in the future. How do you feel about that kind of integration?
If you change the word integration to interoperability then I think it's very important. Customers need to be able to deploy applications for both MPE/iX and HP-UX in the same shop. I think the best solution here is for us to continue to focus on our supplement segment activities. Interoperability seems like the best answer, not a blending of MPE/iX and HP-UX.