Backup Central

Hi,

We are in the midst of discussions on moving to capacity-based licensing from the standard PVU-based method for our site. We have a large number of clients ( licensed via TSM-EE, TDP agents, and on client-device basis ) and around 1PB of primary pool data. As I understand it, there is no published metric for the conversion from PVU to per TB licensing so I would be really interested and grateful if anyone would like to share their experiences of that conversion in a private email to me.

Many thanks in advance.
Ian Smith
Oxford University
England
=

Hi Ian,

As I understood IBM will make an different offer for each customer so that there is a (short term) profit. However on the long term you will pay more to IBM imho since data will grow faster than the number of cores in your servers. After all hardware replacement is done once every 4 years or later on.

The only advantage is that the capacity based licensing is more easy to calculate than the PVU based.

Regards,
Kurt



-----Oorspronkelijk bericht-----
Van: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] Namens Ian Smith
Verzonden: maandag 16 juli 2012 13:13
Aan: ADSM-L < at > VM.MARIST.EDU
Onderwerp: Re: [ADSM-L] Moving to TSM Capacity based licensing from PVU - experiences

Hi,

We are in the midst of discussions on moving to capacity-based licensing from the standard PVU-based method for our site. We have a large number of clients ( licensed via TSM-EE, TDP agents, and on client-device basis ) and around 1PB of primary pool data. As I understand it, there is no published metric for the conversion from PVU to per TB licensing so I would be really interested and grateful if anyone would like to share their experiences of that conversion in a private email to me.

Many thanks in advance.
Ian Smith
Oxford University
England
*** Disclaimer ***
Vlaamse Radio- en Televisieomroeporganisatie
Auguste Reyerslaan 52, 1043 Brussel

nv van publiek recht
BTW BE 0244.142.664
RPR Brussel
http://www.vrt.be/gebruiksvoorwaarden

Ian,
Our company looked into it and thought it may save some $$ and at the
same time simplify the OVERLY complex PVU license model used for
TSM/IBM.

I'll start by saying to make sure you understand what TSM products are
included in the "capacity" license proposal. From memory I don't
remember the exact ones but it does not apply to all TSM licenses. This
obviously means that the capacity license model may be attractive to
some and unattractive to others. Your IBM rep should be able to clarify
this.

Also, in our environment we use a Data Domain backend which as you may
know prefers all incoming data to be uncompressed and unencrypted. Since
the TSM servers have no knowledge of the DD processes it reports the raw
storage numbers before compression and deduplication which negatively
affected the capacity licensing pricing.

We opened discussions on this issue with IBM but they refused to budge
or negotiate an adjustment for the "actual" storage used. Needless to
say that position was not too warmly received and we 86'ed the whole
discussion.

Interestingly, had we used IBM storage/deduplication on the backend they
would use the actual storage, but no such provision for Data Domain.

Good luck....

~Rick


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Ian Smith
Sent: Monday, July 16, 2012 7:13 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: [ADSM-L] Moving to TSM Capacity based licensing from PVU -
experiences

Hi,

We are in the midst of discussions on moving to capacity-based licensing
from the standard PVU-based method for our site. We have a large number
of clients ( licensed via TSM-EE, TDP agents, and on client-device basis
) and around 1PB of primary pool data. As I understand it, there is no
published metric for the conversion from PVU to per TB licensing so I
would be really interested and grateful if anyone would like to share
their experiences of that conversion in a private email to me.

Many thanks in advance.
Ian Smith
Oxford University
England

We recently converted to a special hybrid license that is a combination of
PVU and STG based. We are ~600TB primary occupancy (constantly growing)
but have a lot of high-powered multi-processor systems (in research
computing) so it worked out cheaper (per my guy who does licensing) to go
to the STG/SUR licensing for the smaller/non-research systems backups. The
additional software packages bundled into SUR (no more separate licensing
for TDP products) is an added bonus.

