When I did the ALLOCATE (cpfmtxa vdev vser allocate), the correct current
allocation map was displayed before the new extents were entered. I reallocated
only the new areas, changing existing PARMs to PERM and defining new PARM
extents in what had been PERM space. I did not reenter any of the other, DRCT,
SPOL, or TDSK, allocations. Following the allocation, the correct new extents
were displayed. See the current allocation map, below.
ICK03021I 7618 IS FORMATTED FOR VM/XA|ESA MODE
CYLINDER ALLOCATION CURRENTLY IS AS FOLLOWS:
TYPE START END TOTAL
---- ----- --- -----
PERM 0 30 31
DRCT 31 47 17
PERM 48 55 8
TDSK 56 105 50
PERM 106 2483 2378
PARM 2484 2558 75
PERM 2559 2899 341
SPOL 2900 3099 200
PARM 3100 3174 75
PERM 3175 3338 164
ICK00001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
FORMAT writes a record of all zeros for 0/0/2; there are no odd bits turned on
in it. The scattered bits in the first 200 bytes of the record are an
indication that cylinder 0 had not been reformatted. Further, it could not have
been an accidental implied format as in "cpfmtxa vdev vser" because that would
have formatted the entire volume, not just almost zero out 0/0/2. I am not
quick enough to stop such an accident in time to avert disaster if that were
the case. The original parm disk, which was located in cylinders 1-30, is still
intact - I just checked.
Regards,
Richard Schuh
-----Original Message-----
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of
Stephen P. Frazier
Sent: Tuesday, October 31, 2006 10:19 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Corrupted IPL Record
Your symptoms sound very much like a FORMAT was done on cylinder 0 of
the disk. If you do a FORMAT without the IPL data it will write in
record 2 an IPL program to put the processor in a hard wait. It will
also write the dummy VTOC and an allocation map showing the entire pack
is PERM space. Then you did an ALLOCATE which fixed the allocation map
for the disk. Look at the other tracks on cylinder 0. If they were
erased then that is probably what happened. If the other tracks on
cylinder 0 were not erased then I have no idea what could have happened.
[EMAIL PROTECTED] wrote:
> Just ALLOCATE. Format would have been more devastating.
>
> Regards,
> Richard Schuh
>
> -----Original Message-----
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of
> Kris Buelens
> Sent: Monday, October 30, 2006 1:56 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Corrupted IPL Record
>
> You didn't perform both FORMAT and ALLOCATE?
>
> Kris,
> IBM Belgium, VM customer support
>
>
>
>
> "Schuh, Richard" <[EMAIL PROTECTED]>
> Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
> 2006-10-30 21:32
> Please respond to
> The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
>
>
> To
> IBMVM@LISTSERV.UARK.EDU
> cc
>
> Subject
> Corrupted IPL Record
>
>
>
>
>
> If this shows up twice, I apologize. I first sent it 2 hours ago and it
> hasn't hit the archives as yet.
>
>
> Over the weekend, we upgraded our final system to 5.2. As a part of the
> migration, we changed old PARM extents to PERM and allocated new PARM
> extents. When we tried to ipl the system, there were errors that led me to
> the conclusion that the IPL program had been corrupted. Using DDR on
> another system, I observed that record 0 0 2 had been completely wiped
> out. There were a few scattered bits that were not 0 in the first 100-200
> bytes, nothing that was any kind of pattern, and the rest of the record
> was all 0. Records 1, and 3-6 were all as they should have been. I had to
> run SALIPL to fix the IPL program.
>
> I am not blaming CPFMTXA ALLOCATE because I think it highly unlikely that
> it was the cause. I suspect that something else happened between the
> previous IPL and yesterday's failed attempt. Has anyone else seen this
> kind of corruption or are we, once again, unique?
>
> Regards,
> Richard Schuh
--
Stephen Frazier
Information Technology Unit
Oklahoma Department of Corrections
3400 Martin Luther King
Oklahoma City, Ok, 73111-4298
Tel.: (405) 425-2549
Fax: (405) 425-2554
Pager: (405) 690-1828
email: stevef%doc.state.ok.us
