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" <[email protected]> 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.
