Re: Abend PGT003
I did not change anything in the system about page and spool dasd since the 1st day of install. After my 1st abend, I supposed something was 'corrupted' in my nss/dcss. So this week I rebuilt all the segments with success. I was waiting for the next IPL, Saturday, for the nss cleanup. Unfortunately IPL came on Friday. OK, it could explain my 2nd abend but not the 1st one. Thanks for these suggestions Alain Benveniste Le 2/02/08 22:14, « Dale R. Smith » [EMAIL PROTECTED] a écrit : Since you are on z/VM 4.4.0, I would guess that you have been running it for a while. So my first question would be: What changed two weeks ago? Have you added/removed Paging or Spool space? When was the last time tha t you IPLed? Have you installed/upgraded/removed any VM products? Created/saved/purged any DCSSes or NSSes? Questions, questions! :-)
Re: Abend PGT003
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 IBMVM@LISTSERV.UARK.EDU 02/02/2008 07:17 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU 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.
Re: Abend PGT003
On Saturday, 02/02/2008 at 07:00 EST, Mike Walter [EMAIL PROTECTED] wrote: 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? There are 8 possible reasons for a PGT003 abend. It takes a dump and program listing of HCPPGT to figure it out. Alan Altmark z/VM Development IBM Endicott
Re: Abend PGT003
Open a problem with IBM and send the dump in for analysis. I never had a problem that required a COLD start, and my SPOOL areas are very old: when I install a new VM release I only change the CPLOAD module. So I guess they date from VM/ESA 2.2.0 2008/2/2, Alain Benveniste [EMAIL PROTECTED]: 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 -- Kris Buelens, IBM Belgium, VM customer support
Re: Abend PGT003
Alain, Did you process the DUMPs ... or do you still have them to process (likely in OPERATNS RDR)? Open a PMR with IBM and they can help you figure out what the problem is. JR JR (Steven) Imler CA Senior Software Engineer Tel: +1 703 708 3479 Fax: +1 703 708 3267 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alain Benveniste Sent: Saturday, February 02, 2008 08:18 AM To: IBMVM@LISTSERV.UARK.EDU 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
Re: Abend PGT003
Jr, Yes I have the dump. I even try to find something interesting with the symptom macro but I cqn't go far with that; I have no competence to read a dump. I could open a PMR but we are z/VM440 ... If you see what I mean. I search on the IBM site for a ptf. The unique one referenced is for VM 3.1. That's old Alain Le 2/02/08 14:39, « Imler, Steven J » [EMAIL PROTECTED] a écrit : Alain, Did you process the DUMPs ... or do you still have them to process (likely in OPERATNS RDR)? Open a PMR with IBM and they can help you figure out what the problem is. JR JR (Steven) Imler CA Senior Software Engineer Tel: +1 703 708 3479 Fax: +1 703 708 3267 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alain Benveniste Sent: Saturday, February 02, 2008 08:18 AM To: IBMVM@LISTSERV.UARK.EDU 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
Re: Abend PGT003
Ah, yes ... z/VM 4.4.0 ... that likely would be a problem. Can you determine the RUNUSER (the UserID that CP thinks caused the ABEND)? That might help to figure out what might have been happening when the ABEND occurred ... (please don't say HiDRO :-) JR JR (Steven) Imler CA Senior Software Engineer Tel: +1 703 708 3479 Fax: +1 703 708 3267 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alain Benveniste Sent: Saturday, February 02, 2008 09:04 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Abend PGT003 Jr, Yes I have the dump. I even try to find something interesting with the symptom macro but I cqn't go far with that; I have no competence to read a dump. I could open a PMR but we are z/VM440 ... If you see what I mean. I search on the IBM site for a ptf. The unique one referenced is for VM 3.1. That's old Alain Le 2/02/08 14:39, « Imler, Steven J » [EMAIL PROTECTED] a écrit : Alain, Did you process the DUMPs ... or do you still have them to process (likely in OPERATNS RDR)? Open a PMR with IBM and they can help you figure out what the problem is. JR JR (Steven) Imler CA Senior Software Engineer Tel: +1 703 708 3479 Fax: +1 703 708 3267 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alain Benveniste Sent: Saturday, February 02, 2008 08:18 AM To: IBMVM@LISTSERV.UARK.EDU 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
Re: Abend PGT003
Since you are on z/VM 4.4.0, I would guess that you have been running it for a while. So my first question would be: What changed two weeks ago? Have you added/removed Paging or Spool space? When was the last time tha t you IPLed? Have you installed/upgraded/removed any VM products? Created/saved/purged any DCSSes or NSSes? Questions, questions! :-) -- Dale R. Smith It's just a simple matter of programming. - Any boss who has never written a program On Sat, 2 Feb 2008 15:04:23 +0100, Alain Benveniste [EMAIL PROTECTED] wrote: Yes I have the dump. I even try to find something interesting with the symptom macro but I cqn't go far with that; I have no competence to read a dump. I could open a PMR but we are z/VM440 ... If you see what I mean. I sear ch on the IBM site for a ptf. The unique one referenced is for VM 3.1. That 's old Alain -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alain Benveniste Sent: Saturday, February 02, 2008 08:18 AM To: IBMVM@LISTSERV.UARK.EDU 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 syste m 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
Re: Abend PGT003
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 IBMVM@LISTSERV.UARK.EDU 02/02/2008 07:17 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU 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.
