Ed Jaffe wrote: >Agreed. For example, it would be good if monitors such a RMF and >others did not use costly machine cycles.
Leaving aside "costly machine cycles" (compared to what?), it would be technically impossible, wouldn't it? It's at least very technically difficult to monitor something without, well, monitoring. Instrumentation always comes with a cost, though we can often get that cost down very low. (I would posit that's already true today on zEnterprise compared to anything else, but we're never completely satisfied.) Sometimes I use the phrase "Be careful what you wish for," and this is one of those occasions. If your request is that IBM (and other vendors) continue working to make monitoring more efficient, I'd agree that's a great idea. Efficiency promotes scalability and performance, making previously impossible (or at least difficult) business computing problems possible to solve and solve well. That's all good. 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.) Look, I can tell you that it makes little sense to "push the balloon." If you want a lower cost of computing, great, but this sort of approach won't do it. We learned that some years ago. I won't bore you with all the sordid details -- maybe 10 years from now -- but the bottom line is if you want to tackle cost you must tackle, well, cost. And to do that you have to do pretty much what IBM is doing: drive growth, invest in innovations to keep the business #1, and share at least some of the fruits of that growth with our loyal customers to drive down their total costs for entire solution(s). That's the "virtuous cycle." Rearranging the deck chairs, metaphorically speaking, doesn't accomplish much. (*) OK, there's one(**) technical enhancement in this area I'd personally like to see IBM deliver. "Talk to your IBM Representative" if you agree, and take a coffee break if you don't. :-) It'd be that SCRT would also collect and tally SMF Type 89 records for anybody's product that cares to generate such records. This enhancement wouldn't be so exciting for, say, a random DB2 tool. The MSUs reported for DB2 serve pretty well in that case. But it could still be interesting for other software products. I think the ideas behind SCRT are really sound, and it'd be nice if every vendor who wishes could more easily plug into that particular ecosystem if/as they wish. (**) OK, maybe two. I think additional sub-LPAR capping controls might be interesting if technically doable, though there's already been some work done there with IBM's Integrated Workload Pricing (IWP). Resistance to provisioning an LPAR is way overblown in many organizations (compared to what alternatives? again), but nonetheless I think there might be some room for improved sub-LPAR workload control capabilities. Of course these opinions are my own, and I'm often far too open and candid about my thoughts. :-) -------------------------------------------------------------------------------------------------------- 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
