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 >
