Hello Carl, Think of your environment as an onion with three layers: The outside layer is the real world, as seen/defined by the zVM system running on your hardware / LPAR. If the, "real world layer" can't see something then the, "inner layers" won't be able to see it either. So, first job, make sure that LNX032 is visible to the, "real world". This can probably be done most easily with a command such as, "CP QUERY DASD LNX032" from a suitably-privileged, "real world" userid.
The response to the query command will vary and you'll probably want to check the manuals to understand your particular response or, if you have trouble understanding it, post it here for an immediate interpretation (or, mor elikely, several different immediate interpretations <g>) - but, until you're 100% happy that LNX032 is, "visible" in the, "real world" there's no point in proceeding any further. Next, logon the virtual machine in which you're going to IPL your 2nd- level zVM. Let's call this the, "2NDLEVEL" world. DON'T IPL yet - let's first take a look around to see what subset of the real world has been included in "2NDLEVEL-land". This is most easily done with the CP command, "QUERY VIRTUAL". Is there anything there that, "looks like" LNX032? Remember, "2NDLEVEL-land" only includes stuff that's either defined in 2NDLEVEL's directory entry or which has been added after logon using commands such as LINK or (from a privileged, "real world" user) ATTACH. You can also check on LNX032's, "real world" status again by issuing (from a privileged, "real world" userid), "CP QUERY xxxx" where xxxx is the real address shown in the response to the previously- mentioned, "QUERY DASD" command. If the, "real world" status shows, "ATTACHED TO 2NDLEVEL AS yyyy" then you're in business - the disk is dedicated to 2NDLEVEL for its exclusive use. If it shows, "ATTACHED TO SYSTEM" then LNX032 will only be visible to 2NDLEVEL if 2NDLEVEL has LINKed to it - you can check this with the, "Real World" command, "CP QUERY SYSTEM xxxx" - this will show all the currently active links for the device at address xxxx - is 2NDLEVEL there? If not, work out why not (missing MDISK statement in 2NDLEVEL's directory entry maybe). If you can't work out why not then, once again, ask and somebody'll help. OK, now you're happy that the 2NDLEVEL, "hardware" can, "see" LNX032, IPL zVM in 2NDLEVEL. As soon as zVM is up, issue the command, "CP QUERY yyyy" (yyyy being the address where 2NDLEVEL is, "seeing" LNX032) from a suitably privileged userid on 2NDLEVEL to check on the status of LNX032 from 2NDLEVEL's perspective. Hopefully, fully visible - probably either, "FREE" or, "ATTACHED TO SYSTEM". If you're not sure of its status, issue commands and ask questions until you are sure. Now, logon your Linux guest under 2NDLEVEL (let's call it LINUX3). Once again, DO NOT IPL anything - use CP QUERY VIRTUAL to verify that the LINUX3, "hardware" configuration is as you expected. Is LNX032, "visible" to LINUX3? If not, why not? Does the disk need to be ATTACHED to LINUX3 (as a dedicated device) or maybe ATTACHED TO SYSTEM so that LINUX3 can then LINK to it? (Basically, this is a question of whether or not you want to share LNX032 with other userids under 2NDLEVEL - if you want to share a disk then it's ATTACHED to SYSTEM and accessed via MDISK/LINK, if you want it dedicated then you simply ATTACH to <userid>. Then, once you've fully satisfied yourself that LNX032 is visible to LINUX3, IPL Linux. If Linux then can't see the disk I would suggest that you have a Linux configuration problem. If you take this layered approach then it'll be much easier to get help because we'll have together debugged each of the three layers in turn before proceeding on to the next one. With hindsight it'll all be extremely obvious. Regards Jeff Gribbin
