ADSM-L

Re: new TSM Client Pricing - a BP opinion

2003-05-14 16:36:04
Subject: Re: new TSM Client Pricing - a BP opinion
From: Steve Schaub <Steve.Schaub AT HAWORTH DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 14 May 2003 16:35:14 -0400
I will agree that the new pricing model is less than ideal, and I would
love to be able to buy an "unlimited" client license like we had under
the 3466 program.

But I am getting more than a little tired of the whining from the
academics.  Given the astronomical cost of trying to send my kids to
college, where tuition has defied the reality of the last 3 years
economy (rising costs and salaries when everyone else has been frozen or
taken pay cuts), I flat out refuse to believe that "Universities are not
run like Fortune500 companies", or that they "cannot keep track of what
every research group spends money on in terms of computing".  Give me a
break, and spend some time in the real world.  No one else has unlimited
resources either.

-----Original Message-----
From: Steve Roder [mailto:spr AT REXX.ACSU.BUFFALO DOT EDU] 
Sent: Wednesday, May 14, 2003 9:38 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: new TSM Client Pricing - a BP opinion


Your "past" does not go very far back in terms of licensing for this
product.  I started out on this product when it was called WDSF
(Workstation Data Save Facility), when it was only available on VM, and
the only protocol support was 3270 datasteams.  If my memory serves,
when it became Adstar Distributed Storage Manager (ADSM), IBM added
TCPIP as a protocol, making the product viable.  That would be ADSM V1.
Back then, IBM had a program with Higer Ed (HESC) which allowed
Universities to pay a single, flat fee (cheap) for any software that ran
on VM, and was used for 80% academic purposes.  ADSM was on that list,
and upon request, we would get the media, and an unlimited number of
client licenses.  When HESC was discontinued, and we had to pay for
ADSM, a client license was a flat price, and it did not matter what the
client was.  You registered the license with the server, and each new
client caused the server to increase it's "in use" count (this has
really not changed much, until V5, and the GUID).

Having to buy licenses in advance of their use is a reality of doing
backup business in a large Research University environment.
Universities are not run like Fortune500 companies.  The CIO cannot
dictate to the researchers how they spend their grant monies.  We (the
Main Computing
Center) do not, and cannot, keep track of what every research group
spends money on in terms of computing.  What we do is provide services
to the students, and the researchers.  They request backup services, and
we provide that to them.  Therefore, no, we cannot plan for much in
terms of TSM growth, and is why we keep at least 50-100 unused licenses
on hand at all times.  We anlayze our growth rate, and use that as our
planning yardstick.

This new pricing model could drastically affect us, conceivably sending
us off looking for a replacement for TSM.  This, our CIO, can do, and
will, if this increases our annual TSM costs by 500%.  We already pay
upwards of $40k, and $200K for yearly maintenance is, well, a possible
TSM showstopper.

I think the below model, which you explain well, was conceived by a
bunch of lawyers, none of which considered how it would effect customers
in Higer Education.  Things work very differently at a large, research
University.



> 2. License types:
> -       in the past there were four types of ADSM/TSM licenses - for
TSM
> server, for TSM client which is server in the enterprise, for TSM 
> client which is client in the enterprise and for mainframes' MSUs. TSM

> servers and server-class TSM clients were subdivided into "Tiers" 
> based on processor count (1-4 Intels were Tier 1, 5+ Intels and 1-23 
> RISKs were Tier 2, 24+ RISKs were Tier 3). The client-class TSM 
> clients had single license for any type and number of processors. 
> There were separate licenses for "Managed Library" (library above 
> certain size required a license, also Tiered), "Shared Library" 
> (server shares library with storage agents or another servers), 
> "Managed System for SAN" (formal name for Storage Agents).
> -       with introduction of ITSM v5.1 the licensing have been changed
to
> calculate number of processors instead of TMPs derived from number of 
> processors. The differences between RISK and Intel processors has been

> removed. Separate license for TSM server(s) was also removed and they 
> were made equal to server-class TSM client licenses. The license for 
> client-class TSM clients remained unchanged except it is now quoted in

> dollars, euro, etc. instead of TMPs (which had their own price).
>
> In my personal opinion (not binding anyone) this was rather good. 
> Simplification does matter and the discussions on it mimic the past 
> discussion should Great Britain abandon pennies/shillings/guineas in 
> favour of metric monetary system. Maybe we being IT professionals know

> what is the difference between processors, between "tiers", between 
> system acting as client or server, etc. But the management or 
> purchase/procurement department does not! And they need simple 
> quantitive system. </personal>
>
>
> 3. What is considered server-class and what is client-class. Official 
> wording from IBM will be used here. It was put in a file named 
> "Enhanced Value Based Pricing definitions" on www.tivoli.com. After 
> migration to ibm.com it became unreachable as lot of other content.
> -       "A client is a computer system or a process that requests a
> service of another computer system that is typically referred to as a
> server.  ...   Examples include laptop computers, desktop computers,
> deskside computers, and technical workstations."
> -       "A server is defined by its use in the customer's environment,
not
> by its use within a Tivoli application."
> -       "A server is a computer system that provides services to one
or
> more clients and/or other devices over a network. Examples include, 
> but are not limited to, file servers, print servers, mail servers, 
> database servers, application servers, and Web servers."
>
> Therefore single processor Pentium/200 print server box will require 
> the expensive ITSM "processor" license while 4-processor mighty SGI 
> box for video processing will require cheap ITSM "client" license. But

