Timothy, I think you are confusing operational costs with software costs.
Having worked for several ISV's, we were often looking at ways to make running our products less expensive. We charged just as much for them as before and it did not stop the 'normal' price increases. Note: I twiddle the bits, not the cents, so pricing is way outside my comfort zone and I pass no judgments on that, other than to say if there was no ROI then no one would buy the product. And, yes, my degree is in economics. The specialty engines that you refer to (and the GP processor) are actually all the same chip, they are just re-taskings as to what can run on it. That is why another ISV was able to do a little magic and have regular jobs run on a z/IIP engine. IBM is coming up with new specialty add-on cards which is what CryptoExpress and others actually are. These are not in the same category as a GP or z/IIP, etc. Back to your original thought. Decreasing the operational cost of monitoring frees up resources for functions that actually make money, so that is a good thing. The one area that I wish could be improved on is the processing of SMF data. At one shop I worked in, our biggest single application was processing the daily SMF data. The software we used to process it was inexpensive, MXG and SAS, but the operational cost was high. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Timothy Sipples Sent: Wednesday, November 06, 2013 12:14 AM To: [email protected] Subject: Re: Security exposure of zXXP was Re: zIIP simulation If, on the other hand, you're asking IBM (and other vendors) to spend some of their precious engineering talents and efforts on new price discrimination features specifically for monitoring, does that really make sense? Let's suppose for sake of argument that such new facilities existed, and consequently the "price" to run monitoring decreases. OK, then what happens to the prices of everything else? And, for that matter, what happens to the prices of monitoring tools? These vendors still have payroll to meet, still have R&D to do, still have support to deliver, etc. Will you actually end up with more and better monitoring? Or will the most likely outcome be that you run exactly the same (or even less!) monitoring than you do today, and your total IT expenditures barely budge (ceteris paribus) as the various vendors quickly re-establish market equilibrium? Did anyone else ever study economics? :-) I rather like the current situation, which is that there are these nifty things called zIIPs which vendors can choose to use as much or as little as they wish according to their particular individual business models (and with an IBM agreement). That is, there are already *plenty* of ways tools vendors can price discriminate if/as they wish and if/as competitive markets require. zEnterprise already has the most sophisticated, widest variety of metrics for vendors to price their wares compared to any other platform. And 1,000+ flowers have bloomed. Name any pricing design you want, and there's probably a zEnterprise vendor that offers it. Do we really need *more* such technical facilities(*) -- and do we need any more so badly that we can cancel something wonderful that IBM's engineers could be working on instead? I'd vote no(*) based on currently available information, though I try to keep an open mind. Along those lines, IBM has a Statement of Direction that zAAPs will no longer be available on future zEnterprise models, so IBM is trying to simplify things at least a bit since having four types of specialty z/OS engines probably isn't "enough better" than having three. (For those keeping score, the four types are SAPs, ICFs, zAAPs, and zIIPs. Four isn't necessarily the correct number -- zEDC, CryptoExpress, etc. also count -- but those are the four I was referring to.) -------------------------------------------------------------------------------------------------------- Timothy Sipples GMU VCT Architect Executive (Based in Singapore) E-Mail: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ATTENTION: ----- The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
