A brief history of Software Pricing

General Introduction

It was about 13 years ago that they asked me if I was interested in doing the presales for mainframe business. I came from the ‘other’ side since I’d always been engaged in application development as a programmer, an analyst and a DB2 admin. So, at that moment I’d never seen any mainframe hardware whatsoever.  But we had an experienced mainframe sales person at the time who learned me everything there was to learn about ESCON, CHPIDs, OSA-Express cards, CECs etc. etc. And then there was this other part as well : if you wanted (and this hasn’t really changed) to work out a business case, you had to know something about software pricing too.

I still vividly remember my first steps in ‘Software Pricing’ on mainframe or should I rather say my first stumbles. I just looked up the word in a dictionary.

Stumble [stuhm buh l]

1. the act of stumbling (to strike the foot against something, as in walking or running, so as to stagger or fall)

2. a slip or blunder

I can assure you, both meanings were very appropriate at the time.

Just one year later, our experienced sales person took on another opportunity and, just as that, I was no longer the rookie but I was the most experienced mainframe (pre)sales guy in the company. A new sales was appointed for mainframe and of course I was the one introducing him to all this magnificent stuff. Don’t worry, he pulled through with flying colours and we’re still working together.

Still, it’s a bit of a crazy story but we first met just a couple of hours before the official announcement of the z890 in April 2004 (yes, the 40^th anniversary of the mainframe). There was a large IBM and BP event in Paris and he picked me up at my home for a 3-hour drive to Paris. Of course we started talking about the mainframe, comparing with the AS400 (now System i) he knew from his background. And, actually, we never stopped talking for the next three days. After each session new questions popped up and were, as good as possible, answered. Until finally we came to the subject of ‘software pricing’.  What could I say ? The only thing there was to say : “Well, you know, here’s where it gets a bit complicated”. Talking about a euphemism.

And this remained a constant during the years to come. Talking to customers, the questions I most often heard about software pricing were : “Could you freshen up my memory about that, I’m a bit confused ?” usually followed by “Could you explain that once again, I don’t think I’m still following ?”

I really would like to say, luckily things have gotten a lot less complicated over the years, but they haven’t.

So, why am I telling you all this. On November 15, we hosted a meeting for the GSE Young professionals Working Group at our HQ. These are all young mainframers we desperately want to get or to keep aboard of the mainframe ship. And I thought it was a good opportunity to write them a 'short' article on the evolutions we’ve seen over the years in software pricing on the mainframe.

General tendency

To put things into perspective of what we are talking about. We, as a business partner, are often engaged into negotiations on the hardware price of a new system. Mainframe is expensive, remember ? But when the customer starts working out his business case, it’s always played on the software part. Usually software represents 70% or more of the cost when e.g. mapped out on a four year basis. So any decrease in software cost when going to a new generation of mainframe might already make up for the hardware cost.

And this is the general tendency we have seen over the past years. Or should I say : tendencies. On the one hand IBM has always put effort into making the mainframe a competitive platform as compared to other, distributed environments. For a moment now, we’re ignoring all the benefits you get from the platform as is, but we’re purely focusing on the price, let’s say, on the CFO part of the business. You can make it competitive by making sure that the customer is only paying for what he is really using. On the other hand, IBM has made sure that with every new generation of the mainframe, prices were more attractive on the new system. This meant investing in new hardware paid off in the long run with economically more interesting software prices.

And there’s one more tendency, that is predominantly directing software pricing : it is IBM’s intention that you will pay less for new workloads that you introduce to the mainframe rather than installing them on the ‘cheaper’ distributed systems. This is a key factor in remaining competitive with the distributed systems.

Starting off with machine based pricing

When browsing through my (old) documentation, I keep lingering at a document from 2004, the year of the introduction of the z890 : ‘z890 and z800 Software Pricing P-Guide’. One of the first pages headlines ‘What is Sub-Capacity Pricing ?’.  In 2004 sub-capacity pricing is a new term for a pricing mechanism that was introduced for the z900. I know I’m more than generalising throughout this summary in order to give you a clear view of the bigger picture.