Our hybrid agreement required us to create a separate TSM server for the
PVU licensed nodes, which is ~15% of total occupancy)

On Mon, Jul 16, 2012 at 7:12 AM, Ian Smith <ian.smith < at > oucs.ox.ac.uk> wrote:

Hi,

We are in the midst of discussions on moving to capacity-based licensing
from the standard PVU-based method for our site. We have a large number of
clients ( licensed via TSM-EE, TDP agents, and on client-device basis ) and
around 1PB of primary pool data. As I understand it, there is no published
metric for the conversion from PVU to per TB licensing so I would be really
interested and grateful if anyone would like to share their experiences of
that conversion in a private email to me.

Many thanks in advance.
Ian Smith
Oxford University
England




--
*Zoltan Forray*
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray < at > vcu.edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html

This has been our experience too. We've been running TSM for six years,
and in that time, the number of systems has gone up 4x, the number of
CPUs has gone up about 10x, and the amount of primary backup/archive
data has gone up 50x. We're sticking with the core-based PVU licensing
as long as we can.

-- Skylar Thompson (skylar2 < at > u.washington.edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine

On 07/16/12 05:23 AM, BEYERS Kurt wrote:
Hi Ian,

As I understood IBM will make an different offer for each customer so that there is a (short term) profit. However on the long term you will pay more to IBM imho since data will grow faster than the number of cores in your servers. After all hardware replacement is done once every 4 years or later on.

The only advantage is that the capacity based licensing is more easy to calculate than the PVU based.

Regards,
Kurt



-----Oorspronkelijk bericht-----
Van: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] Namens Ian Smith
Verzonden: maandag 16 juli 2012 13:13
Aan: ADSM-L < at > VM.MARIST.EDU
Onderwerp: Re: [ADSM-L] Moving to TSM Capacity based licensing from PVU - experiences

Hi,

We are in the midst of discussions on moving to capacity-based licensing from the standard PVU-based method for our site. We have a large number of clients ( licensed via TSM-EE, TDP agents, and on client-device basis ) and around 1PB of primary pool data. As I understand it, there is no published metric for the conversion from PVU to per TB licensing so I would be really interested and grateful if anyone would like to share their experiences of that conversion in a private email to me.

Many thanks in advance.
Ian Smith
Oxford University
England
*** Disclaimer ***
Vlaamse Radio- en Televisieomroeporganisatie
Auguste Reyerslaan 52, 1043 Brussel

nv van publiek recht
BTW BE 0244.142.664
RPR Brussel
http://www.vrt.be/gebruiksvoorwaarden

I'm a little surprised by this, as the TSM macros you run to calculate the storage don't know (or care) about the storage device, i.e., they just report the uncompressed storage amount:

https://www-304.ibm.com/support/docview.wss?uid=swg21500482&wv=1

That said, if you are running TSM deduplication, that *is* reported with the macros, so there would be a cost saving. Was IBM talking about a discount for ProtecTier, maybe?

Steve

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of Rick Adamson
Sent: Monday, July 16, 2012 8:44 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: [ADSM-L] Moving to TSM Capacity based licensing from PVU - experiences

Ian,
Our company looked into it and thought it may save some $$ and at the same time simplify the OVERLY complex PVU license model used for TSM/IBM.

I'll start by saying to make sure you understand what TSM products are included in the "capacity" license proposal. From memory I don't remember the exact ones but it does not apply to all TSM licenses. This obviously means that the capacity license model may be attractive to some and unattractive to others. Your IBM rep should be able to clarify this.

Also, in our environment we use a Data Domain backend which as you may know prefers all incoming data to be uncompressed and unencrypted. Since the TSM servers have no knowledge of the DD processes it reports the raw storage numbers before compression and deduplication which negatively affected the capacity licensing pricing.

We opened discussions on this issue with IBM but they refused to budge or negotiate an adjustment for the "actual" storage used. Needless to say that position was not too warmly received and we 86'ed the whole discussion.

