Compaq and HP engaged in vicious FUD battle

A REMARKABLE DOCUMENT which appears to show that field sales staff at Hewlett "Carly" Packard are using the shotgun wedding with the Compaq "Curly" Corporation to sell more of their kit and gain more commission.

And the following document is circulating amount Q sales staff to counter the HP fud.

Heads will have to roll over this one, which is so astounding that we can hardly believe it's true. But it is... µ

Introduction
Ever since the proposed HP/Compaq merger was announced, Compaq field people and partners have encountered a considerable amount of FUD from the Hewlett-Packard field. This FUD involves everything from "Alpha is a dead-end platform," to "HP-UX will be the surviving UNIX," to "no porting will be needed for HP-UX customers." This document identifies many of the more common FUD points HP is using and provides you with ideas to counter the FUD.

1. Customers do not need to recompile HP-UX applications to go to IPF.

RESPONSE: The current shipping version of HP-UX is HP-UX 11i, version 1.5. It has a full 64-bit kernel that supports 64-bit applications and also runs 32-bit binaries transparently. As part of HP-UX 11i, there is a binary translator — code named "Aries" — that translates PA-RISC instructions dynamically into Itanium instructions during runtime (see: unix-cds.zk3.dec.com/k/4175/4175.pdf for details). We feel HP will continue to offer this binary translator when the new merged (HP-UX and Tru64) UNIX comes out. It is for that reason only that HP can claim there is no need to recompile applications in the future.

