Is there any chance of some other SVM issuing a 'CP SEND' or 'CP FOR' command to the server running WAKEUP and experiencing the unexpected interrupt?
Of course, in such a case of one disconnected SVM waking another up in that manner, one might expect to hear the faint strains of "Dueling Banjos" playing softly in the background! ;-) Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. "Martha McConaghy" <u...@vm.marist.edu> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 09/14/2009 09:08 AM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Problem that is a blast from the past... Yes, I aware of that. The issue is why the console interrupt is happening in the first place. I haven't been able to track down a cause. So, I've just taken CONS out at this point. Its not worth spending so much time on. Martha On Mon, 14 Sep 2009 11:15:05 +0200 Kris Buelens said: >Note: by coding an explicit CONS option on WAKEP, it will stop with RC=6 >when there is something in the stack when WAKEUP is started. May that be >the problem? >At the other hand: I don't see a TIME option on the WAKEUP command in the >first append, so WAKEUP would not stack 3 lines but only 2. > >2009/9/10 Cal <c...@the-fishers.com> > >> Hi Martha >> Where did this exec come from? >> The way that wakeup works is it always stacks the next line from the times >> file. Actually it stacks 3 lines >> 1. Current date and time >> 2. Line from Wakeup Times file >> 3. SPM, VMCF, SMSG, IUCV message, IO or externat interrupt data. >> So if you wrote your own exec you are using the stack the line that you are >> really intersted in is the last line on the stack. If you pull the line from >> the times file and execute it you will leave something on the stack and >> wakeup will exit. >> The 300 secs come from the +5 >> >> Cal Fisher >> MVMUA website >http://www2.marist.edu/~mvmua/<http://www2.marist.edu/%7Emvmua/> >> My Navy memoirs http://www.the-fishers.com/cal/Navy >> >> >> >> ----- Original Message ----- From: "Martha McConaghy" <u...@vm.marist.edu> >> To: <IBMVM@LISTSERV.UARK.EDU> >> Sent: Wednesday, September 09, 2009 5:58 PM >> Subject: Re: Problem that is a blast from the past... >> >> >> That's the strange part, there is nothing. This is happening on VM >>> systems >>> with very little going on, so there isn't any "noise". Here's what the >>> console looks like when it happens: >>> >>> DMSCYW2246I 15:06:26 WAKEUP in (299 sec). >>> DMSCYW2246I* 00066 ==/==/== +5 15:11:26 EXEC HOBVARS >>> DMSCYW2246I* 00067 ==/==/== +5 15:11:26 EXEC HOBVMCPU >>> DMSCYW2246I* 00068 ==/==/== +5 15:11:26 EXEC HOBVMPRC >>> Number of VMs: 19 >>> DMSCYW2246I* 00070 ==/==/== +5 15:11:26 EXEC HOBVMDSK >>> DMSCYW2246I* 00071 ==/==/== +5 15:11:26 EXEC HOBVMFLE >>> DMSERS002E File HOBVM700 CLIENT A not found >>> DMSCYW2246I* 00072 ==/==/== +5 15:11:26 EXEC HOBVMPOR >>> DMSCYW2246I* 00073 ==/==/== +5 15:11:26 EXEC HOBVMIFC >>> DMSCYW2246I* 00077 ==/==/== +5 15:11:26 EXEC HOBVMCD >>> DMSCYW2246I 15:11:26 WAKEUP in (300 sec). <--300 secs always shows up >>> DMSCYW2246I* 00066 ==/==/== +5 15:11:26 EXEC HOBVARS >>> DMSCYW2246I* 00066 ==/==/== +5 15:11:26 EXEC HOBVARS <--This isn't right >>> Console interrupt... queue: 2 >>> Queue data: * 00066 ==/==/== +5 15:11:26 EXEC HOBVARS <--my diags >>> Queue data: * 00066 ==/==/== +5 15:11:26 EXEC HOBVARS <--my diags >>> >>> The sequence is to run HOBVARS, HOBVMCPU, HOBVMPRC, HOBVMDSK, HOBVMFLE, >>> HOBVMPOR, HOBVMIFC and then HOBVMCD. It sleeps and then starts over. >>> Whenever I see the "WAKEUP in (300 sec)" I know it is going to fail. >>> If the time is anything less than 300 sec, then it will be OK. It happens >>> too consistently to be a coincidence. When it fails, HOBVARS always shows >>> up twice. I think that maybe what is being interpreted as a console >>> interrupt, i.e. someone typing on the console. I can't see any reason >>> why that happens. HOBVARS never gets run at that point. I've put >>> traces on it and it doesn't get executed. Its almost like WAKEUP >>> is getting confused. Could there be something on the program stack that >>> is getting it messed up? >>> >>> Is there any way to trace what WAKEUP is doing? >>> >>> Martha >>> >>> On Wed, 9 Sep 2009 23:50:38 +0200 Alan Altmark said: >>> >>>> On Wednesday, 09/09/2009 at 05:26 EDT, Martha McConaghy >>>> <u...@vm.marist.edu> wrote: >>>> >>>>> >>>>> WAKEUP +5 ( CONS EXT SMSG FILE(HOBBIT TIMES *) >>>>> >>>>> Sometimes, it will run through a sequence and then exit, sometimes it >>>>> >>>> will run >>>> >>>>> for several days before it happens. This is happening on different >>>>> >>>> systems >>>> >>>>> to, not just on one VM system. I suspect that some silly thing is not >>>>> >>>> set >>>> >>>>> correctly, but I have no idea what. I finally did a CP TRACE EXT on >>>>> one of them and found that it is getting an external interrupt code >>>>> >>>> 1004. >>>> >>>>> According to my trusty old reference book, that is a "clock comparator" >>>>> interrupt. That is what is causing WAKEUP to stop with RC=6. >>>>> >>>> >>>> While it's true that EXT 1004 is a timer pop, RC=6 from WAKEUP indicates >>>> it detected a console I/O interrupt. I am wondering if some sort of >>>> automation sequence (CP SEND) is bothering the virtual machine. Since >>>> there's no QUIET option, the reason for the wakeup should be in the >>>> console. >>>> >>>> Alan Altmark >>>> z/VM Development >>>> IBM Endicott >>>> >>> > > >-- >Kris Buelens, >IBM Belgium, VM customer support > 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. E-mails 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 e-mail.