Interestingly, had we used IBM storage/deduplication on the backend they would use the actual storage, but no such provision for Data Domain.

Good luck....

~Rick


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of Ian Smith
Sent: Monday, July 16, 2012 7:13 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: [ADSM-L] Moving to TSM Capacity based licensing from PVU - experiences

Hi,

We are in the midst of discussions on moving to capacity-based licensing from the standard PVU-based method for our site. We have a large number of clients ( licensed via TSM-EE, TDP agents, and on client-device basis
) and around 1PB of primary pool data. As I understand it, there is no published metric for the conversion from PVU to per TB licensing so I would be really interested and grateful if anyone would like to share their experiences of that conversion in a private email to me.

Many thanks in advance.
Ian Smith
Oxford University
England

I've had a couple of customers look at capacity-based licensing, ditto what the other folks said. IBM will make a different offer to each customer, which supposedly takes into account the conversion of your existing licenses.

I have one customer who only keeps their backups 2 weeks (really, really short), but they back up over 250 systems, lots of TDP for SQL agent, total of only about 80 TB in primary storage. They definitely would come out better switching to capacity-based.

I have another customer who backs up less than 100 clients, but keeps everything 6 months, they are over 300 TB primary storage. Better off sticking with PVU-based.

However, some customers may also come out better with capacity-based licensing, because it includes all the TDP's and TSM for VE; some might use it as a quick and dirty way to pick up more products with no additional cost.

So you just have to look at your own circumstances and figure out where the growth is; if you are already at 1 PB, my guess is you will NOT come out better going to the capacity-based license, but can't say for sure.

W

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of Ian Smith
Sent: Monday, July 16, 2012 7:13 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: [ADSM-L] Moving to TSM Capacity based licensing from PVU - experiences

Hi,

We are in the midst of discussions on moving to capacity-based licensing from the standard PVU-based method for our site. We have a large number of clients ( licensed via TSM-EE, TDP agents, and on client-device basis ) and around 1PB of primary pool data. As I understand it, there is no published metric for the conversion from PVU to per TB licensing so I would be really interested and grateful if anyone would like to share their experiences of that conversion in a private email to me.

Many thanks in advance.
Ian Smith
Oxford University
England

Steve,
Perhaps I should have stated YMMV as our negotiation with IBM took place
when the cap model was in its infancy and from reviewing the link you
provided it appears some aspects have changed.

Basically if you use TSM compression, deduplication, and/or ProtecTier,
it would be reflected in the licensing costs, if you choose another
solution as we did with Data Domain it is not. In the end we asked IBM
to negotiate a middle-ground number but were denied.

I only mention this for those who use Data Domain, or other non-IBM
solutions for dedupe and compression as it will ultimately affect the
capacity license model cost.


Hope that helps....


~Rick


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Stackwick, Stephen
Sent: Monday, July 16, 2012 12:42 PM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: [ADSM-L] Moving to TSM Capacity based licensing from PVU -
experiences

I'm a little surprised by this, as the TSM macros you run to calculate
the storage don't know (or care) about the storage device, i.e., they
just report the uncompressed storage amount:

https://www-304.ibm.com/support/docview.wss?uid=swg21500482&wv=1

That said, if you are running TSM deduplication, that *is* reported with
the macros, so there would be a cost saving. Was IBM talking about a
discount for ProtecTier, maybe?

Steve

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Rick Adamson
Sent: Monday, July 16, 2012 8:44 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: [ADSM-L] Moving to TSM Capacity based licensing from PVU -
experiences

Ian,
Our company looked into it and thought it may save some $$ and at the
same time simplify the OVERLY complex PVU license model used for
TSM/IBM.

I'll start by saying to make sure you understand what TSM products are
included in the "capacity" license proposal. From memory I don't
remember the exact ones but it does not apply to all TSM licenses. This
obviously means that the capacity license model may be attractive to
some and unattractive to others. Your IBM rep should be able to clarify
this.

