I like the idea of associating the NETID and Node with the logical system rather than the cpu hardware. I have been in the position of having to move systems around due to hardware considerations, so the designation by cupid was a real pain. At one shop where we had two systems, each with its own unique workload, we even disabled the use of SYSTEM NETID altogether because of the volatile nature of things - either system could be brought up on any of 4 cpus and could be switched from one to another at any time. The SYSTEM CONFIG file, perhaps a System_Name, is the proper place in my opinion. And I think that anyone who uses a node name that differs from the System_Name must have converted to VM from an MVS background. Having an identifier based on LPAR name is repugnant to me.
Regards, Richard Schuh -----Original Message----- From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Thursday, February 23, 2006 7:05 AM To: [email protected] Subject: Re: SYSTEM NETID and CPUIDs On Thursday, 02/23/2006 at 03:36 CET, Dieltiens Geert <[EMAIL PROTECTED]> wrote: > 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,...). Override via SAPL. Verrrrrry interesting..... I had thought about using the HMC-defined LPAR name as the index into the SYSTEM_IDENTIFER table, along with a default SYSTEM_IDENTIFER that was the same as the LPAR name. (Y'all know you can QUERY LPAR now, right?) Alan Altmark z/VM Development IBM Endicott
