I don't know if this is a problem now, but....back in the old days...
1. Format the pack first. You can even format cyl 0
2. Alloc the pack second. It will lay down the bit pattern needed.
If you did the opposite, the format destroyed your alloc.
But that isn't your problem. I believe that the default is "perm"
space. So, you wouldn't have been able to use the pack as CP area, even
if it is in the CP LIST.
My guess, because I have done the same thing....long time ago...
You CP formatted 1 to xxx number of cylinders but allocated 1 FOR xxx
cylinders. The last cylinder doesn't get formatted. When you start
using a lot of page space, you eventually will try to write on the last,
unformatted cylinder.
Tom Duerbusch
THD Consulting
Law of Cat Elongation
A cat can make her body long enough to reach just about any
counter top that has anything remotely interesting on it.
>>> Jose Raul Baron <[EMAIL PROTECTED]> 1/8/2008 10:15 AM >>>
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: [email protected]
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