Also, in our environment we use a Data Domain backend which as you may
know prefers all incoming data to be uncompressed and unencrypted. Since
the TSM servers have no knowledge of the DD processes it reports the raw
storage numbers before compression and deduplication which negatively
affected the capacity licensing pricing.

We opened discussions on this issue with IBM but they refused to budge
or negotiate an adjustment for the "actual" storage used. Needless to
say that position was not too warmly received and we 86'ed the whole
discussion.

Interestingly, had we used IBM storage/deduplication on the backend they
would use the actual storage, but no such provision for Data Domain.

Good luck....

~Rick


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Ian Smith
Sent: Monday, July 16, 2012 7:13 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: [ADSM-L] Moving to TSM Capacity based licensing from PVU -
experiences

Hi,

We are in the midst of discussions on moving to capacity-based licensing
from the standard PVU-based method for our site. We have a large number
of clients ( licensed via TSM-EE, TDP agents, and on client-device basis
) and around 1PB of primary pool data. As I understand it, there is no
published metric for the conversion from PVU to per TB licensing so I
would be really interested and grateful if anyone would like to share
their experiences of that conversion in a private email to me.

Many thanks in advance.
Ian Smith
Oxford University
England

Thanks, Rick. The link I provided does make it appear more rigid now. I'm not a salesman, but I guess everything is negotiable if the parties are willing to dicker and it would make sense for IBM to push it's solution.

Steve

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of Rick Adamson
Sent: Monday, July 16, 2012 2:05 PM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: [ADSM-L] Moving to TSM Capacity based licensing from PVU - experiences

Steve,
Perhaps I should have stated YMMV as our negotiation with IBM took place when the cap model was in its infancy and from reviewing the link you provided it appears some aspects have changed.

Basically if you use TSM compression, deduplication, and/or ProtecTier, it would be reflected in the licensing costs, if you choose another solution as we did with Data Domain it is not. In the end we asked IBM to negotiate a middle-ground number but were denied.

I only mention this for those who use Data Domain, or other non-IBM solutions for dedupe and compression as it will ultimately affect the capacity license model cost.


Hope that helps....


~Rick


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of Stackwick, Stephen
Sent: Monday, July 16, 2012 12:42 PM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: [ADSM-L] Moving to TSM Capacity based licensing from PVU - experiences

I'm a little surprised by this, as the TSM macros you run to calculate the storage don't know (or care) about the storage device, i.e., they just report the uncompressed storage amount:

https://www-304.ibm.com/support/docview.wss?uid=swg21500482&wv=1

That said, if you are running TSM deduplication, that *is* reported with the macros, so there would be a cost saving. Was IBM talking about a discount for ProtecTier, maybe?

Steve

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of Rick Adamson
Sent: Monday, July 16, 2012 8:44 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: [ADSM-L] Moving to TSM Capacity based licensing from PVU - experiences

Ian,
Our company looked into it and thought it may save some $$ and at the same time simplify the OVERLY complex PVU license model used for TSM/IBM.

I'll start by saying to make sure you understand what TSM products are included in the "capacity" license proposal. From memory I don't remember the exact ones but it does not apply to all TSM licenses. This obviously means that the capacity license model may be attractive to some and unattractive to others. Your IBM rep should be able to clarify this.

Also, in our environment we use a Data Domain backend which as you may know prefers all incoming data to be uncompressed and unencrypted. Since the TSM servers have no knowledge of the DD processes it reports the raw storage numbers before compression and deduplication which negatively affected the capacity licensing pricing.

We opened discussions on this issue with IBM but they refused to budge or negotiate an adjustment for the "actual" storage used. Needless to say that position was not too warmly received and we 86'ed the whole discussion.

Interestingly, had we used IBM storage/deduplication on the backend they would use the actual storage, but no such provision for Data Domain.

