Well, I have been reading system directory and the fact of starting the page
area in cyl. 0 doesn't seem to be the cause of this problem. Originally the
system-defined system page area is defined as:
USER $PAGE$ NOLOG
MDISK A03 3390 000 END 520PAG R
MDISK A04 3390 000 END 520PG1 R <-- This is the one we added later,
the one causing the problem.
*
So, as you can see, the system-default defined one also starts in cyl. 0.
*** z/VM INSTALLATION DASD FORMAT/RESTORE ***
PACK DASD DASD VIRTUAL TAPE DO NOT
TYPE LABEL ADDRESS ADDRESS FORMAT DASD
====== ======== ========= ============== =============
RES 520RES 314_ 181 _
SPOOL 520SPL 315_
PAGE 520PAG 33F_
USER 520W01 368_
USER 520W02 369_
HCPIIX8377R YOU HAVE SELECTED TO FORMAT THE FOLLOWING DASD:
520RES 0314
520SPL 0315
520PAG 033F <-- original page area device
520W01 0368
520W02 0369
DO YOU WANT TO CONTINUE ? (Y/N)
Y
HCPIIX8490I NOW FORMATTING DASD 0314
HCPIIX8490I NOW FORMATTING DASD 0315
HCPIIX8490I NOW FORMATTING DASD 033F <-- Here being formatted
END OF JOB
HCPIIX8490I NOW ALLOCATING DASD 0314 (RES PACK)
HCPIIX8490I NOW ALLOCATING DASD 0315 (SPOOLING)
HCPIIX8490I NOW ALLOCATING DASD 033F (PAGING) <-- Here being allocated.
Could it be here the difference ?
HCPINI8392I INSTIIS EXEC ENDED SUCCESSFULLY
Ready;
The difference must reside in that 1-3338 must have been performed at alloc
time (at z/VM installation time) instead of 0-3338 which is what we have
(erroneously ?) done.
So, we're going to define a new page device equally directory-defined as
520PAG (that is, 0-END), then we're going to CPFMTXA FORMAT it and then
ALLOCATE 1-3338 this time.
If this problem still persists (we have formatted the disk and allocated it
exactly like 520PAG, so same definition should imply same functioning) we
better search for a new job, like Bill Gates.
Do you agree with this plan ?
Saludos,
José R. Barón
Dpto. Sistemas
CALCULO S. A.
Tel. 91 330 86 44
e-mail: [EMAIL PROTECTED]
P No imprima este e-mail si no es realmente necesario
-----Mensaje original-----
De: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] En nombre
de Kris Buelens
Enviado el: lunes, 07 de enero de 2008 8:46
Para: IBMVM@LISTSERV.UARK.EDU
Asunto: Re: AW: z/VM 5.2 Absurd System shutdown - PJBR
I tried them all again: PAGE, SPOL, TDSK is protected:
Ready KRIS at VMKBCT01 ; T=0.01/0.01 08:33:08
link * 1 1 MR cse
Ready KRIS at VMKBCT01 ; T=0.01/0.01 08:33:13
link * 2 2 MR DRCT
Ready KRIS at VMKBCT01 ; T=0.01/0.01 08:33:18
link * 3 3 MR PAGE
HCPLNM1152E KRIS 0003 has not been linked because
it would overlap system paging space.
Ready KRIS at VMKBCT01 (01152); T=0.01/0.01 08:33:22
link * 4 4 MR Spool
HCPLNM1152E KRIS 0004 has not been linked because
it would overlap system spool space.
Ready KRIS at VMKBCT01 (01152); T=0.01/0.01 08:33:27
link * 5 5 MR ckpt
Ready KRIS at VMKBCT01 ; T=0.01/0.01 08:33:31
link * 6 6 MR Warm
Ready KRIS at VMKBCT01 ; T=0.01/0.01 08:33:35
link * 7 7 MR Tdsk
HCPLNM1152E KRIS 0007 has not been linked because
it would overlap system temporary disk space.
Ready KRIS at VMKBCT01 (01152); T=0.01/0.01 08:33:38
So the problem is probably caused by that the page area was never
properly formatted.
2008/1/7, Alan Ackerman <[EMAIL PROTECTED]>:
> On Fri, 4 Jan 2008 14:09:05 +0100, Fritz, Wilhelm <[EMAIL PROTECTED]> wr
> ote:
>
> Sounds like you have some other minidisk defined overlaying your page spa
> ce. When one of your
> virtual machines writes to it, it causes paging errors.
>
> Take a look at your directory. You should have NO other minidisks defined
> in the range 0-3338
> on device 520PG1 02D5. (Or overlaying the other page pack, either.)
>
> Alan Ackerman
> Alan (dot) Ackerman (at) Bank of America (dot) com
>
--
Kris Buelens,
IBM Belgium, VM customer support
