Mike, That's a good approach. Our VM is also used to start 16 MVS and 1 VM in a Disaster Recovery case. I have checked if a dasd shared but no. I received my z/VM530 too but the dasds are dedicated. The idea of a last cyl that is not formated is a probality. I did a cp vol list to verify that and that's ok (and I always use FORMAT rather than ALLOCATE with ickdsf). But you can be true with the system dasd sent in the systempac. Allocations look good but could be partially formated. It means i should not trust in what IBM delivered to me. Hard to believe.
We don't have a IBM support (but I have a good collegue who helps me at IBM), we (my client) prefer to give less money for a concurrent to get a support (When I call I start to say 'I have a problem with VM on Mainframe', the support says 'Vmware on windows ?, you don't have a contract for that ...etc). Most of time, I let the guy talk in the phone and I go to take my lesson yoga ... VM is dying in France. I should try in the US I suppose. Alain Benveniste Le 3/02/08 0:58, « Mike Walter » <[EMAIL PROTECTED]> a écrit : > Is it possible that a different system (even a second level guest) wrote > to that DASD, or that there's a minidisk allocated on that DASD and > something wrote to the minidisk? > > Since you're 100% certain (right?) that the CP_Owned slot numbers were not > changed, the only other thing I can think of is that maybe the disk was > never FULLY formatted. E.g. it's easy to think of a 3390-3 disk as 3,338 > cylinders, and format 0-3,337 (forgetting that it is actually 3,339 > cylinders - thus leaving the true last cylinder not CP-formatted). You'll > run along just fine until one day when the system finally writes to that > slot on cylinder 3,339 and crashes. It won't be obvious why you crashed, > and you will continue to run just fine until the system once again tries > to write to that slot. But the dump will probably have some breadcrumbs > showing which slot was being written. > > Why not open a PMR? Get your money's worth from your support contract! > > Mike Walter > Hewitt Associates > Any opinions expressed herein are mine alone and do not necessarily > represent the opinions or policies of Hewitt Associates. > > > > Alain Benveniste <[EMAIL PROTECTED]> > > Sent by: "The IBM z/VM Operating System" <[email protected]> > 02/02/2008 07:17 AM > Please respond to > "The IBM z/VM Operating System" <[email protected]> > > > > To > [email protected] > cc > > Subject > Abend PGT003 > > > > > > > Hi, > > PGT003 Explanation: The DASD page slot being released was not previously > allocated, or the slot address is incorrect. > > User response: By means of the caller?s return address and base registe > r > stored in SAVER14 and SAVER12 in the SAVBK located by R13, identify the > module attempting to release the page. Locate the source (control block o > r > ASATE) of the address of the DASD being released to verify that it has no > t > been destroyed. If the DASD page is in a spool file, it is possible that > the > file has been incorrectly checkpointed and warm-started after a system > shutdown or a system crash. > > > I got 2 PGT003 abends in 2 weeks. And I don't find the reason. > All my DASD pages are always allocated with a %>0 and I never changed a s > lot > address since the install. So I suppose that 'a DASD page is in a spool > file' but I don't understand what that means. How to konw that ? > And if I do a FORCE start, would it be enough or should I do a COLD start > to > definitely remove my problem ? > > Alain Benveniste > > > > > > 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. All messages sent to and from this e-mail address may be monitored > as permitted by applicable law and regulations to ensure compliance with our > internal policies and to protect our business. Emails are not secure and > cannot be guaranteed to be error free as they can be intercepted, amended, > lost or destroyed, or contain viruses. You are deemed to have accepted these > risks if you communicate with us by email. >