Up to then, software pricing was machine based. This meant there was a flat monthly pricing amount according to the model of e.g. your z800 box. But that was always a problem. You don’t buy a mainframe every year and so customers made a three or four year projection of what they needed in the next years and bought their systems accordingly. So, the first years, they only used e.g. 60% of what they had bought but they still had to pay for the entire machine.

But before I continue with this I should give you some more terminology. Software pricing is/was mainly divided into two categories : MLC (Monthly License Charge) and OTC (One Time Charge) pricing.

MLC pricing is a monthly charge you are paying in order to use IBM software. Examples of this is the operating system z/OS (OS/390 at the time) and lots of others like e.g. DB2, CICS, Cobol, IMS . . .  MLC software is paid in terms of numbers of MSUs (Million Service Units). It’s a measurement of the amount of processing work a computer can perform in one hour. This stands in close relationship to the MIPS (Million Instructions Per Second).

OTC, now better known as IPLA (International Program License Agreement), stands for a One Time Charge. You actually buy the software and you can pay an additional Subscription & Support (S&S) fee that also gives you the right to implement future versions at no extra cost. Examples are the operating system z/VM and lots of ‘tools’ like TSM, DB2 Utilities . . .

Enters Sub-capacity pricing

With VWLC (Variable Workload License Charge) IBM introduced the sub-capacity pricing for MLC. This meant that you closely came to pay what you were really using at that moment. Let me elaborate a bit on this, since this hasn’t fundamentally changed since then.

In order to detect what you are actually using, you need a reporting tool. That is SCRT (Sub Capacity Reporting Tool). It registers your usage for an entire month based on SMF records. Some softwares like e.g. z/OS and DB2 generate their own SMF records for this. Others take on the same level as e.g. z/OS. Out of that it will, per software, determine where your peak is for that software during that particular month. Now, you may argue, one test in acceptance that goes completely out of the roof might cause an enormous peak and then I’m penalized for that one moment during that month. Well, IBM took care of that.

The SCRT report determines the peak on a 4 hour rolling average. This means that it always takes an average of the past four hours to determine the height of the workload, so extreme peaks are levelled out. This is illustrated on the graph below for two LPARs. And if you want to make sure, you’re not going above a certain level you can use a mechanism that is known as capping. You can indicate that a certain LPAR (or group of LPARs) must not go beyond a defined level.

In this illustration, partition A’s peak rolling four-hour average is shown to peak at 73 MSUs, during the month. Let’s take z/OS as an example. When it would be running solely in partition A it would have its sub-capacity charges based on that 73 MSU value, although the machine capacity is at 100MSU.  Likewise, partition B’s peak rolling four-hour average is recorded at 52 MSUs. A product running solely in partition B would have its sub-capacity charges based on that 52 MSU value. But since z/OS is running in both LPARs, it will be charged at the combined peak for those LPARs i.e. 98 MSUs. Here we can also illustrate the capping mechanism again : if LPAR B is e.g. a test LPAR you might put up a capping of 45 MSUs and perhaps your combined peak might be lowered to 95 MSUs.

As you can see, the reporting and therefore also the billing is based on MSU’s.

The graph above, also shows you the pricing levels for the MSUs. It indicates that you pay a high price for the first MSU’s. This is an example for VWLC pricing when it was first introduced. The more MSUs you are reporting, the less you pay per MSU for the higher MSUs. As a matter of fact, there’s such a graph for every system and the steps for the smaller systems (z890, z114, zBC9 through z13s) tend to be much smaller. You have expensive 1-3 MSUs and from there on MSUs get less expensive in far smaller steps.

