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: Sub Capacity Reporting for non IBM Vendors
Edward Jaffe pisze: R.S. wrote: It is also worth to mention that IBM is the only company which is not try to catch the customer. I read several horror stories on this forum, on ISVcosts list, from own experience - almost any other company presents license agreements that HAVE to be negotiated. Only IBM's license agreemenst are let's say FAIR. No excessive costs of upgrade, SS, etc. BTW: I didn't say 'CA' g You're statements that: IBM is the only company which is not try to 'catch' the customer and Only IBM's license agreemenst are let's say FAIR [SIC]--which I will paraphrase, since you are a non-native English speaker, to mean: IBM is the only honest mainframe software company are highly insulting and patently false. You might have read so-called horror stories. And, you might have your own anecdotal negative experiences. But, I know for an ABSOLUTE FACT you are NOT a customer of Phoenix Software International. Your assertions, therefore, should not and cannot apply to us or any other software providers with whom you do not do business. (I suspect there are *dozens* of them--some who freely contribute their time and expertise to this list!) Your statements are unfair, inaccurate, subjective opinion presented as fact, and ought to be recanted... I recant. I shouldn't say that IBM is the only honest company. That should be the only honest company *I know* . This statement does not preclude other companies. Obviously I didn't mean PSI, because I had nothing to do with this company. However *every* ISV's license agreement I met needed negotiation. Not only for the price, but first of all terms and conditions. Sometimes it was small change, but sometimes not. Last but not least: ISV *technical* employees usually are not responsible for marketing model of the company they work for. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- 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: Sub Capacity Reporting for non IBM Vendors
On Mon, 14 Sep 2009 08:50:02 +0200 R.S. r.skoru...@bremultibank.com.pl wrote: :I recant. :I shouldn't say that IBM is the only honest company. That should be the :only honest company *I know* . This statement does not preclude other :companies. :Obviously I didn't mean PSI, because I had nothing to do with this :company. However *every* ISV's license agreement I met needed :negotiation. Not only for the price, but first of all terms and :conditions. Sometimes it was small change, but sometimes not. Let me understand this correctly. You accept all IBM boilerplate agreements with zero negotiation??? -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: Sub Capacity Reporting for non IBM Vendors
Binyamin Dissen pisze: On Mon, 14 Sep 2009 08:50:02 +0200 R.S. r.skoru...@bremultibank.com.pl wrote: :I recant. :I shouldn't say that IBM is the only honest company. That should be the :only honest company *I know* . This statement does not preclude other :companies. :Obviously I didn't mean PSI, because I had nothing to do with this :company. However *every* ISV's license agreement I met needed :negotiation. Not only for the price, but first of all terms and :conditions. Sometimes it was small change, but sometimes not. Let me understand this correctly. You accept all IBM boilerplate agreements with zero negotiation??? No. I don't have to look for gotchas. I negotiate prices, but usually not TsCs. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- 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: Sub Capacity Reporting for non IBM Vendors
On Mon, 14 Sep 2009 10:24:20 +0200 R.S. r.skoru...@bremultibank.com.pl wrote: :Binyamin Dissen pisze: : On Mon, 14 Sep 2009 08:50:02 +0200 R.S. r.skoru...@bremultibank.com.pl : wrote: : :I recant. : :I shouldn't say that IBM is the only honest company. That should be the : :only honest company *I know* . This statement does not preclude other : :companies. : :Obviously I didn't mean PSI, because I had nothing to do with this : :company. However *every* ISV's license agreement I met needed : :negotiation. Not only for the price, but first of all terms and : :conditions. Sometimes it was small change, but sometimes not. : Let me understand this correctly. You accept all IBM boilerplate agreements : with zero negotiation??? :No. :I don't have to look for gotchas. I negotiate prices, but usually not :TsCs. Please present some examples of a gotchas that are unique to ISVs. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: Sub Capacity Reporting for non IBM Vendors
I don't have to look for gotchas. I negotiate prices, but usually not TsCs. Boy! Are you naive! TC are negotiable! - Too busy driving to stop for gas! -- 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: Sub Capacity Reporting for non IBM Vendors
Ted MacNEIL pisze: I don't have to look for gotchas. I negotiate prices, but usually not TsCs. Boy! Are you naive! TC are negotiable! I'm not naive. I know that TsCs are negotiable, as everything in business. It is strange: when I complained about IBM on the list, I was scolded. Now I said something positive and I'm again scolded. What I wrote is my (non-sponsored) opinion, based on some (mine and others) experience. It wasn't my goal to convince anyone of anything. EOT -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- 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: Sub Capacity Reporting for non IBM Vendors
Peter, Yes, all SMF records are written by SMF. However, it is system programs or application programs that request SMF to write them. I know of many vendor programs that request the writing of various SMF records, and type 89 is no exception. Any program could set up the application oriented part of the SMF record and then request the SMF system to write it as a type 89. I have run into problem situations where a vendor program has requested the writing of an SMF record with an ID used by some other area and there have been conflicts, so the program requesting the particular SMF record does have to follow some standards. I do know for a fact that IBM's CPCS and imaging software packages cause type 89 records to be written. I've had to process them through a special program supplied by that area of IBM for the last 4 years. That program creates reports in csv file format that I then send into IBM so they can determine the charges for our CPCS and imaging processing for the next year. Those charges are based on the number of items that are processed in those systems. Tom Kelman Enterprise Capacity Planner Commerce Bank of Kansas City (816) 760-7632 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Peter Relson Sent: Saturday, September 12, 2009 8:00 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Sub Capacity Reporting for non IBM Vendors A vendor could write SMF Type 89 records that record something other than MSUs. IBM actually does this with their Check Processing Control System (CPCS) and imaging software. Those products write Type 89 records that record the number of items processed. It seems really unlikely that anyone would write their own SMF type 89 records (especially IBM). But perhaps you know something I don't. SMF 89 records are not written by applications. They are written by SMF. Only by SMF. SMF 89 subtype 2 records (which is what is really being talked about in the SCRT discussion) are written by SMF based on information associated with the product registration service (IFAEDREG). SMF 89 subtype 1 records are written by SMF based on information provided by applications using IFAUSAGE. Peter Relson z/OS Core Technology Design -- 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 * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- 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: Sub Capacity Reporting for non IBM Vendors
What is said here might be true for those products that are doing sub-capacity pricing based on MSUs. They just need to register/deregister their product to write the MULC data. However, as I said in a previous post, I know that the IBM CPCS and imaging software cause SMF89 records to be written so those products can be priced based on the number of items processed by the products. I don't think that can be done by registering the product to write the MULC data. I have to process these records through a program to create reports to send to IBM each year. By the way, I also know that this was in place before the present sub-capacity pricing process was in place for the subsystems like CICS and DB2. I started to process these records at a previous job in 2000 or earlier. Tom Kelman Enterprise Capacity Planner Commerce Bank of Kansas City (816) 760-7632 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Saturday, September 12, 2009 3:50 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Sub Capacity Reporting for non IBM Vendors Scott Barry wrote: CA Common Services (CAIRIM) is writing SMF 89 data today, contributing to SMF 89 and MULC (SMF type 30) analysis and reporting for many of its software products. This effort came about in the past year's time- frame, having been revealed (remember - CA does not announce futures!) at CA World 2007. The product identification is delivered by CA as a PTF, if interested, to resolve the individual product names based on their CA LMP key identification. I think what Peter is saying is that such records are most likely NOT being created by CAIRIM. That is, it's unlikely that any CA-written code formats an SMF89 record and calls the SMFWTM service to write it to SMF. It's far more likely that CAIRIM simply uses the IFAEDxxx services to register/deregister their products and/or IFAUSAGE to write MULC data. Those actions will indirectly cause SMF89s to be produced. That's what our products do. I suspect, that's what they do too... Correct me if I'm wrong... -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.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 * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- 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: Sub Capacity Reporting for non IBM Vendors
In a message dated 9/14/2009 1:51:24 A.M. Central Daylight Time, r.skoru...@bremultibank.com.pl writes: company. However *every* ISV's license agreement I met needed negotiation. Not only for the price, but first of all terms and conditions. Sometimes it was small change, but sometimes not. IBM's billing systems used to be just the pits. Dups, retreads, and drops were common practice. When they outsourced marketing to third party it got really slovenly with third party contracts and more serial numbers for services. The cash cows, confusion and pricing did a lot to drive us away from IBM top to bottom. Third party have been caveat emptor for ages. John Anderson started the isvcosts list several years ago it's an end-user only forum to note problems and concerns. Seems like today management by magazine and instant gratification supercede technical competence and engineering synergy. -- 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: Sub Capacity Reporting for non IBM Vendors
Let's face it: some vendors are very fair and accomodating while others have practices that can only be characterized as predatory. I've dealt with both kinds. -- 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: Sub Capacity Reporting for non IBM Vendors
--snip-- Let me understand this correctly. You accept all IBM boilerplate agreements with zero negotiation??? -unsnip If so, I want whatever it is that he's smoking! :-) -- 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: Sub Capacity Reporting for non IBM Vendors
That's all well and good. However, I just did a D PROD,STATE on my systems and several products - CPCS, the imaging software, CICS, DB2, and MQ - are not in this list, but they are all producing SMF Type89 records. The ones for CICS, DB2, and MQ are run though SCRT every month to produce the reports for IBM sub-capacity pricing. So it appears that this is not necessarily required to get the SMF Type 89 records. Tom Kelman Enterprise Capacity Planner Commerce Bank of Kansas City (816) 760-7632 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Monday, September 14, 2009 10:39 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Sub Capacity Reporting for non IBM Vendors Kelman, Tom wrote: What is said here might be true for those products that are doing sub-capacity pricing based on MSUs. They just need to register/deregister their product to write the MULC data. However, as I said in a previous post, I know that the IBM CPCS and imaging software cause SMF89 records to be written so those products can be priced based on the number of items processed by the products. I don't think that can be done by registering the product to write the MULC data. 1) SMF89.1 records contain resource usage information. See IFAUSAGE service. 2) SMF89.2 records contain product usage information. See IFAEDREG and IFAEDDRG services. These services, and the IFAURP report program, are described in z/OS MVS Product Management: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2r130/ -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.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 * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- 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: Sub Capacity Reporting for non IBM Vendors
Let's face it: some vendors are very fair and accomodating while others have practices that can only be characterized as predatory. I've dealt with both kinds. So have I. As a Capacity Analyst, I have been more involved in costing, than I've ever wanted to be. I knew this was going to happen as soon as IBM introduced tiered pricing in 1984. The issue from Roland's post was not whether there were good, bad, or indifferent. Rather, it was his statement was IBM is good, and everybody else was bad. I can, from direct experience, state (unequivically) that I know two ISV's that (imo) Data21 (ZIP/390), and VANGUARD, are excellent vendors, in support, marketting cost, along with product capability. I can name two that are horrible, in my opinion, suck. But, with today's libel laws, I shall not publicly. - Too busy driving to stop for gas! -- 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: Sub Capacity Reporting for non IBM Vendors
Kelman, Tom wrote: What is said here might be true for those products that are doing sub-capacity pricing based on MSUs. They just need to register/deregister their product to write the MULC data. However, as I said in a previous post, I know that the IBM CPCS and imaging software cause SMF89 records to be written so those products can be priced based on the number of items processed by the products. I don't think that can be done by registering the product to write the MULC data. 1) SMF89.1 records contain resource usage information. See IFAUSAGE service. 2) SMF89.2 records contain product usage information. See IFAEDREG and IFAEDDRG services. These services, and the IFAURP report program, are described in z/OS MVS Product Management: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2r130/ -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.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: Sub Capacity Reporting for non IBM Vendors
Kelman, Tom wrote: That's all well and good. However, I just did a D PROD,STATE on my systems and several products - CPCS, the imaging software, CICS, DB2, and MQ - are not in this list, but they are all producing SMF Type89 records. The ones for CICS, DB2, and MQ are run though SCRT every month to produce the reports for IBM sub-capacity pricing. So it appears that this is not necessarily required to get the SMF Type 89 records. Right. The DISPLAY PROD command is for products that use IFAEDREG and IFAEDDRG. Products that use IFAUSAGE do not appear there. SMF 89.1 records were being produced for IFAUSAGE long before the product registration concept was envisioned. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.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: Sub Capacity Reporting for non IBM Vendors
Edward Jaffe pisze: [...] Such tactics do not work with IBM. Reagan's Trust but Verify applies. They have an elaborate (almost Rube Goldberg-like) system in place to monitor and report usage. Yes and no. IBM is one of very few companies which do not use execution keys. I don't know any IBM product which would be key-protected or protected in any other way. For software products that still use the old monthly rental model, that system determines the monthly rental price due. For newer products, using IPLA contracts where you license x amount of capacity and pay an annual service subscription fee, the system monitors usage to ensure customers don't exceed their entitled capacity. Exceeding your entitlement constitutes an order for more capacity. It's all very automated and, for the most-part, prices are non-negotiable. Like the power company, you pay for what you get and you get what you pay for. Prices are *usually* non-negotiable, but I know some case of discount for MLC products. BTW: Usually the products are non-replaceable as well. There is no ISV version of z/OS or CICS. (some good words about IBM) It is also worth to mention that IBM is the only company which is not try to catch the customer. I read several horror stories on this forum, on ISVcosts list, from own experience - almost any other company presents license agreements that HAVE to be negotiated. Only IBM's license agreemenst are let's say FAIR. No excessive costs of upgrade, SS, etc. BTW: I didn't say 'CA' g -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- 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: Sub Capacity Reporting for non IBM Vendors
R.S. wrote: It is also worth to mention that IBM is the only company which is not try to catch the customer. I read several horror stories on this forum, on ISVcosts list, from own experience - almost any other company presents license agreements that HAVE to be negotiated. Only IBM's license agreemenst are let's say FAIR. No excessive costs of upgrade, SS, etc. BTW: I didn't say 'CA' g You're statements that: IBM is the only company which is not try to 'catch' the customer and Only IBM's license agreemenst are let's say FAIR [SIC]--which I will paraphrase, since you are a non-native English speaker, to mean: IBM is the only honest mainframe software company are highly insulting and patently false. You might have read so-called horror stories. And, you might have your own anecdotal negative experiences. But, I know for an ABSOLUTE FACT you are NOT a customer of Phoenix Software International. Your assertions, therefore, should not and cannot apply to us or any other software providers with whom you do not do business. (I suspect there are *dozens* of them--some who freely contribute their time and expertise to this list!) Your statements are unfair, inaccurate, subjective opinion presented as fact, and ought to be recanted... -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.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: Sub Capacity Reporting for non IBM Vendors
It is also worth to mention that IBM is the only company which is not try to catch the customer. BS! Which planet are you from? I read several horror stories on this forum, on ISVcosts list, from own experience - almost any other company presents license agreements that HAVE to be negotiated. I can tell you IBM licencing problems just as scary as your supposed ISV-Horror stories! One happened when I worked for IGS (an IBM subsiduary). We were using CBU, and did a disaster test one weekend. When IBM billing saw the billing for that month, they wanted to charge us for a 1C5, instead of a 1C2, for the entire month. And, they were part of the group that we negotiated the whole CBU arrangement with. Then there was the time, at another company, as IBM customers, they came in to help us 'rationalise' our billing, to ensure that what we thought we had, and what they thought we had, matched. This was about the time MSU-based pricing came in. The audit was to rationalise, not penalise, or so we were told. When we saw the first bill after that, we saw penalties! So, don't tell me IBM is the only fair software vendor! I can name at least three VERY fair ISVs, and one VERY UNFAIR one, without even breathing hard! Also, if I were an ISV, I'd take a lot of umbridge against your biased and libelous statements! - Too busy driving to stop for gas! -- 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: Sub Capacity Reporting for non IBM Vendors
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Monday, 14 September 2009 7:06 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Sub Capacity Reporting for non IBM Vendors R.S. wrote: It is also worth to mention that IBM is the only company which is not try to catch the customer. I read several horror stories on this forum, on ISVcosts list, from own experience - almost any other company presents license agreements that HAVE to be negotiated. Only IBM's license agreemenst are let's say FAIR. No excessive costs of upgrade, SS, etc. BTW: I didn't say 'CA' g Edward Jaffe replied: Your statements are unfair, inaccurate, subjective opinion presented as fact, and ought to be recanted... Totally agree!!! Stephen Mednick Computer Supervisory Services Sydney, Australia -- 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: Sub Capacity Reporting for non IBM Vendors
Your statements are unfair, inaccurate, subjective opinion presented as fact, and ought to be recanted... Totally agree!!! I'm a customer AND I totally agree, as well! - Too busy driving to stop for gas! -- 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: Sub Capacity Reporting for non IBM Vendors
A vendor could write SMF Type 89 records that record something other than MSUs. IBM actually does this with their Check Processing Control System (CPCS) and imaging software. Those products write Type 89 records that record the number of items processed. It seems really unlikely that anyone would write their own SMF type 89 records (especially IBM). But perhaps you know something I don't. SMF 89 records are not written by applications. They are written by SMF. Only by SMF. SMF 89 subtype 2 records (which is what is really being talked about in the SCRT discussion) are written by SMF based on information associated with the product registration service (IFAEDREG). SMF 89 subtype 1 records are written by SMF based on information provided by applications using IFAUSAGE. Peter Relson z/OS Core Technology Design -- 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: Sub Capacity Reporting for non IBM Vendors
R.S. wrote: It is possible to convince vendor that some LPAR never exceeds xxx MIPS/MSU and no checking is done. Despite of CPU upgrades. And of course it is possible to convince vendor that their product is being used only on that LPAR. It is sometimes possible to convince vendor that we use their product on every LPAR, but MSU base is not related to product usage. Effect: flat price, MSU independent, (MIPS, LPAR, footproint, etc.) independent. Such tactics do not work with IBM. Reagan's Trust but Verify applies. They have an elaborate (almost Rube Goldberg-like) system in place to monitor and report usage. For software products that still use the old monthly rental model, that system determines the monthly rental price due. For newer products, using IPLA contracts where you license x amount of capacity and pay an annual service subscription fee, the system monitors usage to ensure customers don't exceed their entitled capacity. Exceeding your entitlement constitutes an order for more capacity. It's all very automated and, for the most-part, prices are non-negotiable. Like the power company, you pay for what you get and you get what you pay for. This is the road toward a world of buzz words like dynamic provisioning, Software as a Service, cloud computing, and so forth... It would not be that difficult to extend this system to cover the entire System z software ecosystem by simply generalizing the existing report generator. (If it was my project, I could easily have it designed, coded, tested, and in-place in time for the next release.) Unfortunately, in this case all the work must be done by IBM. And, they are a customer requirement-driven organization... -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.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: Sub Capacity Reporting for non IBM Vendors
On Sat, 12 Sep 2009 08:59:36 -0400, Peter Relson rel...@us.ibm.com wrote: A vendor could write SMF Type 89 records that record something other than MSUs. IBM actually does this with their Check Processing Control System (CPCS) and imaging software. Those products write Type 89 records that record the number of items processed. It seems really unlikely that anyone would write their own SMF type 89 records (especially IBM). But perhaps you know something I don't. SMF 89 records are not written by applications. They are written by SMF. Only by SMF. SMF 89 subtype 2 records (which is what is really being talked about in the SCRT discussion) are written by SMF based on information associated with the product registration service (IFAEDREG). SMF 89 subtype 1 records are written by SMF based on information provided by applications using IFAUSAGE. Peter Relson z/OS Core Technology Design CA Common Services (CAIRIM) is writing SMF 89 data today, contributing to SMF 89 and MULC (SMF type 30) analysis and reporting for many of its software products. This effort came about in the past year's time-frame, having been revealed (remember - CA does not announce futures!) at CA World 2007. The product identification is delivered by CA as a PTF, if interested, to resolve the individual product names based on their CA LMP key identification. Scott Barry SBBWorks, Inc. -- 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: Sub Capacity Reporting for non IBM Vendors
Scott Barry wrote: CA Common Services (CAIRIM) is writing SMF 89 data today, contributing to SMF 89 and MULC (SMF type 30) analysis and reporting for many of its software products. This effort came about in the past year's time-frame, having been revealed (remember - CA does not announce futures!) at CA World 2007. The product identification is delivered by CA as a PTF, if interested, to resolve the individual product names based on their CA LMP key identification. I think what Peter is saying is that such records are most likely NOT being created by CAIRIM. That is, it's unlikely that any CA-written code formats an SMF89 record and calls the SMFWTM service to write it to SMF. It's far more likely that CAIRIM simply uses the IFAEDxxx services to register/deregister their products and/or IFAUSAGE to write MULC data. Those actions will indirectly cause SMF89s to be produced. That's what our products do. I suspect, that's what they do too... Correct me if I'm wrong... -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.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: Sub Capacity Reporting for non IBM Vendors
Edward Jaffe pisze: [...] IBM SCRT does not support ISV products. Period. Why? SCRT is based on two records: a) CPU utilization (SMF72 afaik) b) products launched (SMF89) Record 72 reporting does not require any change - so ISV would know what the 4HRA was on each LPAR. There is still no report about LPARs where the product was used. ISV has the following possibilities: 1. Simply trust customer and rely on customers declaration 2. Change the product to write their own SMF89 (or rather add a section to it). 3. Change the product to create custom SMF record and create own reporting tool. The tool may analyze SMF72 as well otherwise two reports will be sent to ISV: SCRT for utilization information and ISV-SCRT for product information. 4. Tie the product to given LPAR name. This is what some vendors already do. Not only CPC serial is checked, but also LPAR id or LPAR name. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- 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: Sub Capacity Reporting for non IBM Vendors
I thought it was Type 70 rather than Type 72. (70 is CPU, 72 is Workload.) Being in IBM Software Group I suppose I ought to pay more attention to software pricing. :-) Martin Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter ID: MartinPacker They're figuring out that collaboration isn't a productivity hit, it makes them smarter. Sam Palmisano on BlogCentral, 26 November 2008 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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: Sub Capacity Reporting for non IBM Vendors
Martin Packer pisze: I thought it was Type 70 rather than Type 72. (70 is CPU, 72 is Workload.) Being in IBM Software Group I suppose I ought to pay more attention to software pricing. :-) Yes, it is SMF70. I haven't checked before writing. However it is irrelevant for the main topic. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- 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: Sub Capacity Reporting for non IBM Vendors
Kelman, Tom wrote: A vendor could write SMF Type 89 records that record something other than MSUs. IBM actually does this with their Check Processing Control System (CPCS) and imaging software. Those products write Type 89 records that record the number of items processed. I have to run those Type 89 records through a special program near the end of the year and send reports to IBM to determine the charges for the products for the next year based on the number of items processed. The upshot is that any vendor could have its software write TYPE 89 records with any kind of costing metric recorded in them, and then have a program to process that and report on it. SMF 70 records have the information needed to compute peak monthly R4HA. SMF89 is used by SCRT only to keep track of when a product was active, to know whether the associated R4HA CPU samples should be considered, when calculating the peak monthly R4HA. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.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: Sub Capacity Reporting for non IBM Vendors
Vendors also use these reports to validate the size of the LPAR that products run in. It would be nice if IBM would allow non-IBM products to participate in the SCRT. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Friday, September 11, 2009 SYSN 10:19 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Sub Capacity Reporting for non IBM Vendors R.S. wrote: Edward Jaffe pisze: [...] IBM SCRT does not support ISV products. Period. Why? SCRT is based on two records: a) CPU utilization (SMF72 afaik) b) products launched (SMF89) [I know you mean SMF 70.] The above is only partially true. SCRT has a hard-coded list of supported products inside. (Browse the module under ISPF to find their names.) These are the only products for which SCRT reporting is possible. If you don't believe me, try writing your own program that uses the IFA macros to generate SMF89 records and see what you see on SCRT. Hint: you will see NOTHING. SCRT reports the monthly peak R4HA for each of the supported IBM products only. If the ISV and customer agree that the ISV product is tied to one of the supported IBM products, everywhere it runs, then the SCRT report *can* be used by the ISV to verify the customer's entitled capacity has not been exceeded. (See IBM's IPLA contracts for how this works.) If the ISV product is not tied to any supported IBM product or runs in a subset of LPARs, there are no applicable fields on the (normal) SCRT report that can be used to do this verification. It is possible for the customer to run SCRT again, using the SMF records from the subset of LPARs in which the ISV product is licensed, to get a peak monthly R4HA for that subset of LPARs. With this approach, the customer must agree that the ISV product is assumed to be running 24x7 and, therefore, tied to z/OS itself. SMF89, which is used by SCRT to know when a product is actively being used, is useless in this and all other scenarios when considering products that are not listed in SCRT's hard-coded internal list of products. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.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: Sub Capacity Reporting for non IBM Vendors
R.S. wrote: Edward Jaffe pisze: [...] IBM SCRT does not support ISV products. Period. Why? SCRT is based on two records: a) CPU utilization (SMF72 afaik) b) products launched (SMF89) [I know you mean SMF 70.] The above is only partially true. SCRT has a hard-coded list of supported products inside. (Browse the module under ISPF to find their names.) These are the only products for which SCRT reporting is possible. If you don't believe me, try writing your own program that uses the IFA macros to generate SMF89 records and see what you see on SCRT. Hint: you will see NOTHING. SCRT reports the monthly peak R4HA for each of the supported IBM products only. If the ISV and customer agree that the ISV product is tied to one of the supported IBM products, everywhere it runs, then the SCRT report *can* be used by the ISV to verify the customer's entitled capacity has not been exceeded. (See IBM's IPLA contracts for how this works.) If the ISV product is not tied to any supported IBM product or runs in a subset of LPARs, there are no applicable fields on the (normal) SCRT report that can be used to do this verification. It is possible for the customer to run SCRT again, using the SMF records from the subset of LPARs in which the ISV product is licensed, to get a peak monthly R4HA for that subset of LPARs. With this approach, the customer must agree that the ISV product is assumed to be running 24x7 and, therefore, tied to z/OS itself. SMF89, which is used by SCRT to know when a product is actively being used, is useless in this and all other scenarios when considering products that are not listed in SCRT's hard-coded internal list of products. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.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: Sub Capacity Reporting for non IBM Vendors
A vendor could write SMF Type 89 records that record something other than MSUs. IBM actually does this with their Check Processing Control System (CPCS) and imaging software. Those products write Type 89 records that record the number of items processed. I have to run those Type 89 records through a special program near the end of the year and send reports to IBM to determine the charges for the products for the next year based on the number of items processed. The upshot is that any vendor could have its software write TYPE 89 records with any kind of costing metric recorded in them, and then have a program to process that and report on it. Tom Kelman Enterprise Capacity Planner Commerce Bank of Kansas City (816) 760-7632 Why? SCRT is based on two records: a) CPU utilization (SMF72 afaik) b) products launched (SMF89) Record 72 reporting does not require any change - so ISV would know what the 4HRA was on each LPAR. There is still no report about LPARs where the product was used. ISV has the following possibilities: 1. Simply trust customer and rely on customers declaration 2. Change the product to write their own SMF89 (or rather add a section to it). 3. Change the product to create custom SMF record and create own reporting tool. The tool may analyze SMF72 as well otherwise two reports will be sent to ISV: SCRT for utilization information and ISV-SCRT for product information. 4. Tie the product to given LPAR name. This is what some vendors already do. Not only CPC serial is checked, but also LPAR id or LPAR name. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- 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: Sub Capacity Reporting for non IBM Vendors
Edward Jaffe pisze: [...] [I know you mean SMF 70.] The above is only partially true. SCRT has a hard-coded list of supported products inside. (Browse the module under ISPF to find their names.) These are the only products for which SCRT reporting is possible. If you don't believe me, try writing your own program that uses the IFA macros to generate SMF89 records and see what you see on SCRT. Hint: you will see NOTHING. I stand corrected. That's stupid IMHO. [rhetorical] Why SCRT does not rely on SMF89 content? SCRT reports the monthly peak R4HA for each of the supported IBM products only. If the ISV and customer agree that the ISV product is tied to one of the supported IBM products, everywhere it runs, then the SCRT report *can* be used by the ISV to verify the customer's entitled capacity has not been exceeded. (See IBM's IPLA contracts for how this works.) If the ISV product is not tied to any supported IBM product or runs in a subset of LPARs, there are no applicable fields on the (normal) SCRT report that can be used to do this verification. It is possible for the customer to run SCRT again, using the SMF records from the subset of LPARs in which the ISV product is licensed, to get a peak monthly R4HA for that subset of LPARs. With this approach, the customer must agree that the ISV product is assumed to be running 24x7 and, therefore, tied to z/OS itself. SMF89, which is used by SCRT to know when a product is actively being used, is useless in this and all other scenarios when considering products that are not listed in SCRT's hard-coded internal list of products. 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. ) BTW: other ways are still valid despite of SMF89 impossibilities. Regards -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- 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: Sub Capacity Reporting for non IBM Vendors
R.S. wrote: 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. ) You could very well be right about this. (And, you probably are. I looked just now and could find nothing to contradict your statement.) In any case, it doesn't change my basic point that SCRT supports only IBM products--no matter if it recognizes their presence on an LPAR from SMF Type 89 records or via customer specification through the NO89 DD statement. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.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: Sub Capacity Reporting for non IBM Vendors
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. We ran into something similar when we convinced an ISV to go to usage base, rather than the entire footprint. The alternative for the vendor was the discontinuation of the licence. Anyway, the product ran under a CIC region that consumed (under peak) less than 3% of the physical processor. So, I implemented an SCRT process for the product. The 4HRA peak was at night (all batch) when the CICS region wasn't even up. My management complained, at first, but I pointed out, while it wasn't perfect, it saved us 180,000USD. - Too busy driving to stop for gas! -- 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
Sub Capacity Reporting for non IBM Vendors
For a non-IBM vendor that does sub-capacity licensing how do you get the data to them? Send them the SCRT .csv file? Send them a number and hope they trust you? Do they actually alter the charges on a monthly basis? If using SCRT data is it product specific (e.g. for a DB2 tool you use SCRT data for DB2) or just based on overall (e.g. z/OS) usage? Or is it some other method altogether? I have a new vendor that I asked the question of sub-capacity licensing and they want me to provide more details on the model. They are unfamiliar with SCRT and sub-capacity/workload licensing but are willing to listen. I have to admit that I currently do not have sub-capacity/workload pricing on any non-IBM products so I just want to get a feel for how it normally works. Thanks all Ken Porowski AVP Systems Software CIT Group E: ken.porow...@cit.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: Sub Capacity Reporting for non IBM Vendors
It would depend on the vendor. I assume that you are currently on VWLC (i.e. sub-capacity) pricing with your IBM software, so you're alreay sending the SCRT reports to IBM. We also have a sub-capacity pricing license with one of our vendors and we just copy them on the SCRT reports. Since the product is an always running, system level product they base their charges on the z/OS MSUs reported, not any of the sub-system MSUs. We don't have one with SAS, but I know their model is that you'd run SAS on a smaller LPAR and they charge you for the size of the LPAR. So, as I said, it depends on the vendor. It the vendor that you're discussing this with hasn't done it before, you're breaking new ground with them. Good luck. Tom Kelman Enterprise Capacity Planner Commerce Bank of Kansas City (816) 760-7632 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ken Porowski Sent: Thursday, September 10, 2009 10:16 AM To: IBM-MAIN@bama.ua.edu Subject: Sub Capacity Reporting for non IBM Vendors For a non-IBM vendor that does sub-capacity licensing how do you get the data to them? Send them the SCRT .csv file? Send them a number and hope they trust you? Do they actually alter the charges on a monthly basis? If using SCRT data is it product specific (e.g. for a DB2 tool you use SCRT data for DB2) or just based on overall (e.g. z/OS) usage? Or is it some other method altogether? I have a new vendor that I asked the question of sub-capacity licensing and they want me to provide more details on the model. They are unfamiliar with SCRT and sub-capacity/workload licensing but are willing to listen. I have to admit that I currently do not have sub-capacity/workload pricing on any non-IBM products so I just want to get a feel for how it normally works. Thanks all Ken Porowski AVP Systems Software CIT Group E: ken.porow...@cit.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 * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- 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: Sub Capacity Reporting for non IBM Vendors
Ken Porowski wrote: For a non-IBM vendor that does sub-capacity licensing how do you get the data to them? Send them the SCRT .csv file? Send them a number and hope they trust you? Do they actually alter the charges on a monthly basis? If using SCRT data is it product specific (e.g. for a DB2 tool you use SCRT data for DB2) or just based on overall (e.g. z/OS) usage? Or is it some other method altogether? I have a new vendor that I asked the question of sub-capacity licensing and they want me to provide more details on the model. They are unfamiliar with SCRT and sub-capacity/workload licensing but are willing to listen. I have to admit that I currently do not have sub-capacity/workload pricing on any non-IBM products so I just want to get a feel for how it normally works. IBM SCRT does not support ISV products. Period. Some ISVs have been able to get customers to agree to tie certain ISV products to SCRT-supported IBM products. For example, they could agree to tie some IMS tool from the ISV to IMS from IBM. With this agreement in place, the same SCRT report sent to IBM can also be sent to the ISV. This works because IMS is supported by SCRT. Some customers will not agree to this marriage. Suppose a customer wants to run the ISV IMS tool in only a subset of LPARs running IMS. Now, the SCRT reports become worthless unless the customer is willing to perform a second SCRT run that includes SMF records from only the subset of LPARs on which the ISV IMS tool is licensed. Multiply this extra work by potentially dozens of ISV products and this can become a considerable burden on the customer. There are people within IBM that would like to enhance SCRT to be able to handle non-IBM products. With just a little bit of work, SCRT's hard-coded product tables could be externalized and generalized and SCRT could be made to produce different sub-reports for different vendors--IBM being just one. But, this work needs justification like all development projects. If customers thought this was an important, and submitted a requirement, this might happen. Otherwise, it's unlikely... -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.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
