On 07/16/2010 02:56 AM, Timothy Sipples wrote: > Norman Hollander writes: >> Specialty Engines don't exist for performance reasons. They exist >> to defer General Purpose Engine upgrades which WILL increase >> software licensing charges. > > First of all, general purpose engine upgrades don't increase software > licensing charges unless you're talking about software licenses tied to > machine capacity (i.e. full capacity licensing). You can add as many CPs as > you want, but what you pay for sub-capacity licensed software depends on > whether you use the CP capacity or not (and on a sustained basis, i.e. peak > four hour rolling average). I'm not trying to be pedantic. It's a very > important distinction.
Adding GP or speciality engines cost money. Intelligent management won't pay for engines for which there is no perceived need. We have never done a GP CP upgrade that did not result in latent demand raising our peak monthly 4-hour MSU, while adding a speciality engine where the load warrants it has the potential for lowering the GP 4-hour MSU peak. If your management is dumb enough to pay for hardware charges on engines they don't really need, then of course it would be true that with sub-capacity licensing there is no automatic increase for software when GPs are added. So yes there is a distinction, but with wiser management the distinction vanishes. If there are any periods where all GPs are saturated at 100%, adding another GP will certainly improve throughput and response time (the usual measures of performance) during those peaks, and adding a specialty engine might improve it if that allows additional work to be offloaded from the GPs during the peaks. Specialty engines exist because because they fulfilled an IBM marketing strategy to encourage new workloads on z/OS and make z/OS more competitive in cost - no doubt with the goal of preserving and increasing z/OS and related revenue in the long-term. JC EWing > > Moreover, if you're also upgrading models, that could lower your software > charges. > > And software licensing charges better not be the sole criterion for your > business's success or failure, otherwise you're really in trouble. (Some > businesses are!) Software you license is software you don't have to write > yourself (or software that would otherwise be unwritten or un-run). And > spending more on such software is often the best idea in the world, because > it means (for example) you've eliminated a paper-based process that's > costing your business an incredible fortune every month, not to mention > lost marketshare. Software is great stuff, and I buy and use a lot of it > because it helps me get my job done better. And every computer would be an > expensive doorstop without good software. > > Anyway, with all that out of the way, in the engineering sense I suppose > you could argue that specialty engines do not provide "performance," as > long as you're also willing to argue that additional CPs don't provide > performance either. However, in the real world, I think they do: or at > least price-performance. That's because you've implicitly assumed equal > response time service delivery pre- and post-specialty engine installation. > To the end user, at least, the specialty engine provides "performance" > because their response times improve as they get more CPU resource for > their particular workloads, post-speciality engine. > > I've heard people argue that speciality engines are not "accelerators," so > don't use that word. Well, OK, in the pure engineering sense maybe they > have a point. But how about the end user's point of view? She gets better > response time because her workload has less contention and more capacity > available. Her work is accelerated. > > So if end users (among others) want to use words like "performance" and > "accelerator" to describe speciality engines, why not? It works for me, and > I'm not going to be so pedantic about that. > > Speaking only for myself, as always. > > - - - - - > Timothy Sipples > Resident Enterprise Architect > STG Value Creation & Complex Deals Team > IBM Growth Markets (Based in Singapore) > E-Mail: [email protected] ... -- Joel C. Ewing, Fort Smith, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
