On Sunday, 05/30/2010 at 04:57 EDT, Michael MacIsaac/Poughkeepsie/i...@ibmus wrote:
> Therefore, I am feeling better that I do have the entire System z hierarchy > available from /proc/sysinfo. If I do want a utility that happens to tie LPARs > (for first level z/VMs) with System_Identifiers, or user IDs (for second level > z/VMs) with System_Identifiers, it is not unreasonable to require the > System_Identifier as a parameter. If for some reason a different z/VM system is > IPLed at the first or second level, it would be reasonable to ask the sysadmin > to convey this new relationship to any utility that may rely upon it. I'm not quite sure where you're going with this, but by knowing how deep you are in STSI, you can map it to DIAG 0. That is, you can determine the System_Identifier of each CP instance in the hierarchy, as well as the name of the container which it is runs (userid or LPAR). Remember, too, that there can be multiple VM systems with the same System_Identifer and they can be *in the same hierarchy*. They won't have the same host/node name in a network, but that's a different issue. An instance of CP is determined by cec.lpar[.userid1[.userid2]...]. System_Identifer is an attribute of the VM system, but it isn't a unique locator. Alan Altmark z/VM Development IBM Endicott
