Hi Ivica,
I think I have it now! Thanks to you and all else who helped me with this. I really appreciate it. Thanks Again, Terry ________________________________ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ivica Brodaric Sent: Sunday, June 01, 2008 4:47 AM To: [email protected] Subject: Re: Presenting Additional ECKD devices to Linux Guest Dynamically There is another way of making things permanent - through PROFILE EXEC, but I suggest you stick with the directory for these commands. Also, if you are new to VM, I suggest you stick with minidisks - they are so much more convenient that you have to have a good reason to use dedicated DASD. When you attach a real DASD to a user, then only that user can use it and it doesn't appear in DIRMAP listing, so you'll have to remember that that disk belongs to a Linux guest. There are however some performance benefits in using dedicated DASD (no cylinder address translation plus I/O assist), but if you have fast DASDs with lots of cache in the controller, which is common these days, you won't see the difference, especially if you use minidisk caching on top of that. Dedicating DASD can still make sense for a large production z/OS or z/VSE guests where you want to extract the last drop of performance, but for Linux guests, IMHO, there's not much point unless you have a huge (multi-disk) database or something like that. If you want to give a Linux guest a whole-DASD worth of space, I suggest you attach it to SYSTEM, define the cylinder 0 as a minidisk belonging to $ALLOC$ user (to avoid accidental overwriting of DASD volume label) and the rest of the DASD as a minidisk belonging to the Linux guest. To attach the DASD to SYSTEM at VM IPL time, the DASD volume label has to be included in user volume list in SYSTEM CONFIG. Cheers, Ivica
