isham research
This discussion is now obsolete - IBM finally decided to cancel the License Manager project. This project wasted significant amounts of scarce mainframe skill at a time when other urgent projects - such as a StorageTank client/agent for zSeries - are desperately needed. Many of IBM's customers and ISV partners also wasted significant resources of their own on a project that never had any reasonable chance of success.
The License Manager was announced in October 2000, together with a reworked version of Parallel Sysplex License Charges called 'Workload Level Charges'. Although announced together, these are actually two quite separate issues and the latter are now discussed on a separate page.
IBM made a statement at SHARE in San Francisco:
22 August 2002 - At the SHARE conference, IBM restated our committment to the fundamental objectives that led us to develop ILM on z/OS, which are as critical today as when we started:
- Firstly, to deliver a software license management tool to our customers, enabling them to better manage their software inventories, across a heterogeneous IT environment.
- Secondly, to facilitate the delivery of sub-capacity pricing by providing a mechanism to ensure compliance to IBM's software pricing terms and conditions.
The second objective is currently being addressed by the Sub-Capacity Reporting Tool (SCRT).
IBM's goal remains to fulfill both of these objectives, and to ensure the implementation provides flexibility and matches customers' evolving needs. The modifications to Workload License Charge (WLC) announced this past April, and the resulting design changes to ILM, have demonstrated the evolution. IBM continues to investigate the optimal way to deliver on these strategic objectives. Customer feedback remains critical to shaping our plans and, while ILM continues to be plan-of-record, we have not discounted other alternatives. Should there be any changes to our current plan we will update you in 4Q2002.
Text from the Above text from the ILM web page at the time
Note the new emphasis on a heterogeneous solution - the ILM was a single-platform product - and the comment about customers' "evolving" needs, an early sign that the ILM approach was recognised as not ideal.
A summary of the status at present:
Since XSLM has only been implemented in z/OS (See IBM License Manager announcement), it is a good practice to include this clause as you license new products for the new z/OS platforms.What is the purpose of an 'open standard' that is designed by a single vendor and only implemented on their proprietary machine? IBM's own License Use Management tool supports virtually every significant platform in the enterprise space except IBM's proprietary mainframe systems. This makes adoption of ILM on other platforms merely a pious hope.
The first case is no problem, and is probably what most users expect from the ILM.
The third hides a trap - suppose a user combines a 100MSUs CICS/IMS DB workload with a 100MSUs IMS TM/DB2 workload. IMS is now running in a total of 200MSUs - but each of the two base features only needs 100MSUs. How does this work? The outer certificate for IMS contains the capacity definition which is inherited by the multiple bases TM and DB - does this have to be 200 MSUs or 100 MSUs? And what happens if the Intelligent Resource Director intervenes to raise the capacity definition for an outer certificate? Managing a license in which an outer certificate covers execution by multiple base components in separate LPARs would seem to present some interesting challenges.
The second case hides a worse trap yet - if a user consolidates two z/OS systems onto a single WLC complex, the result is a certificate for z/OS base that defines the total capacity used by z/OS. If one of the combined systems uses RMF (a feature of z/OS) then the inner certificate for RMF will inherit the full capacity defined for z/OS - and if the other system being consolidated was licensed for BMC's CMF, IBM might be accused of 'tying'. The real problem is actually in the packaging of z/OS, since the same situation would occur under PSLC - but it would disappear if only capacity definitions in inner certificates could override outer certificates. Compuware's action against IBM already lists tying as a complaint. With some products (e.g., Tivoli Workload Scheduler for z/OS) compound certificates have a perverse effect - the base component is the agent and the controller/engine an optional feature; although only one instance of the latter is required, all LPARs are charged for it.
As well as being an expert on WLC, sub-capacity pricing, ILM and the IRD, the user must now become an expert on software packaging.
Acceptance by third parties has been sparse to the point of embarrassment. Frankly, they're not interested - partly for political reasons, partly for business reasons and partly for practical reasons. Those that have signed up may have reasons that users dislike - one is a company that charges $640 for a package on an Intel server but a breath-taking $91,000 on a zSeries IFL.
The majority of users - excepting perhaps the very largest - don't want it. The original list of sponsors was desperately short of household name support - why should a major e-business company share the concerns of a small provincial government?
One of the major Ts&Cs - the period used for workload averaging - is defined not in the ILM certificate but in z/OS code. It is thus outside the scope of the encryption and protection schema, and can be changed by a PTF. Further - perhaps the greater problem - it is not possible for other vendors to use different averaging periods. This rigid "one size fits all" implementation removes at a stroke a major opportunity for flexibility and effective negotiation, and this alone is enough to rule out the approach for many.
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.
The need for enforcement tools is diminishing - in the current environemt, software piracy is attracting ever more severe penalties. The United Kingdom's Copyright, etc. and Trade Marks (Offences and Enforcement) Act 2002 provides for penalties up to ten years' imprisonment and unlimited fines. Such measures are likely to prove sufficient - at least in developed parts of the world - to discourage piracy, and strict mechanical enforcement may prove superfluous.
At the end of the day, the License Manager itself will deliver little if any benefit to the user. For the majority of users, the Sub-Capacity Reporting Tool is proving perfectly adequate, though many users seem to have developed ancilliary automation. Adopting the License Manager would bring no fiscal advantage, and mainframe users who are asked to jump through hoops need a business case to do so.
Even among users of current (z800, z900) hardware, migration from OS/390 to z/OS is proceeding much more slowly than IBM hoped. The pending imposition of the ILM on z/OS users is quite obviously a factor. Now that IBM has announced 31-bit "accomodation" support for z/OS 1.2 to 1.4 and delayed z/OS 1.5 until 1Q04, the short term future of ILM is once again in doubt.
The initiative has been lost. Had IBM's License Manager been available on plan, users could have been coerced into using it as a prerequisite to Workload Level Charges. Time, tide and hardware product plans wait for no man - WLC is now a reality and the License Manager has become a separate issue. With a working alternative, a development headcount said to be over 100 and serious cost pressures throughout the company, it may be time to wonder if it's worth IBM persisting.
Compound certificates are defined in IBM License Manager: Planning and Customisation - SH19-4528. Unfortunately this can no longer be downloaded - it was withdrawn because of increasing discrepancies with the re-implemented ILM. No date has been given for its replacement.
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.
Older articles are in the archive