You said you ended up with the disk in read-only mode, but M would imply that if you couldn¹t get it in read-write mode, you wouldn¹t get it at all. This would lead me to believe that there might have been fingers at work on the console after the log-in and before the boot that might have subsequently linked the disk, possibly with a ³LINK * 200 200 MR², maybe? Again, the console log would lead to the footprint of the perp that would tell all.
Another fine way to handle the situation and allow some control would be to IPL the guest into CMS before starting the Linux guest. Set up the machine using the CMS profile and do your sanity checks there, then IPL the Linux boot disk when you know things will go well. Given our two CEC environment, and our history before going into CSE, we use this method to check that the image was last run on the current LPAR before IPLing the Linux image, to be sure that it can¹t be running in the other CEC. We had the same image booted on both systems at the same time once too often, destroying the image (i.e... Once) We use a read-only CMS 191 with a profile to perform this vital sanity check (for us) before allowing the Linux image to start. (In fact, all our linux images share the same 191 minidisk.) Checking the Linux disks to be sure they are RW certainly wouldn¹t hurt as well. It would be a simple task, especially if you stuck to a standard addressing scheme for all your images. Just an idea to think about. -- Robert P. Nix Mayo Foundation .~. RO-OC-1-18 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 3/1/11 3:40 PM, "Perez, Steve S" <sspe...@corelogic.com> wrote: > I issued a LINK RR against it and did a Q LINKS and it shows no other link > access to that disk. Would it be possible that when we paused PPRC and > suspended Global Mirror on the z/OS LPAR (shared volumes between all LPARS) > that it may have accessed the dasd the minidisk is on in write mode and caused > the access mode on the z/VM LPAR to go into a READ-MODE? Is that probable? > > > > Steve. > > From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf > Of Mark Pace > Sent: Tuesday, March 01, 2011 2:57 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: zLinux OS disk read-only > > M Multiple-write access. Write access is established unless another user holds > a write, a stable (SR, SW, SM) or an exclusive (ER, EW) mode access to > the disk. > > Looks like some other VM has that disk linked in write mode. > > On Tue, Mar 1, 2011 at 3:53 PM, Perez, Steve S <sspe...@corelogic.com> wrote: >> The disk is defined as follows. This is an excerpt from the CP directory: >> >> IPL 200 >> ..... >> LINK RHMASTER 199 199 RR >> MDISK 200 3390 1 10016 LX53B5 M >> >> Unfortunately, the console log did not get spooled so I don't know what the >> log would have indicated for that disk when the guest machine came up. >> That's on my follow-up list. The guest machine is IPL'd off of its OS (disk >> 200) disk when it comes up (in its CP Directory) so I need to find a way to >> spool the console when it starts and not later after it has gone through its >> initialization. >> >> >> Thanks, >> Steve >> >> -----Original Message----- >> From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On >> Behalf Of RPN01 >> Sent: Tuesday, March 01, 2011 2:33 PM >> To: IBMVM@LISTSERV.UARK.EDU >> Subject: Re: zLinux OS disk read-only >> >> How is the disk defined in the CP Directory entry (i.e. What is the mode of >> the disk), and what is in the console log when the user was logged in that >> could give a clue about the status of the disk when the user was >> initialized? >> >> The mode will tell you the condition(s) that could lead to it being read >> only (other users having it read/write or even read only), and the log may >> even tell you which or how many users gummed up the works, or when things >> when oval on you. >> >> In any case, it had to have happened at some point, and there has to be a >> footprint, if you keep your logs. >> >> -- >> Robert P. Nix Mayo Foundation .~. >> RO-OC-1-18 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 3/1/11 2:23 PM, "Steve Perez" <sspe...@corelogic.com> wrote: >> >>> > Hello All, >>> > >>> > Has anyone run into a situation where the zLinux OS disk has become >>> > READ- >>> > >>> > ONLY access? We are running z/Linux under z/VM 5.4 Redhat 5.4. >>> > >>> > My zLinux Admin were doing compares between the production environment >>> > >>> > versus the Test D/R environment and noticed it. He issued the >>> > following >>> > >>> > on the prod zLinux guest environment: >>> > >>> > # mount -o remount,rw /dev/VolGroup01/LogVol00 >>> > mount: block device /dev/VolGroup01/LogVol00 is write-protected, >>> > mounting >>> > >>> > read-only >>> > >>> > Since we are testing our D/R process at the moment for the z/VM LPAR >>> > we >>> > >>> > are unsure at this point whether that is a contributing factor. It >>> > shoul d not be but we can't rule it out. We paused our PPRC/Global >>> > mirroring fro m the z/OS side before starting the D/R activities to >>> > perform recovery of >>> > >>> > the z/VM & z/Linux. The problem was found while in the middle of >>> > verifying/comparing environments on the zLinux side. I can link to >>> > the >>> > >>> > minidisk that is used to IPL that zLinux guest and it shows R/W when I >>> > >>> > issue Q LINKS. All other minidisks owned by that zLinux guest are R/W a >>> > s >>> > well. From my perspective (z/VM) all looks good. >>> > >>> > Any input would be appreciated, if anything to rule out that PPRC/GM >>> > woul d have contributed to this. >>> > >>> > Thanks. >>> > Steve. >> ***************************************************************************** >> ************* >> This message may contain confidential or proprietary information intended >> only for the use of the >> addressee(s) named above or may contain information that is legally >> privileged. If you are >> not the intended addressee, or the person responsible for delivering it to >> the intended addressee, >> you are hereby notified that reading, disseminating, distributing or copying >> this message is strictly >> prohibited. If you have received this message by mistake, please immediately >> notify us by >> replying to the message and delete the original message and any copies >> immediately thereafter. >> >> Thank you. >> ***************************************************************************** >> ************* >> CLLD > >
