isham research

Workload Level Charges - just another scheme?

IBM announced both the IBM Licence Manager and Workload Level Charges (a.k.a. Sub-Capacity Charges) in October 2000. Although announced together, these are actually two quite separate issues. The ILM discussion has now been moved to another page

Since the October 2000 announcement there have been several developments to Workload Level Charges, most recently on 13 May 2003. The general shape of the scheme remains the same:

1. The selection of a four-hour period for averaging purposes is specious. A four-hour average reflects not e-business patterns but legacy usage - the classic "Sophia Loren" double-peak prime shift usage curve in an old-style data centre, and is the principle reason that interest has so far only been expressed by 'data centre' ISVs and not one 'new workload' vendor. E-business peaks, in contrast, come when awareness reaches a major part of the population - a television commercial, a sponsored sporting event or the launch campaign for a new car - not conveniently during a prime shift. Peaks may last for days or weeks rather than hours, and may not recur for months.
2. The four-hour rolling average impacts batch workloads - especially overnight batch. Typically systems are sized to achieve acceptable online response most of the time - this may involve the use of limited overcapacity. Overnight 'batch window' workloads are tuned to exploit all available resources so as to complete in the shortest possible elapsed time. This may cause their utilisation - over a four-hour period - to exceed that of the online workload. Batch systems may thus need to be 'throttled' or artificially braked to stay under the online day's usage ceiling. This is easy enough to do - the workload can be detuned or hard capping can be employed - but it is perverse to reverse the tuning efforts of many decades just to fit in with the whims of software pricers who do not seem to understand data centre realities.
3. Even this algorithm had problems when it was introduced. Most software typically uses more resources during startup than during steady state running - logs are being initialised, buffers primed, nothing has so far been cached, etc. This was leading to LPARS being soft-capped straight after startup because the few 5-minute intervals measured averaged out to high values - so IBM has introduced an APAR (OW55509) that sets empty measurement slots to 1 MSU. This is yet another Band-Aid on a poor design. If detail-level reconciliation of these measurements is ever implemented, this problem will rear its head again.
4. In some countries, religious restrictions may also shift workload patterns to increase utilisation within a four-hour period. Although the user runs the same workload as before, the four-hour peak and therefore the level of charges are higher.
5. Non-variable - or 'fixed' - Workload Level Charges are commonly believed to be set at the equivalent of 86 MSUs. This is not completely true - a significant number are set at very different levels.
6. It also seems that the tongue-in-cheek comment about MSUs in the Devil's IT Dictionary was surprisingly prescient - there are now separate MSU values for software charging and the SRM. Charging uses the MSU values that are announced with the processor - the SRM values are determined somewhat later and may vary from the values originally announced. Restatements are actually very common - LSPR values were restated for the z900 and the same MIPS/MSU values used for the z990. In the latter case this was justified as a "technology dividend" - but it looks very much like IBM regulating the income of ISVs. With the z990, a different issue arises because of the sheer size of the system - presently a physical 32-way with a maximum LPAR size (from September 2004 with z/OS 1.6) of 24 processors, it will be succeeded by a system with at least 54 processors. These huge LPARS exaggerate the MP effect and make the determination of a system's nominal MSU rating an arbitrary process. MSUs - originally developed as a very responsive way of describing the performance of a system, with the value changing every time a processor went on or offline, are now table-derived.
7. WLC is essentially a re-implementation of Parallel Sysplex License Charges and perpetuates the anomalies. One of these is the issue of rounding errors at high MSU levels. At PSLC level 'D' or VWLC '4' and above, the numerical value of the incremental charge in local currency is often expressed as a single integer digit - see 5694-A01 feature 1964 in IBM's April 30 2002 Announcement. This is derived from what is usually a three or four digit base charge, rounded to an integer and then once again multiplied by a three or four digit MSU quantity. The percentage errors this process introduces compared with the use of an intermediate value of (e.g.) three significant places can be significant. The problem is most acute in countries with a high-value currency unit like the EU and the United Kingdom, and less acute in countries with a low-value currency unit, such as Japan.
8. The implementation fundamentally changes the customer/supplier relationship by introducing post-contractual negotiation. To quote IBM:

   Sub-Capacity Reports that reflect a changed product defined capacity will be considered to be orders placed by the customer without further action on the customer's part, and IBM is authorized to make any resulting billing increase or decrease.
   
   Announcement Letter 201-258 - see also Z125-6516-04 4.4

   One German user has asked, only half-jokingly, whether he should train his operators as accountants or his accountants as operators. More seriously - users will have to commit to post-contractual negotiations that have no defined adjudication or appeal process apart from the protagonists - as at present envisaged, IBM's word will be final. If a DASD subsystem explodes in flames and the user is forced into a massive reconstruction, the reason can be confirmed by many agencies and there's no room for argument. What if bad IBM code causes a database corruption that has to be backed out? Less easy to demonstrate. What if it's bad user code or an operational problem? Even less easy to demonstrate. One idea would be for an independent body - such as the Computer Measurement Group - to form a panel of independent performance experts to act as arbitrators.
9. The situation can become complex in a facilities management environment. In some cases, the user may have no direct control over how systems are configured and run, and the FM supplier may have no obligation to exercise best efforts to do this so as to optimise software charges - other considerations such as uptime may have been prevalent when the contract was negotiated. A contract that passes software charges through as incurred but does not define responsibility for optimisation and post-contractual negotiation represents a liability that is hard for an FM user to quantify. This is another area where prior arrangements for arbitration may be useful.

Since the original mistake back at the end of the 1980s, IBM has revised its software charging algorithms many times. On most occasions these changes have been to foster hardware sales, so it is no surprise that those ISVs not benefitting immediately from hardware capacity increases (the 'non-datacentre' ISVs) have not tracked most of these changes.

Other resources on this site include a timeline of IBM pricing strategy announcements and a similar list of Workload Level Charge and License Manager statements by third parties.

Copyright © isham research 2002. May be reproduced as long as acknowledgement is given. May be linked to without restrictions.

Isham Research Home Page