> 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? :-)
Then could one presume that there would be two privclass 'CP SET SYSTEMID' commands, the class 'G' version would (as in Jeff's post) affect only that virtual machine, and higher privclass allowing 'CP SET SYSTEM SYSTEMID' (the command syntax of which would be defined by the Department of Redundancy Department) that would affect all users? This could be compared to the capability for class G users to set their VM's CPUID without affecting the complete system, whereas the sysprog has a much more challenging task to change cpuid for a whole VM system. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. "Alan Altmark" <[EMAIL PROTECTED]> Sent by: "VM/ESA and z/VM Discussions" <[email protected]> 02/23/2006 08:01 AM Please respond to "VM/ESA and z/VM Discussions" <[email protected]> To [email protected] cc 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 The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited.