> this was just the same in versions 4.2 and before, thus I cannot find 
> reasons for complains.
>
>
> 4. Open registration of licenses.
> If the company/organization have decided to use open registration it 
> means it prefers to do less planning. If there is no plan based on 
> good usage predictions you should have enough <whatever> on stock to 
> fulfil the demand. Either switch to well-planned configuration with 
> precise usage tracking (for TSM this means closed registration) or 
> keep a pool of necessary goods, materials, licenses, people, etc. If 
> we talk to something material - workstations or tapes for example, 
> what can we do if there is no desktop for new staff constantly coming 
> in or we run out of scratch tapes!?! Nothing better than buying new 
> ones or findin out a way how to reuse existing ones.
>
>
> --> We were told yesterday that a processor is a processor.
>
> Incorrect. ADSM/TSM/ITSM "client" licenses are for client-class system

> with *any* number of processors. If you have 8-processor Xeon just to 
> play Quake on it, the decision is yours and it is still a "client". If

> you make it a HTTP proxy the server-class rules will apply.
>
> --> furthermore it doesn't matter whether it is running TSM server or 
> --> TSM
> client.
>
> It matters. TSM client might be server requiring "processor" licenses 
> (same as for TSM server) or might be a non-serving system requiring 
> only a "client" license.
>
> --> Tivoli defines a client as a desktop machine (Win98, etc..)
>
> Incorrect. Tivoli defines a client based on its usage. Win98 box 
> sitting in the corner and used by whole department to print on its 
> laser printer
> *is* a print server and therefore requires a "processor" license.
>
> --> ... have told me that for LAN based backup there is only one 
> --> license
> part number (D5127LL) that is a per processor license and is the same 
> for TSM client use or TSM server use.
>
> Misleading. There is more than "one" license part number. The one 
> shown is for TSM server and server-class TSM client for IBM TSM (base 
> edition). There another one for ITSM Extended Edition - D51MFLL. For 
> client-class TSM client (workstations, desktops, etc.) there are two 
> another "Clients" part number - D5158LL, D51MKLL which are actually 
> equal (paid upgrade of server licenses D5127LL -> D51MFLL implies no 
> charge upgrade D5158LL -> D51MKLL). Both these are initial purchase 
> numbers and have several corresponding software maintenance numbers. 
> Maintenance and upgrades are another story.
>
> --> ... new xeon processors with hyperthreading...  2 physical 
> --> processors look
> like 4 to the OS!
>
> As two processors. Physical number of processors is counted not 
> virtual. Same as processors in the box are counted but not the number 
> of TSM nodes you may define on it. BTW: IBM Power4 processors have 
> hyperthreading since '99 but being not used in PCs this is not 
> popular.
>
> --> But since it has a modem, and other computers dial into it (just 
> --> to
> upload/download files), it is considered a SERVER, NOT a DESKTOP
>
> This falls into twilight zone. It is both "a system that requests a 
> service of another system" and "a system that provides services to one

> or more clients". If most of the time system is used as a workstation 
> and files are transferred only occasionally - it is a "client". But if

> this is a no-matter-what-hardware PC with no-matter-what-software OS, 
> which is used mainly for dial-in and file transfer - it is definitely 
> a server and needs "processor" license. Cheating yourself putting 
> server-type load on a "desktop" is not an excuse.
>
> --> In the past, we have bought TSM client licenses in advance of 
> --> need, or
> knowing where they will get used.  Will one have to know when a client

> requests services if it qualifies as a server, or client, and how many

> CPU's it has, before we can buy the license?
>
> Not knowing where the licenses will be used does not change the rules.

> In the past you could not know will the TSM client be Tier 1 or Tier 2

> and how many TMPs you need to have on hand. Now you do not know how 
> many CPUs the TSM client will have and how many "processors" you may 
> need. But it is nearly the same. Yes, I agree having TMPs allowed you 
> to get both "client" desktops and "tiered" server in single pool, 
> while now you need to keep pools of "clients" and "processors". But I 
> think this should pay itself with easier negotiations with procurement

> if right arguments are used.
>
> --> Huge, multiprocessor, single user machines, ...
>
> If it is single-user, it qualifies as a "client", no matter how many 
> or how powerful the processors are, period. Anything else is an 
> attempt from the VAR or from IBM to squeeze out more money from you! 
> Change the VAR or fill an official complaint.
>
> --> I can tell you now that our notoriously ill-tempered 
> --> administrative person
> will run me out of town with both guns blazing if I present this. How 
> can we continue to purchase generic client licenses, in advance, in 
> quantity at bulk discounts, without knowing the exact characteristics 
> of each client node?
>
> Ask the ill-tempered administrator is he/she waiting to run out of 
> paper or toner for the copier machine before to order new ones. Or is 
> keeping both few packs of paper *and* spare toner cartridge on hand.
>
>
> Sorry for the lengthy message. Your rant is for licensing, my one is 
> for asking already answered a year ago questions.
>
>
> Zlatko Krastev
> IT Consultant
>
> P.S. If you read all this I would be glad to have some feedback - was 
> it exhaustive, was I offensive, etc. ZK
>
>
>
>
>
> "Klein, Robert (NIH/CIT)" <kleinr AT EXCHANGE.NIH DOT GOV>
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> 13.05.2003 
> 20:10 Please respond to "ADSM: Dist Stor Manager"
>
>
>         To:     ADSM-L AT VM.MARIST DOT EDU
>         cc:
>         Subject:        new TSM Client Pricing
>
>
> I was speaking with our TSM sales rep earlier today about ordering TSM

> client software upgrades.  She said that as of this past January, a 
> factor in the pricing of a client software license is whether or not 
> the client is a server or a desktop and, if a server, how many cpus it

> has.  Has anyone else heard anything about this?
>
> Thanks.
>
>

Steve Roder, University at Buffalo
HOD Service Coordinator
VM Systems Programmer
UNIX Systems Administrator (Solaris and AIX)
TSM/ADSM Administrator
(spr AT buffalo DOT edu | (716)645-3564)