In-Depth
How to Cut Mainframe Software Licensing Costs, Part II
IT can choose from a variety of techniques to reduce its mainframe software costs
When it comes to cutting the costs of mainframe software, Big Iron technologists have a pretty big bag of tricks from which they can draw.
Enterprise license agreements (ELA), Workload License Charging (WLC), and sub-capacity pricing are three of the most common, but others abound (see http://www.esj.com/enterprise/article.aspx?EditorialsID=2683).
"We took advantage of the capping of total MSUs by Workload Manager. It's pretty easy to set up a spreadsheet to calculate the monthly costs by MSU level. Management can then select the level of ‘pain’ they are willing to live with on a monthly basis," says Joe Poole, a former mainframe operator with a prominent retailer based in the Northeast.
Poole—who retired from active Big Iron duty in December—offers this advice: "Take a look at the 24-hour requirements of your processor and decide on the MSUs that would be needed to complete your workload. Then, make sure your workload is divided into priorities, the highest being system services, then online and data base, then production batch, and finally test batch. Set the system up with capping turned on at the MSU level decided on earlier, and allow the system to ‘burst’ above that line for short periods of time to get the heaviest processing period done quickly.
"When the four-hour rolling average reaches the preset MSU cap, WLM will start capping—not dispatching—the lowest-priority tasks so that the high-priority work will still get done. At the heaviest times of the year, like year end or tax season, the cap can be raised for one month and reset the next. Likewise, slow months can have a lower cap to save even more money for that one- or two-month [period]."
IT can also find flexibility when playing with the four-hour rolling average, some mainframe technologists say. "Some shops do play games … [with the] four-hour rolling average. I know shops that will slow things way down in their environments to avoid that peak ever getting over a certain point, or capping their LPARs artificially low," says a mainframe operator who asked not to be identified. "I really don’t think companies want to do this to their revenue-generating applications on a particular machine—that’s sort of stupid—but I know of some [shops] that have done something like this."
Other, less tricky, strategies abound. Consider the experience of Steve Thompson, a veteran mainframe technologist who asked that his employer not be named. In the past, Thompson says, he and previous employers used a number of techniques to help minimize their mainframe licensing costs. One of the most sensible, he says, is a "penalty box"—i.e., a single LPAR system that (in terms of cost savings) essentially pays for itself.
"We have what we call a penalty box. Vendors that only charge on a tiered basis, based on the size of the processor, are considered for moving to the small processor. Those that are targeted for immediate move to this box are software products that do not provide value running across all LPARs," he explains.
"A good example is a source management product. The product in question is used by and for a small group of our programmers. Because [charges are] based on size of the processor and not usage, it will be uninstalled from all other systems and installed for use only in the penalty box. In this case, the product’s annual cost will drop over 90 percent."
Other Licensing Options
Another approach is usage-based licensing—although not all vendors support this for every product, Thompson says.
"We do this because we have two different machines. We ask, ‘Why are we paying the max price for a product that under our circumstances is only being used by a small number of people for a specialized purpose?’ So either we get usage-based pricing or we put them on the penalty box," he explains.
There’s the brute force approach, too: actually poring over your vendor software licenses. It might sound onerous, but it, too, can help by yielding significant cost savings.
"We review our licenses—for all the products—periodically," Thompson says. "The idea is, if we are paying for optional features that we aren't using, drop them. If we find that two or more products offer the same functions as optional features of other products, then we see if there is enough interoperablility to drop duplicated functions."
Mainframe veteran Poole, for his part, says his shop managed to save more than a few bucks by periodically looking for new options or alternatives to its existing software assets.
"We also took a look at all the software products we were licensing, both IBM and OEM, and replaced the costly ones with less-expensive software. MacKinney Systems is a great source of inexpensive products with good support," Poole notes.
"A good example is MQSeries, which is touted as the middleware that should tie the organization together, but the costs rise incrementally as you add more nodes. We tied together all of our stores with MQ back to the CICS region that handled point-of-sale and credit authorizations, but the next generation of point-of-sale will not use MQ, so all those annual maintenance costs will go away. That's a big savings."
There’s a lot to be said for resourcefulness and ingenuity, too, says mainframe pro Thompson. For example, he points out, although shops typically license mainframe software for specific purposes, there are almost always ways in which such software can be repurposed, or used simultaneously, for other tasks. "A shop can actually pay for a second box that runs a single LPAR just on the cost savings alone, sometimes for just one product! The next thing one can do is figure out a way to use products that one already has to do more work," he comments.
"If you have a product that has tiered licensing, and can run [it] on a smaller box while serving the same number of people, then move it and only run it on that box. As an example, [imagine] a 3270 session manager. The I/O and CPU workload for 3270 buffer routing is quite small. Why pay for this on your large production boxes when you could offload the running of this one system-level application/utility to a small box?"
Ditto for job scheduling and other automated operations, Thompson continues: why use a dedicated job schedule when that same work can be performed by an automated operations system. "If you have the luxury of being able to offload or shift to another related system, then by all means do it. The cost benefit could more than pay for the labor of setting it up and the same people managing the [automated operations] product could help the production control people when they get stuck," he indicates.
Shop Around
Thompson, like Poole, touts the value of comparative shopping. "We had a product that we thought was a bit expensive to use. We checked around and found a new IBM product did the same job, plus provided us with more functionality for less."
Don’t underestimate the importance of spending money to save money, says Bob Richards, a vice-president and enterprise technologist with a prominent financial institution based in the Southeast. Richards says he’s managed to save his employer a substantial amount of money—measured in double-digit percentages—by implementing WLC and sub-capacity charging.
To get the most out of his investment, Richards says, he’s ponied up the cash for LPAR Capacity and Software Usage Analysis (LCS), a third-party tool from mainframe consultant and developer Al Sherkow, a principal with I/S Management Strategies Ltd. "It is the only [tool] that does IBM mainframe pricing, and even IBM uses him to audit their process," he explains.
"The product has easily paid for itself each year I’ve had it licensed, in some cases two or three times over. The software is terrific for tracking IBM’s whole process for sub-capacity reporting. This is the only tool that does that on the mainframe. It has the capability of reading the very same data as [IBM’s] sub-capacity reporting tool (SCRT). In other words, the data that you load into the sub-capacity reporting tool is the same data that you load into Al’s software."
Sherkow’s LCS is actually more granular than IBM’s SCRT, Richards argues. "It just makes IBM’s reporting more accurate, so much so that I’ve used [Sherkow’s] software and said to IBM as a user comment when I fill out their tool report, ‘I have done deeper analysis of this particular value and have determined that it was inaccurate on your system. Therefore, my value that you should be charging me for is this,’" he comments.
"Those kinds of things have saved real dollars. If you don’t bother to do the reporting, you’re paying full price."