This is a marketing claim not supported by any relevant history. Experience tells us that customers and ISVs do not accept translators as a functional answer for their critical, mainstream business applications. No ISV is going to support an application on a binary translator and no IT manager is going to deploy an enterprise application on a translator. That means the translator will mostly be used for older 32-bit applications where the source code has been long lost (see #4 below), and cases where the company does not want to invest the engineering work to make the source code compile on IPF.

2. HP-UX will be the UNIX that attracts ISV attention going forward, not Tru64. Now that Tru64 UNIX is end-of-life, ISVs will rapidly lose interest. Customers should migrate to HP-UX immediately.

RESPONSE: Tru64 is the most modern, mature 64-bit operating system in the industry. It was designed from the ground up as a 64-bit UNIX. Ten years later, that investment has paid off handsomely with Tru64 UNIX having the largest, most stable portfolio of 64-bit optimized ISV applications in the industry. Because these applications have already been tuned and optimized for 64-bit environments, Tru64 UNIX versions of these applications will cleanly recompile to run on IPF and deliver the best performance with the least effort for the ISVs. HP has a hodgepodge of mainly 32-bit applications that would require significant engineering work to bring up to 64bits and then to IPF. HP desperately needs a translator for those applications. Moving to IPF without a translator will be a major transition for most current HP-UX applications.

3. HP provides the smoothest migration path to IPF. In fact, HP-UX is running on IPF today; Tru64 is not.

RESPONSE: This is a half-truth. HP-UX is running on IPF today and Tru64 UNIX is not. But customers are not buying IPF systems today to run their enterprise applications. HP-UX on IPF is a first generation platform that is clearly not mature enough to handle mission critical applications. Compilers and applications need more time to mature as well. Only early adopters, such as ISVs, are purchasing these systems today. When HP-UX on IPF is finally ready to be deployed in the 2004-2006 timeframe, HP-UX and Tru64 UNIX will have been merged and over 10,000 native ISV applications will be available on the merged operating system.

When the time is right, the ease or difficulty of transitioning from a 64-bit HP-UX application to the combined UNIX product, or from a Tru64 application to the combined product will be virtually identical because most 64-bit applications will need only a simple recompile (see #4 below). But there are few 64-bit HP-UX applications today. Most of the HP-UX portfolio is still 32-bit and those applications will encounter much more difficulty in moving to a native IPF environment. This makes HP-UX the more difficult path to IPF for ISVs and end-users, not Tru64 UNIX.

4. "Customers will encounter a number of difficult migrations to go from Tru64 UNIX to HP-UX in the future. However, there is no migration needed for HP customers. All current HP-UX applications will run unchanged on IPF today, and on the new combined UNIX in the future."

RESPONSE: This is simply not true. HP is making the claim of ease based on the fact that they have a binary translator that will take a PA-RISC binary and run it on IPF without recompilation. But as we said earlier, the translator answer is a red herring. We know because we tried the translator route ourselves years ago with FX!32 (see: http://www.research.compaq.com/wrl/DECarchives/DTJ/DTJP00/). Customers demand natively compiled applications that are fully supported by ISVs. We have said this is a marketing answer. Let's look closely at a number of scenarios to see how this HP claim simply does not apply to true enterprise applications:

a. Customer has old PA-RISC binary, but can't locate the source code.

This is a perfect candidate for HP's binary translator. The timing may not be right to replace the old application, so running the binary on a newer industry-standard IPF system may make good business sense to some customers. That eliminates the need for the customer to retain a PA-RISC system solely for one old application. (Remember that Tru64 applications don't suffer from the legacy 32-bit syndrome, and therefore this would not be an issue.)

b. Customer uses a major application, such as SAP or PeopleSoft, and wants to switch to IPF.

With the combined market shares of HP-UX and Tru64 UNIX, HP will have the second largest selling UNIX with a substantial installed base. This will be very attractive to ISVs and virtually all current Tru64 and HP-UX ISVs will choose to move their applications to the new UNIX. But none of them will choose the binary translator route because of product support and stability issues. Every ISV will go through a full porting and recertification effort. It will certainly be worth the effort because the application will then be able to take advantage of the architectural features within the Intel IPF architecture, such as predication and speculation.

Because all Tru64 applications have been 64 bits from day one and are the most mature, 64-bit optimized applications in the industry, most ISVs will be recompiling their Tru64 application binaries

for the new combined UNIX, not their 32-bit HP-UX binaries. The newer 64-bit Tru64 UNIX source code should compile much cleaner on IPF and deliver a much better final product with less effort than 32-bit HP-UX code. When the customer is ready to make the move to IPF, it simply will be a matter of contacting the appropriate ISVs and making the licensing and media arrangements.

c. Customer has internally developed applications running on PA-RISC (or Alpha) and wants to deploy them on the combined UNIX on IPF.

Tools and assistance programs are being developed to ease the porting of customer applications to the combined UNIX on IPF. But the bottom line is customers will want to recompile and recertify almost all of their applications on the new architecture because it will be a major operating system release with numerous changes and enhancements. Without recompiling, the application will be running on the binary translator (for HP-UX applications) and no IT manager will trust an enterprise application running on a translator. For customers who choose not to recompile and recertify on IPF, perhaps it would be better to continue running the application on Alpha or PA-RISC.

5. "Customers should not consider purchasing Tru64 UNIX on an AlphaServer. It's a dead product. In fact, customers running AlphaServers today should migrate as soon as possible to an architecture with a longer life."

RESPONSE: This is standard FUD that all our competitors are using - not just HP. When you look at the timeline for Alpha and Tru64, the issue of "dead product" is more emotional than factual. This industry moves very rapidly, so changes are occurring all the time. Product lifetimes are shorter than they used to be. Customers need to address problems today and for the foreseeable future. Alpha and Tru64 investments are still very desirable given the capabilities of the products and the commitments we have made for supporting products well into the future. Compaq has given customers a very long product roadmap for the eventual retirement of Alpha products.

Think back to 1991 for a moment. HP controlled the emerging UNIX enterprise computing market, which was dominated by proprietary architectures such as IBM AS/400, HP3000, and DEC VAX. Convex and Cray Research dominated the technical server market and both appeared unstoppable. You could get a nice mainframe from IBM, but their UNIX servers were not worth buying. The DEC VAX line was beginning to slow as customers waited for Alpha. Sun was struggling to maintain its leadership in engineering workstations and soon decided that they needed to enter the UNIX server market to continue growing. Microsoft was servicing a small but growing market for desktop PC's, and Linux was nowhere in sight.

How things change! So at some point in the future, when AlphaServers will no longer be supported, the market will be vastly different than it is today. Which brings us to the point of this exercise. Customers should buy the best server that is available today for their applications. In most cases, that server is an AlphaServer running Tru64 UNIX and TruCluster Server. Many servers are deployed for only three to five years, but there is no need to stop buying AlphaServers and there is certainly no need to replace existing AlphaServers.

Here are some reasons to continue to select AlphaServers over HP 9000 servers:

· World-class leadership in cluster technology. When you need to scale out, TruCluster Server is the worlds premiere UNIX clustering product. HP's cluster product lags all other vendors in functionality and technological sophistication. MC/ServiceGuard is based on old, obsolete technology with no plans to be updated.

· The combination of TruCluster Server and the AlphaServer GS was ranked BEST IN CLASS for reliability, availability and serviceability (RAS) by D. H. Brown (see http://www-unix.zk3.dec.com/www/competitive/dhba_ras.pdf http://www-unix.zk3.dec.com/www/competitive/dhbarasreport2.pdf).

· Superiority of AlphaServer hardware. -- High performance under a broad set of application loads and blazingly fast floating-point performance make them especially ideal for compute-intensive applications. PA-RISC servers do not have strong floating-point performance and do not deliver the broad performance and RAS capabilities that AlphaServers can provide.

· A leader in the high performance computing markets. The AlphaServer SC leads in markets where customers demand the absolute highest levels of computational performance available in general purpose servers. We anticipate that AlphaServers will continue to do so for years.

· Compaq's TruCluster Server forms the basis of Oracle's new 9i RAC. This is unique technology collaboration with the industry-leading database vendor.

· Compaq's AlphaServer roadmap and performance. We anticipate Compaq's previously announced roadmap for Alpha will outperform IPF for years. When IPF finally does surpass Alpha, customers can choose to migrate on their own timetable.

6. The new merged UNIX will be HP-UX, not Tru64 UNIX.

RESPONSE: HP has a great general-purpose data center UNIX with broad ISV coverage. Compaq has great clustering; RAS (reliability, availability, scalability) and performance characteristics, gaining share especially in high-performance technical computing market places. Converging the best of each onto the next generation Itanium platform will provide our customers with the most robust enterprise UNIX on the market. µ