ADSM-L

Re: new TSM Client Pricing - a BP opinion

2003-05-14 09:39:02
Subject: Re: new TSM Client Pricing - a BP opinion
From: Steve Roder <spr AT REXX.ACSU.BUFFALO DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 14 May 2003 09:38:22 -0400
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)