On Tuesday, 06/01/2010 at 09:52 EDT, Alan Ackerman <alan.acker...@earthlink.net> wrote: > This has come up on this list a number of times. So far as I can remember > , there is no way for a > second level (guest) VM system to determine the system identifier of the > first level (host) VM system > without a first level mod or the first level system writing it somewhere > (disk, VCTCA, other?) that the > second level system can read. DIAG 00 does not have this information. STS > I does not have this > information. I'm not aware of any CP command or DIAG code that has this i > nformation.
Yep, you're right. I don't know why I keep falling into that trap. Wishful thinking, I guess. And old age. :-) STSI and DIAG 0 return the same things: The userid[s] running the instance. STSI also tells you the LPAR name and CEC info. So you still need STSI to complete the container instance identifier (cec.lpar[.userid*], e.g. IBM_D312E_02.K4.ALAN). While that provides a universal instance id, it doesn't help you if you're looking for a name or address to help you contact said instance. The system identifer and host name would be attributes of the instance, and there's no architected way to get such metadata unless you're using something like CIM which maintains the relationship of guest to host as well as a litany of instance attributes. Alan Altmark z/VM Development IBM Endicott
