Wouldn't it be great if System_identifier didn't have to be based on the
CPU-id and LPAR-number. Why not provide a way to specify a
System_identifier_default in the LPAR-definitions on the HMC, or via
SAPL?  Then, if you don't override it in the SYSTEM CONFIG, that will be
the System_Identifier that VM will use.

That way you could set the System_identifier value even before VM starts
up.  And then, if RSCS, TCP, etc, would all use the System_identifier
instead of SYSTEM NETID, then you wouldn't need to worry about CPU-ids
anymore when you move to another CPU for whatever reason (DRP, new
hardware, another LPAR,...). 

Just my 2 eurocents.

Geert.

-----Original Message-----
From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On
Behalf Of Alan Altmark
Sent: donderdag 23 februari 2006 15:02
To: [email protected]
Subject: Re: SYSTEM NETID and CPUIDs

On Thursday, 02/23/2006 at 04:58 CST, "Jeff Gribbin, EDS" 
<[EMAIL PROTECTED]> wrote:
> My point is that the current criterion (cpuid) is dynamically variable
> whereas the proposed criterion (SYSTEMID) is fixed. Once upon a time 
this
> would have been an issue for me. Nowadays, for me, the convenience and
> simplicity of SYSTEMID would win hands-down - but it DOES imply a 
tradeoff
> and, if implemented, may irritate one or two remaining eccentrics such

as
> I used to be.

I do not propose to eliminate the current capabilities of "{nodeid, 
rscsid} = f(cpuid)".  But, rather, to add "{nodeid, rscsid} =
f(systemid)" 
and a default of "{nodeid, rscsid} = {systemid, RSCS}".

And maybe, just maybe, we could have SET SYSTEMID just as we do SET
CPUID, 
eh?  How many times have people requested to be able to change the 
systemid seen in the lower right-hand corner?  :-)

But the real objective is to (a) not require any configuration of SYSTEM

NETID where none is needed, and (b) eliminate one of the annoying 
pain-points during migrations.  It doesn't necessarily mean making the 
ability to change your nodeid and rscsid to something other than the 
default any easier.  (But it would be nice.)

Alan Altmark
z/VM Development
IBM Endicott
DISCLAIMER

This email and any files transmitted with it are confidential 
and intended solely for the use of the individual or entity 
to whom they are addressed. If you have received this email 
in error please notify [EMAIL PROTECTED]
This footnote also confirms that this email has been checked 
for the presence of viruses.

Informatica J.Van Breda & Co NV BTW BE 0427 908 174

Reply via email to