1. As has been said, you don't need a R/W disk to IPL. R/O is good. SFS directory is even better. 2. Once you IPL Linux, you are not in CMS anymore. You won't be doing anything with your a-disk anymore. So make it easy on your self, when you need to make changes to the profile exec. Put it in a SFS directory.
Tom Duerbusch THD Consulting >>> Scott Rohling <[EMAIL PROTECTED]> 10/28/2008 12:16 PM >>> No - CMS doesn't need a writable disk to IPL.. Most of the customers I've worked with use a common disk (LNXMAINT 192, for example) that they LINK as the guests 191: LINK LNXMAINT 192 191 RR < in the directory For installs - you can either define a writable 191 manually with TDISK -- or put something like this on LNXMAINT 192: /* AUTOSTRT: Auto start install */ Address Command 'CP DETACH 191' 'CP DEF T3390 191 1' If rc <> 0 Then Exit rc 'MAKEBUF' buf = rc Queue 'TEMP' Queue 'YES' 'FORMAT 191 A' /* Run your automatic install code now, which makes the REDHAT CONF, IPLs the RDR, etc */ ...... Then you can XAUTOLOG newguy#AUTOSTRT to do an install.... The common PROFILE EXEC on LNXMAINT 192 will need to recognize AUTOSTRT has been passed and 'not' try and IPL the 200, but just exit and allow the AUTOSTRT EXEC to run. This of course depends on having TDISK available! But I highly recommend using a common 191 disk and common PROFILE EXEC rather than propogating dozens or hundreds of little 191 disks all over the place (or even on one volume). Scott Rohling On Tue, Oct 28, 2008 at 10:50 AM, Mary Anne Matyaz <[EMAIL PROTECTED]>wrote: > Well, two things. I thought you had to have a writable A disk for CMS? And > we do need > a redhat.conf file on there when we kickstart the linux, not so much > afterwards. > MA > > > On Tue, Oct 28, 2008 at 12:45 PM, RPN01 <[EMAIL PROTECTED]> wrote: > >> If you're just IPLing CMS to set things up and then IPL Linux, is there >> really a reason to have multiple 191 minidisks? We share a single read/only >> 191 minidisk among all the Linux guests, in both LPARs. They all end up >> IPLing 391, and we've added a piece to the profile that looks for userid() >> exec, and executes it, if found, as part of the process, allowing for the >> more odd of the Linux images to still share the one 191 minidisk. >> >> If you can do it with one, it seems a shame to have all those one cyl >> minidisks hanging around everywhere. Plus, if you need to make a change to >> something in the way they're brought up, you can do it in one place, instead >> of having to link and fix hundreds of them. >> >> -- >> Robert P. Nix Mayo Foundation .~. >> RO-OE-5-55 200 First Street SW /V\ >> 507-284-0844 Rochester, MN 55905 /( )\ >> ----- ^^-^^ >> "In theory, theory and practice are the same, but >> in practice, theory and practice are different." >> >> >> >> >> On 10/28/08 11:13 AM, "Mary Anne Matyaz" <[EMAIL PROTECTED]> wrote: >> >> Hello all. We're bouncing around an idea to change the way we allocate >> Linux guests. Currently, we have a mdisk that >> has all of the Linux 191 disks on. We then have separate 200 disks >> (mod9's). We're thinking of combining the two, such >> that we have a 1 cylinder 191 mdisk, then 10015 cylinders for the 200 >> disks. This would allow us to move the linuxes from >> one lpar to another as needed. It would also make them more >> self-contained. We're facing a dasd upgrade in the near future, >> and this would make that a little easier. >> Other than the fact that the 200 disk is backed up by TSM and the 191's >> via MVS's FDR, can you guys shoot some holes >> in this theory? Let me know if you see any other problem areas that I >> haven't thought of? >> >> Thanks! >> MA >> >> >> >