IPLA softwares also have sub-capacity pricing although there are still some softwares that are machine based.  These softwares are usually related to the reporting of some MLC software. If you have a machine of 200 MSU and you report only 150 MSU for DB2, then it’s sufficient to have bought the equivalent of that 150 MSU for the DB2 Cloning Tools or for the DB2 Utilities. 

General price decreases – Technology dividend

So, the stage is set for the following evolutions. The first action taken by IBM is a general one and I already mentioned it before. Customers want to be on a current system, but on the other hand they often postpone buying new systems since there’s no real reason for that. So, with the z990, IBM introduced what is now commonly referred to as the technology dividend. In fact it’s a very simple maneuver that stimulates every customer to at least make the calculation whether it’s beneficial for them to go to the next generation.

When I put ‘price decrease’ in the title, this is not entirely correct. For a specific generation, there’s a correlation between the number of MIPS on that machine and the number of MSUs. This used to be very static, not really changing over the generations. But for the last ten years, we started to call MSUs, software MSUs and the relation with MIPS became less evident. Let me just give you a small table and it will immediately be clear what we mean.

System	Pricing	MIPS	MSU
Z890	EWLC	200	32
Z9 BC	EWLC	200	30
Z10 BC	EWLC	200	25
Z114	AEWLC	200	25
zBC12	AEWLC	200	25
Z13s	AEWLC	200	25

For the first three generations from z890 to z10 BC, for the same amount of processing power, less MSUs were needed to cover it. So, when you had to pay for 32MSUs on a z890, this went down to 25MSs on a z10BC. And I can assure you, for a mainframe customer, this was a huge benefit on their software cost, well worth the investment in the new hardware. This technology dividend was more or less every time a 5% decrease.

From then on, we see that the correlation between MSUs and MIPS stayed the same. But with the z114 a new pricing was introduced. With AEWLC pricing you payed less per MSU as compared to the EWLC pricing on the z10 BC. Another technology dividend but implemented in a different way. And for the last two generations, we saw the same pricing mechanism, but an extra reduction was given per technology step. So, if you look up the official price for 3 MSU for z/OS, it hasn’t changed since the introduction of the z114. But, for the z13s you will have approximately a price reduction on it of about 10%.

General price decreases – New Workloads

The above are pricing decreases every customer could/can enjoy when moving on to the next technology. But, as I already said, IBM is particularly keen on getting new workloads on the mainframe and has gone into great effort doing so.

For those who are familiar with the terms, this started of with zOS.e and zNALC. zNALC is the best known of the two and is still in use nowadays. Let’s focus on that one. zNALC is a pricing mechanism for New Workloads that run on separate machines or in separate LPARs. The benefit is realized very simply : if you can prove that it’s a new workload on your mainframe, answering all the right criteria, your z/OS is only priced at a tenth of the normal pricing. This gives the customer a huge benefit on the software cost since z/OS is one of the most expensive softwares in MLC pricing.

The major drawback of this, is that it has to be a completely isolated workload in a separate environment. Well, now, that was always a bit the weak point of this solution. Say, you have all your data on the mainframe, as so many customers do, and you develop, let’s go modern, an app for your customers who can consult their accounts. What about all the other applications, running in another LPAR, that also have access to that information. This is often very difficult to integrate into your existing environment.

New Workloads – from separated to integrated

That’s why, over the years, IBM has made a lot of efforts to give you the best of both worlds : a better pricing for new workloads, but integrated into the existing environment. One of those efforts was e.g. to bring out a new pricing option for certain softwares like e.g. CICS and DB2. It’s called the Value Unit Edition and it’s basically an equivalent of IPLA software for that product. You buy it once and you pay a Subscription and Support fee for the ‘maintenance’ and the upgrades of the product. This is something every customer has to investigate whether this is beneficial for them or not. The advantage of this, is that the workload remains integrated into your existing environment.

