The Sub-Capacity Challenge

Published: August 1, 2006

by Hesh Wiener

IBM offers several software licensing plans for its System z computers, including plans that allow a customer to pay on the basis of capacity used rather than the potential of a whole computer. Sub-capacity pricing is conceptually simple, but in practice it can be complicated and confusing. IBM's often opaque policies frustrate users who would like to gain more control over software costs. It's enough to bring a grown VPDP to tears, and sometimes to migration. But it may be possible to bring sub-capacity pricing and its potential benefits within the grasp of more customers.

Basically, the software fees for products licensed under sub-capacity terms are based on the power, measured in Metered Service Units, or MSU, allocated to the partition in which the products run. So, if an LPAR on a server with total capacity of 50 MSU uses only 5 MSU, the cost for all the software in that partition would be based on the partition's capacity, not the machine's total power. IBM sets the rules for how the capacity of a partition is reckoned, and provides a program, the sub-capacity reporting tool, to gather the usage data on which billing will be based.

IBM also provides quite a bit of supporting documentation to guide the IT personnel who set up a system's partitions. Boiled down, a system's LPAR configuration can be arranged to divide a processor's capacity either proportionally (this LPAR gets 60 percent of the box, the other one gets 40 percent) or absolutely (this LPAR is limited to a capacity of 5 MSU without regard for what is going on elsewhere in the mainframe). The proportional partition management method is the way users balance complex workloads. This method can keep a batch job from crushing an interactive application. The absolute partition management method is the way users put a lid on software costs. This method can keep a software development partition from crushing a software budget.

It all sounds wonderful, but it hasn't caught on quite the way some enthusiasts had hoped. Specifically, there isn't much evidence that sub-capacity pricing is popular among users of the mainframe family where it ought to be very popular, the z800 line.

The z800 series doesn't have the impressive hardware speed granularity of its two successors, the z890 and z9 BC. The line offers four models with governed engine speed, the 0A1, 0B1, 0C1, and 0X2, plus a machine with a reduced speed generic engine plus a full speed Linux engine, the 0E1. Even with these models, the smallest pure mainframe box in the line runs at 80 MIPS and bills for software at a total of 7 MSU. IBM's sub-capacity plans provide for a minimum billing based on 3 MSU.

There are lots of mainframe shops that still run Multiprise 3000 and Multiprise 2000 machines with power well under 80 MIPS or 7 MSU. And in the Multiprise 3000 world, there are quite a few users with 60 MIPS 7060-H30 models who don't need all that speed and don't want to pay software fees for all that processing potential. Some of these shops can afford to move to a new platform that offers less capacity, and they are good prospects for a z9 BC. But plenty of others can't afford the move, perhaps because they don't have money for new equipment, possibly because they don't have funds to pay for the software migration required to take advantage of sub-capacity pricing. IBM's reduced cost software plans apply to 64-bit software; Multiprise machines are all 31-bit systems (and some of them still run 24-bit applications, too).

The least costly forward migration for these shops might be to a z800 that is configured with a working LPAR that is capped at an MSU rating lower than the 13 MSU of a z800 model 2066-0A1. Used z800 machines are cheap these days. So, too, are used disk arrays, a migration requirement for most Multiprise shops because these users currently use internal disk storage, a feature the System z processors do not offer.

The savings available via sub-capacity pricing isn't the same for all eligible software products, but a quick look at a table showing one typical product, the core package for DB2, shows that for many users the potential savings more than justifies a bit of examination. When IBM says sub-capacity pricing can save customers some money, it's not kidding.

There's another catch, but that may be temporary. Some of the shops using small mainframes are VSE sites. VSE software and related middleware is not yet eligible for sub-capacity pricing. These sites are not keen on moving all their applications to z/OS, where sub-capacity pricing is available. When they start taking about big migration costs, they inevitably have to look at alternatives to another mainframe and z/OS. They might ponder moving to a System i platform, which has some characteristics that seem familiar or at least comfortable to mainframe users (including COBOL). Alternatively, they might look at migration to Unix, Linux, or Windows, particularly if they find applications software for any of those environments that suits them. (These machines can use Micro Focus, Fujitsu, or Acucorp COBOL.)

Recently, if belatedly, IBM said it was going to develop technology that allows VSE shops to take advantage of sub-capacity pricing. We have to presume that this will slow migration away from mainframes, but it may not encourage anyone running VSE to quickly move to a new mainframe. First, IBM hasn't put a firm date on its plans for VSE shops. In addition, even when IBM fleshes out its statement of direction with specific facts and cost figures, there's no certainty that IBM's plan will have all the appeal of its promise.

IBM does offer deals on new mainframes that include special software pricing. These deals generally cap software fees for three years. That's fine for customers who are willing to defer a jump in software costs for three years, or who believe that IBM will offer them some way to keep costs under control before their discounts expire. But for users who have had mainframes for a very long time, a three-year cap is quite different from a more-or-less permanent pricing schedule that doesn't have a pricing time bomb for a punch line. A VSE shop that gets a deal with a cap may be willing to bet that IBM will bring in an attractive sub-capacity pricing plan before the capping ends, and that may well be a reasonable chance to take, but most mainframe shops are not big on gambling with the corporation's money. A badly placed bet, or even one that generates uncertainty, is not likely to enhance the career of the computing executive who made the decision.

The option that might satisfy some mainframe shops that are hanging onto their big iron by their fingernails is a combination of a used z800, a used Shark disk array, and a capacity setting that keeps software fees down. The catch is that in practice this might not be possible. It's not entirely clear that IBM will allow a user to run everything in one or more LPARs that use total capacity well under the potential of a machine. I looked over IBM's literature and I didn't see a clear statement that this is possible, but neither did I find any rules that prohibit this. Do you need to add to the mix some kind of placeholder LPAR that in effect runs nothing (or some kinds of null program) to absorb unbilled MSU? Moreover, when it comes down to an actual deal, does IBM make a new z9 as affordable as a used z800 or used z890?

What I would like to do is explain, based on real field experience, just how a mainframe shop used sub-capacity pricing to confine software costs, make upgrades or downgrades a matter of LPAR tuning, and worked out software pricing that was acceptable to the user and to IBM. With that in mind, I would like your help in the form of comments based on your experience. To make it easier for you to share this knowledge, I have set up a nice, anonymous Web page for responses. If you have some relevant experience, or looked into the possibility and concluded it was unsuitable, let me know. I'd like the opportunity to publish some of your comments, and to make things a bit easier in case there's some follow-on interest in the topic; my response page invites you to provide a pseudonym. The page also asks for some real contact information, which, if you provide it, I will hold in confidence.

Thanks in advance for your help.