Re: Sub Capacity Reporting for non IBM Vendors
Re: Posting From r.skoru...@bremultibank.com.pl on Fri, 11 Sep 2009 20:50:31 +0200 > Well. I thought the rules are slightly different: it is enough to > run some product ONCE during reporting period (month) to pay for > that. More precisely: if you run ABC product on LPAR1 (only) and > LPAR1 highest usage is nnn MSU then you pay for product ABC as it > would consume nnn MSU on that LPAR. And it doesn't matter that you > ran the product only once, 3 days before the peak occured. (This is > what I heard from IBMer, however I consider him as an oracle. ) One of the differences between a product which does cut SMF89 records and one which does not is how sophisticated SCRT can be when determining the peak rolling 4-hour average (R4HA) utilization to assign to it. For products which do cut SMF89 records SCRT is able to "know" which hours it was running and which it was not, and thus is able to assign the peak R4HA for the LPAR(s) in which it is running when it was running there, and not choose the peak when the product was not running. A product which does not cut SMF89 records (a.k.a. a "NO89" product) will be assumed to be running in the identified LPAR(s) any time that z/OS is running there. So, for example, let's say that CICS normally runs in LPAR1, but it does not always run there. If LPAR1 peaked at 9am Monday 31 August at 300 MSUs but CICS was not running then, CICS would not be charged 300 MSUs. SCRT would look at the R4HA for LPAR1 throughout the month specifically for the hours when CICS was running, and pick that peak R4HA value. It might help to imagine drawing a graph of the R4HA of LPAR1 for the whole month. Then imagine taking an eraser and erasing the parts of the graph for the hours when CICS was not running (and not cutting SMF89 records). The high point of what was left of the graph is the peak R4HA for LPAR1 when CICS was running, and that is what SCRT will assess for the bill. Maybe CICS would end up being charged 295 instead of the 300 which would be charged for z/OS. For NO89 products the MSUs assigned for billing will simply be the peak R4HA for the month of the LPAR(s) identified by the user as where the product ran that month. This case matches the example described in the original post. I like to avoid the verbs "consumed" or "used" when describing SCRT and sub-capacity pricing because that actually is not what the measurement is based upon. Sub-capacity charges are based upon the LPAR utilization of the machine, not upon product usage. In the example above, CICS did not consume 295 MSUs. CICS is charged 295 MSUs because the peak R4HA of LPAR1 for the hours of the month when CICS was running happened to be 295 MSUs. Other things were probably running in LPAR1 at the same time CICS was during that hour, the R4HA value of 295 is not due solely to CICS. Especially because that 295 is a smoothed average including LPAR1 activity from the previous 3 hours, who knows, maybe CICS wasn't even running in LPAR1 in those previous 3 hours. I hope this helps as opposed to making it more confusing... -- David J. Chase, WW System z Software Sales -- --IBM 18th Fl, 11 Madison Ave, NYC, NY 10010 -- -- 917-472-3346 - dchase at 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: Hardware withdrawal: IBM System z9
Ref Posting from: "Michael W. Moss" on Sun, 22 Nov 2009 03:34:16 -0600 (portions forwarded below) I didn't see a response to the note below, my apologies if the answer was already provided and I missed it. It is slightly more accurate to rephrase what Jim said this way: If you choose VWLC for z/OS then all programs on the machine which offer either VWLC or FWLC pricing must be priced with VWLC or FWLC respectively. One reason each customer's situation will be different is that product pricing under PSLC (full capacity) and VWLC/FLWC (sub-capacity) is usually different, depending upon the sub-capacity LPAR utilization. As a general rule of thumb (very, very general) the break even point for many products is at about 20% white space. Thus, very generally speaking, a customer who is always running, month after month, at a very high utilization rate may find that PSLC at full capacity is lower price than VWLC at full or nearly full capacity. Also, as Jim said, some customers are running their system with a very low utilization of one of the ULC-eligible products (Usage License Charges). In some of those cases a customer could find that paying full capacity PSLC for much of the software stack while paying the relatively lower ULC price for one or more of the sub-systems, could end up being less expensive than the entire software stack priced at sub-capacity VWLC. Again, it is totally dependant upon the specific customer's software stack and utilization characteristics. More information available at http://www.ibm.com/systems/z/resources/swprice/ Regards, David *** *** *** *** *** *** *** Forwarded File *** *** *** *** *** *** *** -- >The one area I think we need clarification is the all z/OS >products are VWLC eligible observation. I thought it was a subset, >what some might call core products as per: >www.ibm.com/systems/z/resources/swprice/reference/exhibits/mlc.html -- >Hence full-circle and back to my original question that I will >rephrase a little this time why aren't qualified customers >committed to the IBM Mainframe platform deploying VWLC pricing >mechanisms? -- >On Thu, 19 Nov 2009 06:18:00 -0600, Jim Elliott, IBM > wrote: > >>Mickey: >> >>Every customer should do a proper analysis of their total software >>bill to determine which pricing model is best for them. While VWLC >>may be best for most, I do have customers where due to usage >>characteristics, a combination of PSLC and ULC works out better. >>We see this often where a customer has a product which has ULC >>(Usage License Charge for DB2, CICS, IMS and MQ) which has low >>utilization. When you go to VWLC all z/OS IBM products go to VWLC. >> >>It is very important to read all the info at >>http://www.ibm.com/systems/z/resources/swprice/ >> >>Jim -- David J. Chase, WW System z Software Sales -- --IBM 18th Fl, 11 Madison Ave, NYC, NY 10010 -- -- 917-472-3346 - dchase at 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: IFL Extended to OpenSolaris
> But the intent of my question was whether one could just purchase > the "standard" RACF/VM license and then run it on z/VM on an IFL, > or does one have to obtain "special dispensation" from IBM to run > RACF/VM on an IFL, as was stated for RSCS? It's not clear to me if everyone understands that the following infrastructure support programs are priced features of z/VM V5 and therefore are perfectly capable of being licensed without special dispensation on IFLs: z/VM V5 Base (including CP, CMS, GCS, TCP/IP, REXX, PIPEs, much more...) z/VM V5 RACF z/VM V5 DirMaint z/VM V5 Performance Toolkit z/VM V5 RSCS The old separate RACF/VM program product is no longer marketed nor supported on modern VM versions. Same goes for the old versions of DirMaint, RSCS, and the predecessors of the Performance Toolkit. If you want any of these on z/VM V5 you license them as features of z/VM V5. They are 'allowed' to run anywhere you have z/VM itself licensed. David -- David J. Chase, WW zSeries Software Sales-- --IBM 18th Fl, 11 Madison Ave, NYC, NY 10010 -- -- 917-472-3346 - dchase at us.ibm.com -- -- 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
recreating deleted dataset
In this case we're talking about an operator error which caused the data (possibly) to be lost, so that situation needs to be described in the comment section of the report. As long as these mistakes do not happen with any regularity then there should be no problem with having this one report accepted. I would like to take this opportunity to remind all sub-cap customers that the contractual requirement is that all SMF data from all LPARs running z/OS must be included in the SCRT report, not merely 95%. While it has been IBM's practice to accept SCRT reports with less than 100% data collection reported, we did that because we knew that not every customer keeps their machine up and running 100% of the time. We didn't want to have to request documentation for every instance when that happened because back in the beginning we really didn't know what the average environment was going to look like. It was never meant to be a "free pass" to leave data out of the report. Not that I'm saying anyone is doing that, but I want to make that clear. David *** *** *** *** *** *** *** Forwarded File *** *** *** *** *** *** *** Date:Thu, 17 Jul 2008 08:07:01 -0500 From:"Kelman, Tom" <[EMAIL PROTECTED]> Subject: Re: recreating deleted dataset Ouch!! I don't know of anyway to recover that, maybe someone else does. I would think the VTOC entry would be gone, and it is highly likely that the data is already overwritten. How much did you lose? Was it more than one day's worth? You are required to have "% data collected" of >95% for the SCRT report to be accepted. 29 days of data out of 30 gives 96.67% and 30 days out of 31 gives 96.77% so if you don't lose anymore you should be alright. If you come up short maybe you could explain it as an exception in the SCRT report, and you could see if IBM will accept it. Tom Kelman Commerce Bank of Kansas City (816) 760-7632 > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Errol Van staden > Sent: Thursday, July 17, 2008 4:30 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: recreating deleted dataset > > Hi List. Does anybody have a utility or know how to recreate a deleted > dataset > (possibly by using the VTOC entry) Our storage administrator accidently > deleted all the SMF dumped data from a system and it has major SCRT > implications for workload usage. > > -- -- David J. Chase, WW zSeries Software Sales-- --IBM 18th Fl, 11 Madison Ave, NYC, NY 10010 -- -- 917-472-3346 - dchase at us.ibm.com -- -- 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
Re: z/VM Evaluation Edition Now Available
Re post from: Tony Harminc <[EMAIL PROTECTED]> >Well I am not a lawyer, etc. etc. but as far as I can see the licence >agreement doesn't say you must run it on a z10 only. Perhaps there is >a genuine technical limitation, e.g. it uses some of the new >instructions or a new HMC interface, or maybe it specifically tests >for the right machine. Indeed it is a technical limitation. The DVD-RAM loads from the DVD drive in the HMC and the z10 interface to the DVD is much, much faster than the interface in the older hardware. My understanding is that the DVD should load in some number of minutes on a z10 as opposed to some number of hours on an older machine. It would not be in anyone's best interests if we billed this as being supported on anything other than a z10. David -- David J. Chase, WW zSeries Software Sales-- --IBM 18th Fl, 11 Madison Ave, NYC, NY 10010 -- -- 917-472-3346 - dchase at us.ibm.com -- -- 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
Re: General question on licensing "obsolete" IBM products
Re posting from: Timothy Sipples > Getting media is another question. IBM may not be able to supply > it, so you'll have to find it from another source. As long as you > have a valid license this is apparently OK. Most IBM software > doesn't have license keys, so no obstacle there. The rest of Timothy's post is correct, but I need to clarify something from the paragraph quoted above. The IBM Customer Agreement (ICA) does not allow for the transfer of IBM's intellectual property from one customer to another. In simple words, you cannot acquire a program you do not have from someone else. (I'm not talking about the various remarketing or reseller agreements, obviously. I'm also only talking about ICA software, not IPLA software which is governed by a different license agreement with different terms.) "Withdrawn From Marketing" means we will no longer ship new media for the program, and it means we won't license the program to someone who does not have it. However if you do have it already and you copy it to another machine in your enterprise then we will create a new license for the software on the new machine. This has nothing to do with the metric under which the program is charged. The license is your permission to use the software on a particular machine. The "size" of the license, and thus the monthly charge, is a separate issue, usually determined by the size of the machine. -- David J. Chase, WW zSeries Software Sales-- --IBM 18th Fl, 11 Madison Ave, NYC, NY 10010 -- -- 917-472-3346 - dchase at us.ibm.com -- -- 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
Re: SCRT
IBM STRONGLY discourages automating the e-mail submission of SCRT Reports. It is very important that customers review their Sub-Capacity Reports each month with a team including software asset management, capacity planning, system programmers, procurement, etc., to ensure that the values on the Sub-Capacity Report represent accurate and fair billable MSUs prior to submitting the report. If the customer determines that any of the reported values are inflated due to an unusual circumstance, such as a looping program, they should follow the override process documented in the SCRT User Guide (http://ibm.com/zseries/swprice/scrt/pdf/scrt_user_guide.pdf). What everyone needs to understand is that when you submit your SCRT reports to IBM you are submitting a Firm Order. The MSU values cannot be changed a month or two afterwards if you were to later notice an error once you received your invoice. Because this manual review step is so crucial, IBM will not assist SCRT customers in building automated solutions which do not contain a process for human review of the reports. We are always open to suggestions from our customers about how we can help make processes such as these easier. -- David J. Chase, WW zSeries Software Sales --IBM 18th Fl, 11 Madison Ave, NYC, NY 10010 Original Message Subject: Re: SCRT Date: Wed, 14 Sep 2005 14:50:24 +0200 From: Werner Kuehnel <[EMAIL PROTECTED]> Organization: SAS Inc. Newsgroups: bit.listserv.ibm-main We send since months our SCRT reports fully automated to IBM, too. This morning I attended the webconference where LMDS was introduced. It seems that there is no automation possible. IBM might have automated their work, but on customer side this is a big step backwards. Werner -- Werner Kuehnel IMD GmbH (Mannheimer Versicherung) Mannheim - Germany -- 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
Re: SCRT
> I proposed that the SCRT team set up a FTP server that would automate > the sending of the reports directly from the host without the hassle > of the download to the PC. Then I could come in through the web > interface and when I select browse, only my reports would be visible > to me and I could adjust and/or confirm them as appropriate. But > should I fail to do confirm them, have them submitted as is from the > FTP server (for the reasons stated above). Hi Bob, yes, thanks very much, we agree that some sort of automation such as you describe would be an excellent way to streamline the process. We have added this requirement to the list of development requirements for future SCRT development based upon your comments from the pilot program. Of course at this point I can't tell you how long it will take to develop it, but it is on our list of things to do. David -- David J. Chase, WW zSeries Software Sales-- --IBM 18th Fl, 11 Madison Ave, NYC, NY 10010 -- -- 646-598-6272 - [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
SCRT Version 12.1 is available
Re posting from: Al Sherkow <[EMAIL PROTECTED]> Mon, 12 Jun 2006 11:57:18 -0500 (cross posted on IBM-MAIN and LPAR-PRICING-L) We apologize for accidentally leaving the z9 BC off of page 4 of the SCRT User's Guide, this oversight will be fixed in the next edition of the book. The software pricing website has been updated. http://ibm.com/zseries/swprice/ewlc.html -- David J. Chase, WW zSeries Software Sales-- --IBM 18th Fl, 11 Madison Ave, NYC, NY 10010 -- -- 646-598-6272 - dchase at us.ibm.com -- -- 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
Sysplex Aggregation
Re: Posting from Marcos_Morelatto (attached below) All the LPARs in the sysplex being used to demonstrate qualification must be using the same coupling facility structure. David > We will join two mainframes in one sysplex to reduce costs using WLC > (PricingPlex). The IBM document "Restatement of criteria for > aggregated sysplex ( > http://ibm.com/common/ssi/rep_ca/8/897/ENUS204-268/ENUS204-268.PDF > ) provides the rules. > > We already use the RACF CF caching in one mainframe (3 LPARs sharing > the same RACF). According the document the RACF caching is a "common > systems enablement function". > > The question is: if we activate the RACF caching on the second > mainframe, but using a different RACF DB, we will be compliant with > the sysplex aggregation rules? The rule does not specify that the > cached RACF DBs must be shared across all LPARs. Any experience with > this? > > Regards, > > Marcos Antonio Morelatto > T-Systems Brazil > Mainframe Technical Support -- David J. Chase, WW zSeries Software Sales-- --IBM 18th Fl, 11 Madison Ave, NYC, NY 10010 -- -- 917-472-3346 - dchase at us.ibm.com -- -- 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