As we can see ITSM 5.1 internal license validation is still in old
MgSysLAN,MgSysSAN,TDP for XXX, etc. scheme. I can bet a beer 6-pack that
this is marketing decision to change licensing scheme short before 9-th
April announcement. Development either was not notified or it was too late
to allocate resources for such a change.
Change from tier-based to processor-based licensing was for nearly all
Tivoli products. Only small part of Tivoli product portfolio was not
renamed to IBM Tivoli <something> and kept its existing licensing scheme.
As we all have seen only six week after announcement new ITSM
processor-based licensing was put in the fridge for re-work and came out
in last days of August changed to increase the mess :-(((
Let's hope in v5.2 (or whatever number it will be) we will have this
corrected.
Zlatko Krastev
IT Consultant
Steve Harris <Steve_Harris AT HEALTH.QLD.GOV DOT AU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
30.08.2002 02:50
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
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.
**********************************************************************
|
