Re: Cheryl's List #148
I didn't understand this comment: >The current problem with z/OS pricing is that most >software is charged on the size of the machine, not >the amount of usage of the software. The newsletter mentions VWLC later, but I disagree with this sentence with respect to IBM software. (It's not a "current problem.") Most customers now pay for all or at least the vast majority of IBM software based on monthly peak four hour rolling averages on an LPAR basis and in very granular MSU increments. The size of the machine is irrelevant except as an overall limit, not as a floor. Even some sub-LPAR sub-capacity pricing is now available. I could change just one word to make that sentence correct, though: "The current problem with non-mainframe pricing is that most software is charged on the size of the machine, not the amount of usage of the software." IBM and a few other vendors allow you to license their non-mainframe software on the number of CPUs that it runs (at maximum) rather than the total number of processors in the machine, with (much coarser) core granularity, but that practice is hardly universal. - - - - - Timothy Sipples Resident Enterprise Architect Value Creation & Complex Deals Team IBM Growth Markets (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cheryl's List #148
I could change it to say that "The current problem with z/OS pricing is that most software is charged on the size of the machine OR LPAR, not the amount of usage of the software." But I still think it's a current problem. There have been improvements in MVS releases to address this situation, such as the latest pricing improvement for z196 machines, Integrated Workload Pricing. But the basic problem still exists. When you add work to a z machine or LPAR, the cost of most of the other IBM and ISV software will increase. Referring back to the other discussion of 'Dummy LPARs', yes, you could put the new software in another LPAR and not increase the software prices of the major software on the machine. But the z/OS usage is still increased. Many of the ISVs use sub-capacity pricing based on the MIPS or MSUs of the LPARs running z/OS. So an added LPAR for a new workload still causes an increase. In 2009, I quoted Al Sherkow in my newsletter when he said "about half of IBM's customers use sub-capacity pricing." I assume (and hope) that a greater percentage are now using sub-capacity pricing, but it's been a long haul. When I ask people why they don't use it, I get a variety of answers, but it's usually something in the form of "well we have this special full-site license that covers everything." That might work fine for IBM products, but it doesn't work for all products. Every installation should be pushing their ISVs to do sub-capacity pricing. When I talk about 'usage-based' pricing, I'm talking about a product that uses 30 MIPS during its peak, not about one that runs in a 30 MIPS LPAR. Because the tooling for that type of chargeback is fairly expensive, I can't see it happening except for new products arriving in the marketplace. I hope that explains my statements. Best regards, Cheryl == Cheryl Watson Watson & Walker, Inc. www.watsonwalker.com 941-266-6609 == On Mar 12, 2011, at 1:58 AM, Timothy Sipples wrote: I didn't understand this comment: > The current problem with z/OS pricing is that most > software is charged on the size of the machine, not > the amount of usage of the software. The newsletter mentions VWLC later, but I disagree with this sentence with respect to IBM software. (It's not a "current problem.") Most customers now pay for all or at least the vast majority of IBM software based on monthly peak four hour rolling averages on an LPAR basis and in very granular MSU increments. The size of the machine is irrelevant except as an overall limit, not as a floor. Even some sub-LPAR sub-capacity pricing is now available. I could change just one word to make that sentence correct, though: "The current problem with non-mainframe pricing is that most software is charged on the size of the machine, not the amount of usage of the software." IBM and a few other vendors allow you to license their non-mainframe software on the number of CPUs that it runs (at maximum) rather than the total number of processors in the machine, with (much coarser) core granularity, but that practice is hardly universal. - - - - - Timothy Sipples Resident Enterprise Architect Value Creation & Complex Deals Team IBM Growth Markets (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cheryl's List #148
A few follow-up comments: 1. It is possible (and common) to see different MSU values for z/OS and, for example, for DB2 in SCRT reports. That is, a particular LPAR could peak at 10 MSUs for z/OS and peak at 8 MSUs for DB2 (and 7 MSUs for CICS), or whatever. All the major IBM products (plus several others) cut their own SMF Type 89 records. Just like the machine, the size of the LPAR (z/OS peak) is only a ceiling, not a floor, for the other products. 2. One of the factors in determining how to configure LPARs (and how many to configure) is software licensing, and certainly that's common practice (and has been for years). IBM's zNALC and Solution Edition licensing requires separate LPARs, in fact. 3. Integrated Workload Pricing (IWP) gets even deeper into sub-LPAR sub-capacity licensing. 4. I'm also puzzled why sub-capacity licensing isn't even more popular. - - - - - Timothy Sipples Resident Enterprise Architect Value Creation & Complex Deals Team IBM Growth Markets (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cheryl's List #148
Hi Timothy, I certainly can't speak for all shops, but for mine and I suspect others, there are problems acheiving reductions (leveling, if you will) in the 4 hour peak. We used to run 24x7, until the budget mess hit. Now we run 16x5. With the next round of layoffs planned, it will probably be 10 x5. We can no longer spread our workload out across 24 hours and 7 days. Our onlines do run 24x7, but batch for the most part has been shifted to times when support folks (operators) are available. We really need the pricing break that sub-cap could give us, but that rolling 4 hour requirement kills it for us. During the times when support staff is available, our production LPAR runs at 95-100%. Offshift, with only the online and backups running, the LPAR runs at 25-30%. Are there any other measurement methods that are supported for sub-cap? Thanks, Linda - Original Message - From: "Timothy Sipples" To: IBM-MAIN@bama.ua.edu Sent: Sunday, March 13, 2011 6:04:54 AM Subject: Re: Cheryl's List #148 A few follow-up comments: 1. It is possible (and common) to see different MSU values for z/OS and, for example, for DB2 in SCRT reports. That is, a particular LPAR could peak at 10 MSUs for z/OS and peak at 8 MSUs for DB2 (and 7 MSUs for CICS), or whatever. All the major IBM products (plus several others) cut their own SMF Type 89 records. Just like the machine, the size of the LPAR (z/OS peak) is only a ceiling, not a floor, for the other products. 2. One of the factors in determining how to configure LPARs (and how many to configure) is software licensing, and certainly that's common practice (and has been for years). IBM's zNALC and Solution Edition licensing requires separate LPARs, in fact. 3. Integrated Workload Pricing (IWP) gets even deeper into sub-LPAR sub-capacity licensing. 4. I'm also puzzled why sub-capacity licensing isn't even more popular. - - - - - Timothy Sipples Resident Enterprise Architect Value Creation & Complex Deals Team IBM Growth Markets (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cheryl's List #148
On Sun, Mar 13, 2011 at 9:04 AM, Timothy Sipples
wrote:
> 4. I'm also puzzled why sub-capacity licensing isn't even more popular.
With customers or vendors?
For vendors, it's a chance to collect less money...not so appealing.
For customers, yeah, IF the vendor offers it.
But short of customer revolt, there's little incentive for the vendor
to offer it; and in this new millennium of let's-make-a-deal, with
even IBM not really having "list" prices, customers who care can
usually bludgeon their vendors into submission without having to issue
an ultimatum ("Subcapacity or nothing").
--
zMan -- "I've got a mainframe and I'm not afraid to use it"
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cheryl's List #148
Responding to Linda, I think you'll want to compare business cases with your management. Case #1: Business as usual. Case #2: Minimize the cost of overnight operators as much as possible (through increased automation, alerting, etc.), and compare the cost of that skeleton crew (of one?) to the likely sub-capacity license savings. It seems odd to me that #1 would make financial sense, but odd is not impossible. And then Case #3: Case #2, plus reallocate some non-mainframe operators by shifting workload to the mainframe, starting with some workloads that can fill utilization "valleys." Mainframes are *extremely* operator-efficient -- so if there's a focus on controlling operations costs, go actually control operations costs. If you add workload to a mainframe, typically the operations staff doesn't even change. - - - - - Timothy Sipples Resident Enterprise Architect Value Creation & Complex Deals Team IBM Growth Markets (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cheryl's List #148
On Mon, Mar 14, 2011 at 12:39 AM, Timothy Sipples wrote: > Mainframes are *extremely* operator-efficient Hmm...while certainly true, I sure hope IBM marketing doesn't seize on that as the next mainframe marketing tactic! That's worse than the "Magic Box"... -- zMan -- "I've got a mainframe and I'm not afraid to use it" -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cheryl's List #148
The one thing that I think is decidedly true is that the plethora of IBM pricing metrics makes it very difficult for customers to understand and optimize their costs. Of course that may be intentional--IBM needs to have their revenue stream of course. On the other hand, at least IBM is fairly transparent about their pricing, at least for MLC software. The ISVs, not so much. Transparency is good regardless of how complicated it is to figure out and regardless of whether or not we like the final number. At least we can predict that number--at least until we're surprised by some nuance in the rules that we had missed. Which leads us back to the issue of things being too complicated. Regarding the lack of usage of sub-capacity VWLC, wasn't it only with the z10s that Group Capacity Limits became available? Before that there wasn't any good (built-in) way of controlling the overall usage and so it was quite easy for your R4H to hit very near 100% at *some* time during the month. GCL now gives us a way to ensure the R4H doesn't go over our defined limit just because somebody wrote some bad code or we needed to do a large testing cycle or some such. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cheryl's List #148
Yes, it is common to see different MSU values for z/OS and DB2 and CICS in SCRT reports. Its because DB2 and/or CICS isn't running in every LPAR on a box. If z/OS and DB2 and CICS is running in the same LPAR then you will always see the same 4hr peak for all three products for the month for that LPAR. The metric is based on z/OS busy and if ANY CICS region or ANY DB2 region is active in the LPAR during that 4hr period of the month. So even a single CICS region for example running very few or even no transactions in the LPAR will cause the CICS charges to be the same for the LPAR as when there are dozens or hundreds of regions running millions of transactions. This is the problem with peak-based container pricing whether it be at the CEC level (machine mips) or LPAR level (VWLC), if you don't fully utilize the container for every product then you end up paying more than you'd like and if you create lots of little containers to optimize product pricing then you create a lot of undesirable architectural overhead. -Original Message- >From: Timothy Sipples >Sent: Mar 13, 2011 8:04 AM >To: IBM-MAIN@bama.ua.edu >Subject: Re: Cheryl's List #148 > >A few follow-up comments: > >1. It is possible (and common) to see different MSU values for z/OS and, >for example, for DB2 in SCRT reports. That is, a particular LPAR could peak >at 10 MSUs for z/OS and peak at 8 MSUs for DB2 (and 7 MSUs for CICS), or >whatever. All the major IBM products (plus several others) cut their own >SMF Type 89 records. Just like the machine, the size of the LPAR (z/OS >peak) is only a ceiling, not a floor, for the other products. > >2. One of the factors in determining how to configure LPARs (and how many >to configure) is software licensing, and certainly that's common practice >(and has been for years). IBM's zNALC and Solution Edition licensing >requires separate LPARs, in fact. > >3. Integrated Workload Pricing (IWP) gets even deeper into sub-LPAR >sub-capacity licensing. > >4. I'm also puzzled why sub-capacity licensing isn't even more popular. > >- - - - - >Timothy Sipples >Resident Enterprise Architect >Value Creation & Complex Deals Team >IBM Growth Markets (Based in Singapore) >E-Mail: timothy.sipp...@us.ibm.com >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cheryl's List #148
Timothy: Some good points. There is also a issue when you try and reduce operators. The biggest issue I have seen is that the number of IPL's goes up and small problems become large problems. On the other end I have also seen the "untrained" people end up calling the systems people and they(systems people) are exhausted by the next morning as you end up on the phone with them for long periods of time. Meanwhile the systems people get really pe'oed at management and refuse to take phone calls. Then it becaomes a pissing match between departments. No one wins at this and mean while the good sysprog people just can't get out of the place fast enough. Also you have to tell new people that they should expect long phone calls in the middle of the night. Ed From: Timothy Sipples To: IBM-MAIN@bama.ua.edu Sent: Sun, March 13, 2011 11:39:10 PM Subject: Re: Cheryl's List #148 Responding to Linda, I think you'll want to compare business cases with your management. Case #1: Business as usual. Case #2: Minimize the cost of overnight operators as much as possible (through increased automation, alerting, etc.), and compare the cost of that skeleton crew (of one?) to the likely sub-capacity license savings. It seems odd to me that #1 would make financial sense, but odd is not impossible. And then Case #3: Case #2, plus reallocate some non-mainframe operators by shifting workload to the mainframe, starting with some workloads that can fill utilization "valleys." Mainframes are *extremely* operator-efficient -- so if there's a focus on controlling operations costs, go actually control operations costs. If you add workload to a mainframe, typically the operations staff doesn't even change. - - - - - Timothy Sipples Resident Enterprise Architect Value Creation & Complex Deals Team IBM Growth Markets (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cheryl's List #148
Hi Timothy, Case #1: Business as usual. Business as usual has already been taken by the budget woes. Case #2: Minimize the cost of overnight operators as much as possible (through increased automation, alerting, etc.), and compare the cost of that skeleton crew (of one?) to the likely sub-capacity license savings. We have no automation products, and cannot purchase any - budget. It seems odd to me that #1 would make financial sense, but odd is not impossible. And then Case #3: Case #2, plus reallocate some non-mainframe operators by shifting workload to the mainframe, starting with some workloads that can fill utilization "valleys." The mainframe operators already monitor the other systems. Mainframes are *extremely* operator-efficient -- so if there's a focus on controlling operations costs, go actually control operations costs. If you add workload to a mainframe, typically the operations staff doesn't even change. True enough, but in these budget times, with every body cutting everthing that can be cut, the layoff of staff is easily quantifiable in the amount of 'savings'. If there were other options that would reduce costs, that would be most welcome. We have already cut some staff, some software, and some maintenance services. It is also my understanding that Group Capacity L imits became available with z10, but we are on an 80 MIP z800. The ability to use an average R4H, rather than peak R4H would probably help us a lot. - Original Message - From: "Timothy Sipples" To: IBM-MAIN@bama.ua.edu Sent: Sunday, March 13, 2011 9:39:10 PM Subject: Re: Cheryl's List #148 Responding to Linda, I think you'll want to compare business cases with your management. Case #1: Business as usual. Case #2: Minimize the cost of overnight operators as much as possible (through increased automation, alerting, etc.), and compare the cost of that skeleton crew (of one?) to the likely sub-capacity license savings. It seems odd to me that #1 would make financial sense, but odd is not impossible. And then Case #3: Case #2, plus reallocate some non-mainframe operators by shifting workload to the mainframe, starting with some workloads that can fill utilization "valleys." Mainframes are *extremely* operator-efficient -- so if there's a focus on controlling operations costs, go actually control operations costs. If you add workload to a mainframe, typically the operations staff doesn't even change. - - - - - Timothy Sipples Resident Enterprise Architect Value Creation & Complex Deals Team IBM Growth Markets (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cheryl's List #148
http://www.bsp-gmbh.com/turnkey/cookbook/bsppilot.html Possible automation on CBT tape 249, file 33. Was rewritten for MVS 3.8 Turnkey project. I was thinking BSP was licensed for non-commercial use, but I don't see any distribution or licensing sites other than Turnkey 3. I did see a message about using it on OS/390. On Tue, Mar 15, 2011 at 3:53 PM, Linda Mooney wrote: > Hi Timothy, > We have no automation products, and cannot purchase any - budget. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cheryl's List #148
There's also a triple technology dividend between a z800 and a z10 BC. And more granular capacity settings. And zIIPs and zAAPs. And much beefier IFLs for additional consolidation potential. I'm not sure what capacity you have for your z800, but let me guess it's a 2066-0B1 which is approximately 99 MIPS and exactly 20 MSUs (full capacity). Other examples are similar. Here are some z10 BC configurations that would be analogous to a 2066-0B1 (ignoring potential specialty engine benefits): 2098-J01: ~96 MIPS/12 MSUs 2098-E02: ~96 MIPS/12 MSUs 2098-K01: ~108 MIPS/14 MSUs 2098-F02: ~107 MIPS/14 MSUs Let's go with the average of 13 MSUs. Just moving to a z10 BC would yield a ~35% reduction in MSUs, which then yields a substantial reduction in IBM license charges. For example, if you're currently seeing a peak 4HRA of 19 MSUs on a z800, you'd probably see that change to 12 MSUs on a z10 BC. There's most likely a strong business case here for doing something different/smarter when putting the ingredients together. Whether your employer sees the business case reasonably accurately then acts on the business case is another question, unfortunately. :-( - - - - - Timothy Sipples Resident Enterprise Architect Value Creation & Complex Deals Team IBM Growth Markets (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
