The dasd is accessible to more than one system; however, it is protected by the 
VM:Secure Rules Facility to only allow access by 3 userids, one of them being 
mine. I have discussed this with the other 2 users and both say that they have 
not touched the disks of the other system except one instance when one of them  
added to the Devices_Offline_at_IPL list in September. For that, she had to 
logon to the small system to do the CPRELEASE / Update / CPACCESS sequence. We 
can update those disks from the larger system iff the small system is down, and 
we know it. It is a production system and is normally running 24X7. We have to 
schedule any down time so that it falls within a narrow maintenance window. And 
we will pay dearly if we knock it down by doing silly things like reformatting 
one of its disks.

I have yet to see formatting the disk as a plausible explanation. The 
allocation map, record 0/0/4 did not get touched. IPL1, record 0/0/1, which is 
not constructed so as to cause a disabled wait, was not touched. Format would 
have clobbered both, but that did not happen. IPL2, record 0/0/2, did not get 
completely zeroed. Format would have done that. Unless there are strange code 
paths in format which just happened to be used, this phenomenon cannot be 
explained by FORMAT. 

And I don't think for a minute that Chuckie wrote ICKDFS.

Regards,
Richard Schuh

 -----Original Message-----
From:   The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]  On Behalf Of 
Brian Nielsen
Sent:   Tuesday, October 31, 2006 2:16 PM
To:     [email protected]
Subject:        Re: Corrupted IPL Record

If the DASD is accessible by more than one system, perhaps some activity =

on the other system is the source of the corruption.

Brian Nielsen

On Tue, 31 Oct 2006 13:29:48 -0800, Schuh, Richard <[EMAIL PROTECTED]> wrot=
e:

>Neither one is on the system where the corruption occurred. It is so 
specialized and stable that there is rarely any need to even look at the =

directory, much less update it. We have access to the disks from our main=
 
VM system, so we allocate new M-disks there using VM:Secure and copy the =

resulting mdisk statements to the small system.  
> 
>Regards,
>Richard Schuh

Reply via email to