Re: Prometheus -- MIDRANGE-L

Yes, you ~did~ miss the point. By many miles.

A customer with a ~small~ iSeries or AS/400 is NOT using XML or WAS to thedegree you suggest. There are applications that are written in green codethat are feature rich and do not need middleware to gobble up the CPW. Thesecustomers are the audience for a smaller i5 - not the ones who are writingslow applications with VB connections to an i.

On your other point, selling a System p is not at all profitable for IBMcompared to selling a System i. And, selling a System p to System icustomers who are on a green screen ERP application will cost them hugeeffort and money to convert or replace their application.

Selling a server with a much smaller profit margin, and migrating FROM aSystem i - NOT a good deal. Not even close.

----- Original Message -----From: "Richter,Steve"

Subject: RE: Prometheus

-----Original Message-----
From: Trevor Perry [mailto:tperry@xxxxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, May 30, 2006 4:53 PM
To: Midrange Systems Technical Discussion
Subject: Re: Prometheus
Wow! Did you miss the point.
I have MANY customers running at 100CPW or close. Their applications are
feature RICH, and they need only a little more CPW - just a server
modernization for new features. To suggest they should depart the platform
is ludicrous. With a server that will run their original AS/400
applications, and can also get them to the web without having to add
servers, etc, they will be able to run their SMB business for years tocome.
I have XML code that runs on a 485 CPW system that can take many minutesto run when the document gets over 10 meg in size. Where I workedrecently, on a 570 with 2 cores we were doing a lot of work with VB codethat called SQL procedures on the 570 and got result sets back in return.The response time of that code was barely acceptable. I dont see how a 100CPW system will be able to return result sets to a PC client VB programwith decent response time.
( another example. I am approaching 1 minute on a 485 CPW system tocreate a service program. Why should I have to limit the number ofprocedures I have or divide them up into many service programs? Justbecause the system is so CPW starved? That is no way to sell a moderncomputer system. )
In my example with the result sets returned from the sql procedures thecode ran slow mostly because the sql procedures were doing a lot of workand they could have been more efficient ( things like creating files inqtemp, etc ). But why bother? If the system is priced per user then wecould just throw another cheap but powerful CPU core at the problem. IBMmakes the same amount of money and the customer is happy because they donthave to spend thousands of dollars to have their code rewritten.
The p5 is successful and it's system software ( db2 ) is sold per user.IBM makes money and the customers are buying a lot of p5s. A good deal allaround, no?
-Steve