I can only speak (unofficially) re: IBM software considerations with
Capacity On Demand, but I think you'll be pleased.
1. For MLC, you pay only for the month(s) in which you have increased your
capacity. If you have VWLC (subcapacity MLC) -- as you probably should
with CoD -- you pay only to the extent you raise your caps, and only for
the LPAR(s) that increase.
For example, let's suppose you have two LPARs. Both LPARs are running
64-bit z/OS, both are running DB2 for z/OS, and one is also running CICS
Transaction Server for z/OS. The LPARs are each 50% of the machine, which
is let's say 30 MSUs total. You activate OOCoD for one day, and let's say
your system capacity increases by another 20 MSUs, to 50. You elect to
maintain 15 MSUs in your CICS Transaction Server LPAR, but you have some
extra short-term DB2-oriented standalone batch that you want to run in the
other LPAR, so you raise that LPAR's softcap to 20 MSUs. You send in your
SCRT reports on-time, as usual. Later, when IBM bills for that month,
you'll pay:
35 MSUs for z/OS (+5, not +20)
35 MSUs for DB2 (+5, not +20)
15 MSUs for CICS Transaction Server (no change, not +20)
You'll get some "whitespace" above the softcap (i.e. more than 35 MSUs on a
short-term basis), because the softcap only clamps down on the four hour
rolling averages. If you're not on VWLC (not sending in your SCRT reports)
then you'd pay 50 MSUs for z/OS, DB2, and CICS Transaction Server for that
month in this example. VWLC is a good thing! :-)
The 5 MSU increase for z/OS and DB2 is priced lower than, say, the 11th
through 15th MSUs on your system, because there's a price curve. [Here's
another dimension: if your chargebacks only reflect a fixed, average price,
are you overcharging for this increase? Yes, you are! If you have to use
chargebacks -- and I have very mixed feelings about that -- make sure you
adopt something like a fixed-plus-variable model, and that the chargebacks
are accurate. The typical mainframe shop applies chargebacks (badly) at 2
to 3 times actual costs, simply because they can measure what happens on
the mainframe. Many shops charge near 100% of the data center space and
near 100% of their networking through mainframe chargebacks, when the
mainframe is the smallest and least demanding piece of equipment in the
data center and all the networking, except the final client connections,
are now virtualized with everything else in the data center requiring the
biggest share of the hubs/routers/switches. How is that fair?!?]
2. Most IBM software products are IPLA ("One-Time Charge"). Almost all
the IPLA products are subcapacity-based if you're on VWLC, so VWLC is yet
again a good thing. They may be measured according to total z/OS MSUs
(e.g. Tivoli zSecure Admin), or according to total MLC product MSUs (e.g.
CICS Interdependency Analyzer, DB2 Cloning Tool for z/OS), or according to
the product itself (e.g. WebSphere Application Server for z/OS, which uses
the z/OS MSUs, but only for the LPARs where you have it installed).
Then you have two choices. You can just buy more MSUs as full licenses
(plus subscription and support) outright. Or, if you don't do that, you
can pay IBM "MSU-day" rates. That is, each OTC product actually has a one
day rental part number for precisely this situation. You can see those
part numbers in most (all?) software product announcement letters. Almost
every zOTC product has an MSU-day option.
In this example, if you have Tivoli zSecure Admin, CICS Interdependency
Analyzer, DB2 Cloning Tool for z/OS, and WebSphere Application Server for
z/OS (WAS only in the CICS LPAR), then you'd need, on a temporary or
permanent basis:
35 MSUs for Tivoli zSecure Admin (+5, e.g. 5 MSU-days)
35 MSUs for DB2 Cloning Tool for z/OS (+5, e.g. 5 MSU-days)
15 MSUs for CICS Interdependency Analyzer (no change)
15 MSUs for WebSphere Application Server for z/OS (no change)
Actually, MSUs translate into "Value Units" with OTC products for permanent
licenses, and you round up to the nearest whole Value Unit. Value Units
are a bit "coarser" than MSUs, so you may not actually need more Value
Units with modest MSU increases. (The basic reason they're coarser is IBM
doesn't want to be bothered -- and your purchasing department doesn't
either -- cutting invoices or placing orders for micro-changes. It gets
kind of silly when you're billing $5 or $10 for a mission-critical software
product. MSU-day prices tend to be very small numbers individually -- like
$10 for a day of product X -- but at least IBM can lump those together onto
a single monthly invoice.) The softcap benefit still applies -- you can
get some temporary "whitespace" above the softcap. Also, while MLC
products are priced individually according to single machines or qualifying
Sysplexes, OTC products are aggregated across your entire enterprise. So
if you can lower a softcap (in an appropriate way to an appropriate degree)
on another machine before activating your OOCoD and raising your softcap,
you can in effect transfer the OTC license for that day. It's "total
enterprise Value Units" at any/every four hour rolling average that counts.
In this example there's only one machine, but hypothetically if you could
reduce the CICS LPAR by 2 MSUs let's say, you'd end up with this:
33 MSUs for Tivoli zSecure Admin (+3)
33 MSUs for DB2 Cloning Tool for z/OS (+3)
13 MSUs for CICS Interdependency Analyzer (no change; you already have 15
permanently licensed)
13 MSUs for WebSphere Application Server for z/OS (no change; you already
have 15 permanently licensed)
So you can have various permutations like that, and you might be able to
slide just under another rounded up Value Unit. You can also buy a
mixture: some more perpetual licenses, and some MSU-days. Whatever makes
sense in your particular situation. [And this also points to an
interesting effect of the "technology dividend": when you buy IBM zOTC for
a specific machine, when you upgrade to the next model you'll find that
your existing stash of Value Units should cover more system capacity
("MIPS"), maybe 10% more. You can either take the extra capacity
immediately and pay nothing more for IBM zOTC (and MLC), or you can wait to
grow back up to your Value Units before buying more, or some combination.
Are you reflecting that benefit in your chargebacks? :-)]
A couple other points are worth mentioning:
1. I don't think OOCoD affects your qualification for Parallel Sysplex
aggregation, as long as the deviation is genuinely temporary. So if CoD
throws you out of the "50% rule" for a day, for example, don't worry about
it, unless you think that signals a future, more permanent condition.
2. Previously I talked about IBM Enterprise License Agreements (ELAs).
You'll want to make sure you understand the effect that increasing MLC
would have on your OTC. It's quite possible that it would make sense,
earlier, to opt for increasing your MLC forecast in order to get some OTC
benefits. Take a look at my previous ELA write-up to get some background
on that.
All that said, John, there are some very clear cases where CoD makes
enormous business sense, and they typically involve businesses either with
short duration annual spikes or a truly "once-in-a-lifetime" spike. An
example of the latter that I can think of is when the government changes a
law or regulation, causing a once-only rush of some kind, perhaps to take
advantage of an expiring tax provision. There are also cases where you're
genuinely not sure whether you need the extra capacity or not, or how much
you need, so you can pay much less for a day or two and see how it goes.
And there are things like mergers, when you're buying another company and
you need some extra capacity to load all their data onto your mainframe
overnight, within a certain time window.
CoD, for hardware and software, are attempts to price fairly for the way
businesses work in the real world, to offer flexibility. Everything I
described is published, announced, and standard. You don't have to go
begging to a vendor (IBM anyway) for a "special favor." The z world
changed in 2000, as I'm fond of saying.
There is a flavor of CoD called "Customer Initiated" (CI). I recommend
that almost everyone get that if possible. That gives you (and your
management) full control should the unexpected happen -- or if you just
forecasted badly. :-) It's a prudent contingency feature, pre-negotiated,
and I recommend it. But don't let CoD substitute for what should be a
permanent capacity increase, and, as a general rule, try to avoid buying
anything remotely resembling permanent capacity on N-1 (or older) models.
CoD is a great business tool, but please use it wisely.
Still confused? Fire away, and I'll try to clarify.
- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
E-Mail: [EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
