Hi all,

thanks supremely for some interesting, and varied takes, on this thorny 
subject. With thousands of clients in a distributed site, we are losing the 
battle to properly audit the PVU entitlement we require. For a brief second it 
looked like  the client-side reporting of PVU might be our panacea but no. It 
is an estimate as it has to assume what is a client device and what is a client 
to be licensed by PVU. Shame on IBM for constructing a licensing model so unfit 
for purpose.

TBH we are well down the path of despair with this whole issue and the assorted 
replies strongly suggest that we either pay more via the per-TB model, or stick 
with the impossible PVU model. Its not much of a choice, even if we, like 
others, are actively looking at client-side dedupe ( particularly with TSM for 
VE ) and possibly dedupe of Exchange data.

One thing that vexes me, is that it appears that once committed to per-TB 
licensing, you can never reduce the entitlement. If you do succeed in reducing 
your primary pool occupancy, it just seems that can only be used as 'headroom' 
for future growth. That is, you cannot pay for occupancy minus 10% next year 
even if your storage requirements only amount to that. Furthermore, it seems 
that there is a mandatory growth figure of at least 10% ( others have mentioned 
20% ) year on year in the occupancy entitlement - even if you don't or won't 
need it ( for example by pursuing aggressive strategies of dedupe, compression 
and quota management ). That vexes my management too and I fear that we will, 
in the course of the next couple of years, turn our backs on this product as 
soon as we have rolled our own solution. Which will be a shame, as it is a good 
product and we won't be able to recreate it.

Many thanks once again.
Ian Smith
Oxford University
________________________________________
From: ADSM: Dist Stor Manager [ADSM-L AT VM.MARIST DOT EDU] on behalf of Thomas 
Denier [Thomas.Denier AT JEFFERSONHOSPITAL DOT ORG]
Sent: 17 July 2012 16:19
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Moving to TSM Capacity based licensing from PVU - 
experiences

-----Keith Arbogast wrote: -----

>For those who are wavering between that and PVU based, it may help,
>depending on your client mix, to know that the 6.3 client reports
>Processor Vendor, Processor Brand, Processor Type, Processor Model
>and Processor Count. So, one doesn't  need to install the License
>Metric Tool on clients at that level. I'm presuming IBM would accept
>its own determination of that data, and not insist on it coming from
>the LMT.

>From the documentation of the 'query pvuestimate' command in the
Version 6.3 "Administrator's Reference":

    Note: The PVU information reported by Tivoli Storage Manager is
    not considered an acceptable substitute for the IBM License
    Metric Tool.

Thomas Denier,
Thomas Jefferson University Hospital