ADSM-L

Re: [ADSM-L] Lost in TSM licensing

2007-06-27 14:56:09
Subject: Re: [ADSM-L] Lost in TSM licensing
From: "Remeta, Mark" <MRemeta AT SELIGMANDATA DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 27 Jun 2007 14:54:48 -0400
I've been ignoring my KPMG guy :)
I sent him the output of the commands he wanted, let him fill out the
spreadsheet.


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Kauffman, Tom
Sent: Wednesday, June 27, 2007 2:51 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Lost in TSM licensing


The KPMG type is dinging me for when I will get the revised spreadsheet
back to him -- so I looked at it again -- and my brain broke.

They want the count of _processor chips_ and the number of cores on
each.

The straight answer for the RS-6000 is "I just don't know".

We ordered some number of dual-cpu features on the P5 systems; AIX is
telling me I have that count of CPUs (and, because I have SMT on, nmon
gives me twice this count). Short of opening the box, I've got no good
way to answer the question. And even then . . . they're asking the wrong
question. There are some number of CPU chips in a CPU module (quick --
no research -- the 55Q is a quad-cpu system; the cpu chips are smaller.
Are there two cpu modules with two chips each or one module with 4
chips?)

In any case, I should be able to get whatever the silly metric is by
doing a query node f=d, or matching select. And this, of course, breaks
big-time as soon as you start running under vmware ESX or any of the
unix-related lpar environments.

BTW -- yesterday IBM announced that the p6 systems will be rated at 120
value units per core.

Tom Kauffman
NIBCO, Inc

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Wanda Prather
Sent: Wednesday, June 27, 2007 2:15 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Lost in TSM licensing

Not to mention that it's just Too Silly.

The client already reports back to the server what platform it is.
It's not like the client doesn't know, or can't find out, the
information
that the server needs to have.

W


>>> On Wed, 27 Jun 2007 17:19:44 +0100, Matthew Warren
>>> <Matthew_WARREN AT BNPPARIBAS DOT COM> said:
>
>> Hmm, there is always a scheduled TSM command that send's it's output
to
>> a
>> file you have rights to look at later?
>
>> On occaision for small adhoc tasks I have used the TSM scheduler to
>> initiate a command on a client, when I've needed to do the same thing
>> across a lot of nodes.
>
>> as TSM administrator, you could send the output to a file, let tsm
back
>> it
>> up, and then restore it elsewhere to get at it, if you really really
had
>> to!
>
>
> This is true.  I prefer to strongly de-emphasize the extent to which
> I've root-kitted all my clients boxes.  Going behind the admin's back
> to do some administrative operation you dreamed up doesn't endear one.
>
> I once used TSM to get myself an Xterm on a box for which the root
> password had been lost.  Even when I was coming to aid in an
> emergency, the looks were ... thoughtful.
>
> If this were an IBM-supplied, IBM-approved analysis tool, then it
> would at least not be 4000 admins cobbling together 4000 different
> ways to extract the information and inflicting them on an unawares
> population.
>
>
> - Allen S. Rout
>
CONFIDENTIALITY NOTICE:  This email and any attachments are for the
exclusive and confidential use of the intended recipient.  If you are not
the intended recipient, please do not read, distribute or take action in
reliance upon this message. If you have received this in error, please
notify us immediately by return email and promptly delete this message
and its attachments from your computer system. We do not waive
attorney-client or work product privilege by the transmission of this
message.



Confidentiality Note: The information transmitted is intended only for the
person or entity to whom or which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of this information by persons or entities other
than the intended recipient is prohibited. If you receive this in error,
please delete this material immediately.
Please be advised that someone other than the intended recipients, including
a third-party in the Seligman organization and government agencies, may
review all electronic communications to and from this address.