Roger Lowe asks: >Surely, the functionality of MWRT could have been added to SCRT so >that us customers could keep running it on z/OS?
IBM did that, as I understand it -- and I thought I explained that, but I'll try again. SCRT also has a Microsoft Windows-based tool component. MWRT is a *replacement* for that Windows-based SCRT component. If you're using MWRT, you don't have to also use SCRT (the Windows tool). This is path augmentation, not path duplication. For those of you who are not going to use MWRT, it's business as usual (SCRT). Think of this as SCRT Standard Edition and SCRT Advanced Edition (MWRT), basically. For now, at least, there will be two tools/paths with MWRT a perfect superset of SCRT. If the Microsoft Windows desktop/laptop requirement for SCRT/MWRT is not a good requirement, let IBM know through the appropriate channels. Radoslaw Skorupka asks: >How can the tool recognize which transactions are mobile? Aled Hughes remarks: >I may be stupid, but I have yet to understand the basics - what >is defined as a 'mobile transaction'. I thought I was clear on that point, too, but I'll try again. If *you* can distinguish between a mobile transaction and a non-mobile transaction, IBM is willing to at least discuss the measurement and reporting processes. Both you and IBM sit down to agree on a measurement plan consistent with IBM's views of the term "mobile transaction." If that measurement plan is "reasonable," it'll probably be approved. For those of you still scratching your heads thinking that's a "radical" notion, it's not. As long as the definitions are well understood, and as long as you and IBM can measure (and if necessary audit) against those definitions, there should be no particular impediment. Most of you already know how many of your customers are arriving via iOS devices, and how many are arriving via Android devices, and how many are arriving via Blackberries, and so on. Most of you probably already know the nature and number of CICS transactions (for example) attributable to each of those devices (or at least those devices collectively). If you do, great, work out a measurement and reporting plan with IBM. If you don't, that might be a problem already (for customer service, capacity planning, and/or security reasons), and now you've got some additional incentive to address those possible gaps. One of my IBM colleagues provided me with some additional information over the weekend. MWP is even better than I described. Here are the points of clarification (in no particular order): 1. MWP is actually the *third* sub-sub-capacity licensing innovation. The first was Getting Started Sub-Capacity Pricing (GSSP), then IWP arrived, now MWP. (I wrote that MWP was the second sub-LPAR sub-capacity licensing option from IBM, but it's actually the third.) A lot of you said you didn't always like having separate LPARs for separate licensing, and IBM continues to respond to your requests. 2. MWP *can* apply to zNALC LPARs. If you have a z/OS LPAR (zNALC or not) with only z/OS (and z/OS elements) but no other IBM products, then MWP doesn't apply. I stated that correctly. But if you have a qualified zNALC LPAR with other IBM products (e.g. DB2 for z/OS) licensed via AWLC or AEWLC or sub-capacity IPLA, *yes*, MWP *can* apply to those other products. Good news again. 3. Relatedly, MWRT will adjust the MSUs downward for *all* sub-capacity eligible IBM products running on z/OS, based on measured "mobile transactions" as agreed with IBM. Yes, that includes sub-capacity IBM International Program License Agreement (IPLA) products. To pick an example, if you're running IBM Integration Bus for z/OS (formerly known as WebSphere Message Broker for z/OS), MWRT can adjust that product's reported MSUs, too, based on mobile use of Integration Bus's services. Your IBM CICS tools are adjusted with your CICS, your IBM IMS tools with your IMS, your IBM DB2 tools with your DB2, your IBM MQ tools with your MQ, your ACLS.... It's across the (z/OS-based) board, according to the amount of workload classed as "mobile transactions" (as agreed with IBM), excluding only z/OS and z/OS elements. It's not only the big IBM products I listed. Everything IBM that's (a) sub-capacity eligible, (b) riding on z/OS, (c) with mobile activity. Very good news. 4. Sysplex qualification rules are unaffected, as I wrote. I really should not have mentioned Sysplex aggregation rules so close together with SCRT/MWRT measurements since Sysplex qualification and the "50% rule" are measured quite differently. But, to reiterate, nothing changes there -- and that's good. You wouldn't want MWP to suddenly make you ineligible for Sysplex aggregation as your billed MSUs drop, and it doesn't -- MWP has no impact on those rules. To respond to the comments about licensing complexity, I think I addressed that adequately, too, but I'll try again. MWP shouldn't require much work to adopt, and the work it requires versus status quo should be of a one-time nature and well compensated. You keep following the same processes and procedures as SCRT, but you use a slightly expanded tool (MWRT) that applies a downward adjustment factor based on "mobile transaction" measurements as one more input into the monthly calculations. Yes, you'll have to figure out with IBM how that should be done, but in initial customer experiences this hasn't been rocket science. If you just have no clue where transactions are coming from, that's probably a problem requiring remediation that MWP is now making visible, not a new problem. In terms of decision making, it's not complicated either. If you have mobile transactions, adopt MWP, quite simply. If you don't have mobile transactions, or if you're currently handling your mobile transactions off your mainframe -- with some likely Rube Goldberg-esque architecture that's geometrically more complicated than MWRT ever could be -- start doing mobile transactions on z/OS with MWP. If you've got an IBM Solution Edition then don't worry about that LPAR (or those LPARs) until you get closer to the end of your term. If you've got an IBM Enterprise License Agreement (ELA) and some room to your caps, this is also a great time to add even more mobile transactions to your mainframe. The central point is that the price of mobile transactions on z/OS mainframes is dropping. A lot. Unambiguously. When the price of something drops a lot, then at least at the margins you (and/or others like you) should be shifting more existing mobile transactions to z/OS mainframes and/or doing more new mobile transactions with z/OS mainframes. That's just common, economic and financial sense. Exactly where you are in your mobile journey is situational, but this big IBM price cut at least ought to make you rethink what you're doing (or not doing). And that's not rocket science either. -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, zEnterprise Industry Solutions, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
