Home > LCS Software > Customer Comments (this page)

From a Site with Multiple zSeries Processors

The LPAR Capacity and Software Usage Analysis (LCS) tool is installed to process data from five zSeries eServers. LCS provides monthly audits of IBM's Sub-Capacity Report Tool, LCS also provides more accurate determination of MSUs that should be billed; this has reduced software charges at this customer every month since installation. LCS also provides tools and aids to help in tuning and capacity planning. This site feels that LCS more than paid for itself within months of its installation.

An email from one licensee to another prospective licensee

LCS will provide audit capability for SCRT. We don't want the fox in the hen house, unescorted that is.

LCS allows us to model software configurations tuned for maximum cost-savings.

LCS allows us to correct over-charges for sporadically run products such as compilers.

SCRT is a billing tool. We need additional capabilities.

We were willing to spend our money on this tool and service. We think it's quite valuable, especially considering the apparent cost to develop something similar in-house.

Separate Postings on LPAR-PRICING-L

1. To keep the SCRT process audited, I use Al Sherkow's LCS software and it has paid for itself in the resultant billing savings for two years thus far.



2. Al Sherkow's LCS software does an excellent job of accurately pricing the majority of IBM's mainframe products, including the IPLA software. I have that software and use it to successfully audit the SCRT reports that I send every month to IBM. Check out his website for more information. And I know he updates his prices when IBM changes them.



3. I used to get pricing information from IBMLink using the Price390ESW tool. I would enter the product number and optionally, the function ID and it gave me all the various pricing forms. Then I'd bang the numbers into my spreadsheet. It was slow and tedious, but it worked. Then I had to monitor announcements and check for updates. When they added the new bands, they trashed my spreadsheets and I had to rework them all. Now I'm using Sherkow's LCS tool, which provides this information and keeps it up to date.



4. You absolutely want to audit your SCRT numbers. It can save you money. SCRT does rudimentary analysis, using only type 70 and 89 records. It assumes if you specify a product on an LPAR it should be billed for the full amount. We run Sherkow's LCS product and compare to our SCRT reports. We have adjusted SCRT when we discovered lesser (sometimes zero!) utilization of NO89 products.



5. Or you could have gotten Al Sherkow's software and saved yourself a lot of effort.



6. As far as auditing the SCRT and making MSU adjustments based on aberrant system behavior during a "peak" S4HRA, I use LCS from Al Sherkow (www.sherkow.com) to make *honest* adjustments to the SCRT. In my opinion, setting some product's MSU usage to ZERO is wrong unless you can justify it. With LCS, I can justify the values I specify.

Postings on ISVCOSTS

1. Without type 89 records the potential exists to be over charged for software. I know this happens because I run LCS to audit my SCRT reports and periodically find that SCRT wants to over charge on my NO89 software. I insert my overrides in the SCRT reports when this happens.



2. I have used LCS to save real charges in a variety of ways:
   1. Knowing COBOL only runs on two lpars out of six in one of my data centers, I adjust my NO89 parms accordingly. LCS reports a lower MSU value and I use it to report a lower customer MSUs value when I report it to IBM. LCS tells me what the recommended MSU value should be. I save money "monthly" with this one.
   2. Eliminating hourly intervals because of runaway tasks or spin loops. This one bit me last week and pegged a 2084-314. I am going to adjust what I report accordingly. The software was MQSeries and IBM has the fixing PTF as PE. In the very least, I'll pay less for MQSeries than I would have otherwise.
   3. I use LCS to audit the SCRT information.
   4. I can track the simultaneous 4HRA daily, looking for new peaks and determine if next month I can mitigate the effect that caused that peak. Honestly, I am still working on getting this one right. Nothing wrong with LCS, but I need to remember to review and analyze each new peak. Conflicting priorities (like real work...grin) sometimes prevent me from giving this the attention I want to, even if it will save more money.
   
   These are just some of the things I use LCS to analyze. Recently, with Al's assistance and the signing of the sub-cap IPLA agreement, I used LCS to prove to IBM that I did not need to acquire any additional value units for some CPU upgrades and avoided unnecessary upgrade fees of $157,000!
   
   As always, YMMV. But LCS has already proven its worth to me, many times over! And, no, Al has not compensated me for this posting. It is a pure testimonial from one happy customer.

Postings on IBM-MAIN

1. There's a bit of mileage in optimising software charges, but with Software Group running round doing audits and sending retrospective demands - yes, I've seen one in Europe - that's not much fun either. I'll leave that to Al Sherkow - there isn't room for two in that market and the lad does a good job. (from a Consultant, not a Customer)


2. ... if you are concerned with monitoring LPAR capacity and possibly considering workload-based charging (WLC), Al Sherkow's LCS software can provide valuable insight, if you are a licensed SAS and MXG user.


3. To the question: "Does anybody have a URL where I can go to get an overview of the various licensing for z/OS software from IBM?"
   One Reponse: Here is another link you might try --> http://www.sherkow.com/lcs/. I have heard several of Al's presentations and think highly of his knowledge on this subject. (from a Consultant, not a Customer)

Last Updated: Thursday, 28 June, 2007