Perhaps this will answer the question; a real live experience from which to share a lesson without experiencing the pain up close and personal.
When preparing to convert from VM/ESA 240 to z/VM 510 last New Year's, I discovered that the DASD volume reserved for "DUMP" space was online to the VM/ESA 240 system and also to the z/VM 510 system (running in another LPAR on the same machine). Unfortunately, <blush> I discovered that only after VM:Operator on the z/VM 520 system, which had been running fine for weeks, took a VMDUMP. It wrote its VMDUMP to the accidentally shared dump DASD. More unfortunately, several VM/ESA production SDFs (System Data Files) had been accidentally written to that dump DASD - some of which were written over by the new VMDUMP.
We cleaned up the mess pretty quickly (the nightly SDF backup taken by VM:Spool really saved time). I immediately updated the "SYSTEM CONFIG" file, placing a "record qualifier" of the production "System_Identifier" on the CP_OWNED record that defined the DUMP space and also other sysres DASD so that only the LPAR in which we run our production VM system would have the "dump" and sysres DASD as CP_Owned. That kept the test LPAR from putting dumps there any more, or accidentally using the VM/ESA system's directory, etc.
Now getting to the example. When we were performing a D.R. test the next May, we IPLed the production VM system sysres on another box. The "System_Identifier" for that CPU was set to "RECOVERY", not the production system. Since it did not match, it would not allow the IPLed sysres to come online. Instead it issued message (if I remember correctly):
HCP912W System recovery failure; volid VMR51A not mounted.
followed by a Disabled Wait State. (VMR51A is our primary z/VM 5.1.0 sysres). The "Operator response" is to mount the volume -- hard to do from a Disabled Wait State. The "Programmer response" is to ensure that the volume is CP Formatted (it was), and in the CP OWNED VOLUME LIST (it was - sort of).
What actually happened was that during IPL, CP found the "PARM" disk, read the SYSTEM CONFIG, included only those CP_Owned volumes that matched the "record qualifiers" (ours did not match at the time; "RECOVERY" was added later that morning), and those without record qualifiers. Since the sysres was removed from CP_Owned list as part of SYSTEM CONFIG processing, the message and Disabled Wait State resulted. <blush*2>
In my eyes, that sequence is pretty good empiric proof that the answer to "Then which comes first, the system config file is read and acted upon accordingly or is the page pack searched for first." would be: SYSTEM CONFIG is read first, and acted on accordingly.
Fortunately, we had another VM system from which we could IPL and issue the (earlier-discussed-today use of the CP command) "DEFINE MDISK" command -- providing a fine real-life example of "oops/recovery" from shooting myself directly in the foot. That week we also built a single-volume z/VM system which can be IPLed without any other DASD requirements - handy for using DEFINE MDISK and then XEDIT to fix files. One 3390-3 is cheap compared to not being able to IPL. Since that system is merely a tool to let us edit and fix files, we call that system the "Virtual Machine Operating System Hipervisor Tool", and built a LOGO screen and labeled the DASD accordingly: VMOSHT.
Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.
| "Steve Gentry"
<[EMAIL PROTECTED]>
Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 06/29/2006 03:01 PM
|
|
Then which comes first, the system config file is read and acted upon accordingly
or is the page pack searched for first. And if the address is in the offline list in the system
config file, can the address be brought on line after VM is up and relabeled/reformatted?
Steve
The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited.