Good luck....

~Rick


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of Ian Smith
Sent: Monday, July 16, 2012 7:13 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: [ADSM-L] Moving to TSM Capacity based licensing from PVU - experiences

Hi,

We are in the midst of discussions on moving to capacity-based licensing from the standard PVU-based method for our site. We have a large number of clients ( licensed via TSM-EE, TDP agents, and on client-device basis
) and around 1PB of primary pool data. As I understand it, there is no published metric for the conversion from PVU to per TB licensing so I would be really interested and grateful if anyone would like to share their experiences of that conversion in a private email to me.

Many thanks in advance.
Ian Smith
Oxford University
England

We moved over to per TB licensing last year, and were told categorically
that the only dedupe they would take into account was TSM's dedupe. We
also have ProtecTIER, and they would not take that into account.

Steven

On 16 July 2012 19:22, Stackwick, Stephen <Stephen.Stackwick < at > icfi.com>wrote:

Thanks, Rick. The link I provided does make it appear more rigid now. I'm
not a salesman, but I guess everything is negotiable if the parties are
willing to dicker and it would make sense for IBM to push it's solution.

Steve

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Rick Adamson
Sent: Monday, July 16, 2012 2:05 PM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: [ADSM-L] Moving to TSM Capacity based licensing from PVU -
experiences

Steve,
Perhaps I should have stated YMMV as our negotiation with IBM took place
when the cap model was in its infancy and from reviewing the link you
provided it appears some aspects have changed.

Basically if you use TSM compression, deduplication, and/or ProtecTier, it
would be reflected in the licensing costs, if you choose another solution
as we did with Data Domain it is not. In the end we asked IBM to negotiate
a middle-ground number but were denied.

I only mention this for those who use Data Domain, or other non-IBM
solutions for dedupe and compression as it will ultimately affect the
capacity license model cost.


Hope that helps....


~Rick


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Stackwick, Stephen
Sent: Monday, July 16, 2012 12:42 PM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: [ADSM-L] Moving to TSM Capacity based licensing from PVU -
experiences

I'm a little surprised by this, as the TSM macros you run to calculate the
storage don't know (or care) about the storage device, i.e., they just
report the uncompressed storage amount:

https://www-304.ibm.com/support/docview.wss?uid=swg21500482&wv=1

That said, if you are running TSM deduplication, that *is* reported with
the macros, so there would be a cost saving. Was IBM talking about a
discount for ProtecTier, maybe?

Steve

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Rick Adamson
Sent: Monday, July 16, 2012 8:44 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: [ADSM-L] Moving to TSM Capacity based licensing from PVU -
experiences

Ian,
Our company looked into it and thought it may save some $$ and at the same
time simplify the OVERLY complex PVU license model used for TSM/IBM.

I'll start by saying to make sure you understand what TSM products are
included in the "capacity" license proposal. From memory I don't remember
the exact ones but it does not apply to all TSM licenses. This obviously
means that the capacity license model may be attractive to some and
unattractive to others. Your IBM rep should be able to clarify this.

Also, in our environment we use a Data Domain backend which as you may
know prefers all incoming data to be uncompressed and unencrypted. Since
the TSM servers have no knowledge of the DD processes it reports the raw
storage numbers before compression and deduplication which negatively
affected the capacity licensing pricing.

We opened discussions on this issue with IBM but they refused to budge or
negotiate an adjustment for the "actual" storage used. Needless to say that
position was not too warmly received and we 86'ed the whole discussion.

Interestingly, had we used IBM storage/deduplication on the backend they
would use the actual storage, but no such provision for Data Domain.

Good luck....

~Rick


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Ian Smith
Sent: Monday, July 16, 2012 7:13 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: [ADSM-L] Moving to TSM Capacity based licensing from PVU -
experiences

Hi,