Another initiative that could have impact on your software cost was the introduction of specialty engines. Here we can particularly focus on the zIIP. The zIIP (z Systems Integrated Information Processor) is an additional processor that is added to your system. Specific workloads are offloaded from z/OS to the zIIP. This can be specific DB2 workloads, Java, encryption or XML workloads (you can find a more extensive list over here). Here’s the illustration that is often used to illustrate how the zIIP is working

As you can see, the workload on the general processor is reduced as part of it is now executed on the zIIP. There’s an important caveat to be made here : this will only have an influence on your software cost if this happens during your peak period of the month. If so, here’s another example of how the software cost can go down due to a hardware investment.

New workloads today

Let’s finish off by having a look at the enhancements we recently saw in sub-capacity pricing. The first one was announced about two years ago, the third about two months ago. They have in common that they, again, focus on New Workloads like Mobile or Cloud.

-       Mobile Workload Pricing (MWP)
Used when IBM programs such as CICS, DB2, IMS, MQ, or WebSphere Application Server are processing mobile transactions from phones or tablets,

-       z Systems Collocated Application Pricing (zCAP)
Used when net new instances of IBM programs such as CICS, DB2, IMS, MQ, or WebSphere Application Server are added in support of a new application not previously running on a mainframe server

-       z Systems Workload Pricing for Cloud (zWPC)
Used when IBM programs such as CICS, DB2, IMS, MQ, or WebSphere Application Server are processing transactions from net new public cloud applications

The three have in common that they may reduce the cost of growth for these target applications by potentially reducing the reported peak capacity values for sub-capacity charges. This remains a constant throughout : it must have an impact on year peak reporting, otherwise you’ll see no benefit for your software cost.

Integration of new workloads into your existing environment is one thing, distinguishing which of the workload is new (e.g. mobile “coming from phones or tablets”) is another thing. So, just in case you started to think that I exaggerated at the beginning and you think software pricing isn’t all that complicated, let me explain how Mobile Workload Pricing can influence your reported peak and how the workload is recognized as ‘mobile’ workload. This gives me the opportunity to illustrate all the mechanisms I talked about earlier.

Here’s an illustration on MWP

Click on image for larger version

1. Let’s assume that we are talking about the 4hr rolling average peak for this LPAR. Normally your SCRT tool would report a peak 4hr rolling average of 1.500 MSU. That is, 1.500 for z/OS and 300 for CICS. Maybe this customer is using a zIIP which could already have an influence on the reported peak that would otherwise perhaps have been 1.800 MSUs.
2. For CICS, as we already indicated, 300MSU is reported. That means that for z/OS you will pay for 1.500 MSUs and for CICS you will pay 300 MSUs. Other softwares like DB2 have their own reporting but let’s assume they have the same MSUs as z/OS.
3. Now you have to determine which part of CICS is used for Mobile Transactions and which part is not. This can be a particularly difficult one, since the same transaction might be executed many times, but it can originate from a mobile app or perhaps also from a plain and simple terminal. This is something a customer has to agree upon with IBM and it’s based upon e.g. specific fields of SMF records
4. Based on that, you come to the conclusion that 200 out of the 300 MSUs that are reported by CICS actually have a mobile origin.
   Well, you get a reduction of 60% on that part of the CICS workload reducing that part of 200 MSUs to 80 MSUs.
5. The good news is that for that LPAR, all the software in that LPAR, including z/OS and DB2 get the same reduction. This means that the reported 1.500 MSUs is lowered to 1.380 MSUs.
6. The rest is BAU (Business As Usual), you can use this to determine the peak for that month. It is e.g. possible that at another moment your z/OS reports 1.400 MSUs at a moment that no mobile workload enters the system. This would mean that for that month your peak will be at 1.400 MSUs.

Well, this little example concludes our short walk through Software Pricing history. I might just add one source of information. There’s a very elaborate IBM internet page that explains you utterly everything about software pricing you ever wanted or, perhaps, didn’t want to know. It’s all there for you.

(This was also published in our Realdolmen z Systems newsletter)