Here here!!!
I second the motion that if Tivoli comes up with a new way to charge
us for the software, they must come up with a better way to gather the
required information. We went through this "count the CPUS" exercise about 6
months ago (when they first attempted this pricing scheme) and it was not
simple. It involved a lot of e-mails to different people and groups to
figure it out. I've got better ways to spend my time.
Ben
-----Original Message-----
From: Steve Harris [mailto:Steve_Harris AT HEALTH.QLD.GOV DOT AU]
Sent: Thursday, August 29, 2002 5:51 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Requirement for licence data collection
Hi All,
I'm just going through a painful licence data collection exercise. I have
some 80 nodes registered, but not all these need to be paid for as we set up
one node per application on our clusters.
Up till now I was managing this adequately with an excel spreadsheet because
I just needed to keep track of separate machines:tier1 for Wintel and Tier 2
for everything else. Now, with new new licencing model I need to know how
many CPUs as well and this information is not easy to get.
I've "outsourced" the setting up of new nodes on non-AIX platforms to the
platform support guys, and even if I manually intervened when I created new
nodes, it is really easy for someone to move a node from one machine to
another, or install a new CPU board and I don't get to know about it. I've
looked into pushing scripts down to all my nodes and trying to run some sort
of command to get the number of cpus, but this is very difficult to do. On
Wintel there is a command, but only if you have the reskit installed and you
can run the cscript command etc etc. There are even some boxes that I back
up that I have no rights to and have never even had this sort of
information.
I therefore suggest that there is a requirement for
1. a data collection mechanism to return to the TSM server the number of
CPUs and other relevent licencing information on a regular basis. This
information should include the system serial number where this is available,
or some sort of checksum based on installed equipment a-la Windows XP's
anti-piracy feature where it is not.
2. This data to be stored appropriately in the database.
3. Audit lic to be updated to report licence compliance in the same terms as
are required by Passport Advantage licencing. ie by number of CPUs on
distinct machines.
This requirement could be satisfied by simple extensions to the TSM database
NODES table to hold the appropriate information. The information could be
passsed at dsmc startup in the same way that the IP address is. The only
difficult issue is that Intel architecture machines don't have serial
numbers. THe windows XP checksum approach will work here even if it doesn't
all that well on XP because we are only trying to make a unique checksum for
comparison purposes. We don't care if it changes provided that it changes in
the same way for all nodes that run on the machine. The checksum mechanism
should also be the same for all OSes running on intel architecture so that
correct licencing is available for machines logically partioned using VMware
or equivalent products.
I was recently involved in a backup product selection exercise and ease or
difficulty of licence mangement was a huge issue amongst the admins at
various levels in the organization, for several different products. At that
time TSM had a big plus because managment was easy. It is no longer.
Discussion?
Steve Harris
AIX and TSM Admin
Brisbane Australia
**********************************************************************
This e-mail, including any attachments sent with it, is confidential
and for the sole use of the intended recipient(s). This confidentiality
is not waived or lost if you receive it and you are not the intended
recipient(s), or if it is transmitted/ received in error.
Any unauthorised use, alteration, disclosure, distribution or review
of this e-mail is prohibited. It may be subject to a statutory duty of
confidentiality if it relates to health service matters.
If you are not the intended recipient(s), or if you have received this
e-mail in error, you are asked to immediately notify the sender by
telephone or by return e-mail. You should also delete this e-mail
message and destroy any hard copies produced.
**********************************************************************
|