We are in the midst of discussions on moving to capacity-based licensing
from the standard PVU-based method for our site. We have a large number of
clients ( licensed via TSM-EE, TDP agents, and on client-device basis
) and around 1PB of primary pool data. As I understand it, there is no
published metric for the conversion from PVU to per TB licensing so I would
be really interested and grateful if anyone would like to share their
experiences of that conversion in a private email to me.

Many thanks in advance.
Ian Smith
Oxford University
England

When we first started renegotiating our last deal, about a year ago, the discount for ProtecTier was talked about a lot, but I don't know if it was part of the final package.

We went with capacity-based licensing for two reasons:
1) no one liked dealing with PVUs, and the TSM server team could neither easily measure PVUs nor encourage server administrators to factoring PVUs into their designs.
2) We manage storage growth aggressively and track it constantly. Managing that now manages our TSM license cost at the same time.

Oddly enough, it looks like our initial architecture for the VE environment will play to this model nicely. As of TSM 6.3, the TDP for VE doesn't yet do "incrementals forever," so we need an architecture that reduces backup time for the data movers, and we will look heavily at client-side dedupe, on the theory that we'll own the datamovers and can give them all the CPU power they might need to do client-side dedupe without impacting production CPU capacities. Of course, this is all on paper now; ask me in six months how well it's actually working out.

Nick

On Jul 16, 2012, at 11:42 AM, Stackwick, Stephen wrote:

I'm a little surprised by this, as the TSM macros you run to calculate the storage don't know (or care) about the storage device, i.e., they just report the uncompressed storage amount:

https://www-304.ibm.com/support/docview.wss?uid=swg21500482&wv=1

That said, if you are running TSM deduplication, that *is* reported with the macros, so there would be a cost saving. Was IBM talking about a discount for ProtecTier, maybe?

Steve

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of Rick Adamson
Sent: Monday, July 16, 2012 8:44 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: [ADSM-L] Moving to TSM Capacity based licensing from PVU - experiences

Ian,
Our company looked into it and thought it may save some $$ and at the same time simplify the OVERLY complex PVU license model used for TSM/IBM.

I'll start by saying to make sure you understand what TSM products are included in the "capacity" license proposal. From memory I don't remember the exact ones but it does not apply to all TSM licenses. This obviously means that the capacity license model may be attractive to some and unattractive to others. Your IBM rep should be able to clarify this.

Also, in our environment we use a Data Domain backend which as you may know prefers all incoming data to be uncompressed and unencrypted. Since the TSM servers have no knowledge of the DD processes it reports the raw storage numbers before compression and deduplication which negatively affected the capacity licensing pricing.

We opened discussions on this issue with IBM but they refused to budge or negotiate an adjustment for the "actual" storage used. Needless to say that position was not too warmly received and we 86'ed the whole discussion.

Interestingly, had we used IBM storage/deduplication on the backend they would use the actual storage, but no such provision for Data Domain.

Good luck....

~Rick


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of Ian Smith
Sent: Monday, July 16, 2012 7:13 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: [ADSM-L] Moving to TSM Capacity based licensing from PVU - experiences

Hi,

We are in the midst of discussions on moving to capacity-based licensing from the standard PVU-based method for our site. We have a large number of clients ( licensed via TSM-EE, TDP agents, and on client-device basis
) and around 1PB of primary pool data. As I understand it, there is no published metric for the conversion from PVU to per TB licensing so I would be really interested and grateful if anyone would like to share their experiences of that conversion in a private email to me.

Many thanks in advance.
Ian Smith
Oxford University
England

Ian et al;
We have a Capacity Based license now, and so far so good.

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.

Best wishes,
Keith Arbogast
Indiana University

-----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=

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.EDU] on behalf of Thomas Denier [Thomas.Denier < at > JEFFERSONHOSPITAL.ORG]
Sent: 17 July 2012 16:19
To: ADSM-L < at > VM.MARIST.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
=

Woot!!! How can they release this stuff with a straight face ?!??!!

W



-----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