Re: Problem that is a blast from the past...
Kris, Your RxServer is more modern than my VMSERVE and has the advantage of your continual support, which I can't do w/o access to a VM system. Also, your technical knowledge has grown since I retired (and so has VM), so RxServe may have features that VMSERVE wasn't capable of. VMSERVE is aimed at the Application Developer and my point in posting my PLUG was to raise awareness that many of the WAKEUP problems posted have already been solved with VMSERVE and the programmer can concentrate on his Business Application. As old and tired as VMSERVE is, I notice that it still gets plenty of downloads, so at least some folks are exploring its usability. I'm indebted to the original author (Rick Holt, at Yorktown) who transferred ownership to me back in the 80's and to the internal IBM community for their continuous feedback until I retired at the end of May, 2004. Les Kris Buelens wrote: We had about 7 servers in each of up to 18 VM systems to manage, all based on RxServer, and obviously we were able to do it all from one location. 2009/9/16 Les Koehler Iirc, Pipes provides the facilities to negate the problem, but I don't remember the details. Interested parties might want to investigate/try my VMSERVE PACKAGE from the VM Download Library. It's a little old now, but when I retired it was widely used within IBM, saving lots of folks a lot of effort in setting up and running service machines. My responsibilities in Global Services required me to monitor, at one time, about 15 service machines across four systems connected via RSCS. All the monitoring was automated and I was only notified of unexpected or missing events. I could even schedule changes remotely, have them installed on the fly, notify interested parties of their success or failure and automatically back them off if they failed to install. Les Chip Davis wrote: I'm sorry to rise to the bait, but the nearly universal misunderstanding of the MAKEBUF command is one of my sore spots. There is absolutely nothing about MAKEBUF that provides any sort of separation of the records in the program stack. Successive reads from the stack will completely ignore any MAKEBUF point and happily continue to read records until the stack is empty, with no indication that a MAKEBUF point was passed. To ensure that no more records are read from the program stack than were placed there after a MAKEBUF, it is necessary to do a Rexx Queued() or SENTRIES command at the MAKEBUF point to determine how many records are already on the stack, and then remove no more than were added after the MAKEBUF. This essentially renders the MAKEBUF/DROPBUF superfluous. The ONLY thing that MAKEBUF does is to reset the FIFO pointer to equal the LIFO pointer. This is quite handy because it allows one to place a group of records on the top of the stack in FIFO order. Without MAKEBUF, this operation would require reading all the records off the stack, stacking the new records FIFO, then restacking FIFO the original records. The closest that MAKEBUF comes to a "separate what you place in the stack from what is already there" operation, is that if all of the records that were added to the program stack after a MAKEBUF command are not removed, the remaining records can be deleted with the appropriate DROPBUF. If at some point, CMS is given the benefit of multiple program stacks (as in the TSO/REXX environment) you could truly "separate what you place in the stack from what is already there" by placing the new records in a new stack. At that point, MAKEBUF and DROPBUF will become vestigial. TSO/REXX's NEWSTACK/DELSTACK commands and the ability to create "a stack of stacks" is what everyone seems to think MAKEBUF/DROPBUF provides. -Chip- On 9/15/09 15:49 Kris Buelens said: Yes, DROPBUF 0 would be even better, a MAKEBUF is not required in such a server I'd say: you'd use it to separate what you place in the stack from what is there already, but as you code DROPBUF 0, there is surely nothing anymore to separate your stuff from.
Re: Problem that is a blast from the past...
We had about 7 servers in each of up to 18 VM systems to manage, all based on RxServer, and obviously we were able to do it all from one location. 2009/9/16 Les Koehler > Iirc, Pipes provides the facilities to negate the problem, but I don't > remember the details. > > > Interested parties might want to investigate/try my VMSERVE PACKAGE from > the VM Download Library. It's a little old now, but when I retired it was > widely used within IBM, saving lots of folks a lot of effort in setting up > and running service machines. > > My responsibilities in Global Services required me to monitor, at one time, > about 15 service machines across four systems connected via RSCS. All the > monitoring was automated and I was only notified of unexpected or missing > events. > > I could even schedule changes remotely, have them installed on the fly, > notify interested parties of their success or failure and automatically > back them off if they failed to install. > > > Les > > Chip Davis wrote: > >> I'm sorry to rise to the bait, but the nearly universal misunderstanding >> of the MAKEBUF command is one of my sore spots. >> >> >> There is absolutely nothing about MAKEBUF that provides any sort of >> separation of the records in the program stack. Successive reads from the >> stack will completely ignore any MAKEBUF point and happily continue to read >> records until the stack is empty, with no indication that a MAKEBUF point >> was passed. >> >> To ensure that no more records are read from the program stack than were >> placed there after a MAKEBUF, it is necessary to do a Rexx Queued() or >> SENTRIES command at the MAKEBUF point to determine how many records are >> already on the stack, and then remove no more than were added after the >> MAKEBUF. This essentially renders the MAKEBUF/DROPBUF superfluous. >> >> The ONLY thing that MAKEBUF does is to reset the FIFO pointer to equal the >> LIFO pointer. This is quite handy because it allows one to place a group of >> records on the top of the stack in FIFO order. Without MAKEBUF, this >> operation would require reading all the records off the stack, stacking the >> new records FIFO, then restacking FIFO the original records. >> >> The closest that MAKEBUF comes to a "separate what you place in the stack >> from what is already there" operation, is that if all of the records that >> were added to the program stack after a MAKEBUF command are not removed, the >> remaining records can be deleted with the appropriate DROPBUF. >> >> >> If at some point, CMS is given the benefit of multiple program stacks (as >> in the TSO/REXX environment) you could truly "separate what you place in the >> stack from what is already there" by placing the new records in a new stack. >> At that point, MAKEBUF and DROPBUF will become vestigial. TSO/REXX's >> NEWSTACK/DELSTACK commands and the ability to create "a stack of stacks" is >> what everyone seems to think MAKEBUF/DROPBUF provides. >> >> -Chip- >> >> On 9/15/09 15:49 Kris Buelens said: >> >>> Yes, DROPBUF 0 would be even better, a MAKEBUF is not required in such a >>> server I'd say: you'd use it to separate what you place in the stack from >>> what is there already, but as you code DROPBUF 0, there is surely nothing >>> anymore to separate your stuff from. >>> >> >> >> -- Kris Buelens, IBM Belgium, VM customer support
Re: Problem that is a blast from the past...
Iirc, Pipes provides the facilities to negate the problem, but I don't remember the details. Interested parties might want to investigate/try my VMSERVE PACKAGE from the VM Download Library. It's a little old now, but when I retired it was widely used within IBM, saving lots of folks a lot of effort in setting up and running service machines. My responsibilities in Global Services required me to monitor, at one time, about 15 service machines across four systems connected via RSCS. All the monitoring was automated and I was only notified of unexpected or missing events. I could even schedule changes remotely, have them installed on the fly, notify interested parties of their success or failure and automatically back them off if they failed to install. Les Chip Davis wrote: I'm sorry to rise to the bait, but the nearly universal misunderstanding of the MAKEBUF command is one of my sore spots. There is absolutely nothing about MAKEBUF that provides any sort of separation of the records in the program stack. Successive reads from the stack will completely ignore any MAKEBUF point and happily continue to read records until the stack is empty, with no indication that a MAKEBUF point was passed. To ensure that no more records are read from the program stack than were placed there after a MAKEBUF, it is necessary to do a Rexx Queued() or SENTRIES command at the MAKEBUF point to determine how many records are already on the stack, and then remove no more than were added after the MAKEBUF. This essentially renders the MAKEBUF/DROPBUF superfluous. The ONLY thing that MAKEBUF does is to reset the FIFO pointer to equal the LIFO pointer. This is quite handy because it allows one to place a group of records on the top of the stack in FIFO order. Without MAKEBUF, this operation would require reading all the records off the stack, stacking the new records FIFO, then restacking FIFO the original records. The closest that MAKEBUF comes to a "separate what you place in the stack from what is already there" operation, is that if all of the records that were added to the program stack after a MAKEBUF command are not removed, the remaining records can be deleted with the appropriate DROPBUF. If at some point, CMS is given the benefit of multiple program stacks (as in the TSO/REXX environment) you could truly "separate what you place in the stack from what is already there" by placing the new records in a new stack. At that point, MAKEBUF and DROPBUF will become vestigial. TSO/REXX's NEWSTACK/DELSTACK commands and the ability to create "a stack of stacks" is what everyone seems to think MAKEBUF/DROPBUF provides. -Chip- On 9/15/09 15:49 Kris Buelens said: Yes, DROPBUF 0 would be even better, a MAKEBUF is not required in such a server I'd say: you'd use it to separate what you place in the stack from what is there already, but as you code DROPBUF 0, there is surely nothing anymore to separate your stuff from.
Re: Problem that is a blast from the past...
I'm sorry to rise to the bait, but the nearly universal misunderstanding of the MAKEBUF command is one of my sore spots. There is absolutely nothing about MAKEBUF that provides any sort of separation of the records in the program stack. Successive reads from the stack will completely ignore any MAKEBUF point and happily continue to read records until the stack is empty, with no indication that a MAKEBUF point was passed. To ensure that no more records are read from the program stack than were placed there after a MAKEBUF, it is necessary to do a Rexx Queued() or SENTRIES command at the MAKEBUF point to determine how many records are already on the stack, and then remove no more than were added after the MAKEBUF. This essentially renders the MAKEBUF/DROPBUF superfluous. The ONLY thing that MAKEBUF does is to reset the FIFO pointer to equal the LIFO pointer. This is quite handy because it allows one to place a group of records on the top of the stack in FIFO order. Without MAKEBUF, this operation would require reading all the records off the stack, stacking the new records FIFO, then restacking FIFO the original records. The closest that MAKEBUF comes to a "separate what you place in the stack from what is already there" operation, is that if all of the records that were added to the program stack after a MAKEBUF command are not removed, the remaining records can be deleted with the appropriate DROPBUF. If at some point, CMS is given the benefit of multiple program stacks (as in the TSO/REXX environment) you could truly "separate what you place in the stack from what is already there" by placing the new records in a new stack. At that point, MAKEBUF and DROPBUF will become vestigial. TSO/REXX's NEWSTACK/DELSTACK commands and the ability to create "a stack of stacks" is what everyone seems to think MAKEBUF/DROPBUF provides. -Chip- On 9/15/09 15:49 Kris Buelens said: Yes, DROPBUF 0 would be even better, a MAKEBUF is not required in such a server I'd say: you'd use it to separate what you place in the stack from what is there already, but as you code DROPBUF 0, there is surely nothing anymore to separate your stuff from.
Re: Problem that is a blast from the past...
Yes, DROPBUF 0 would be even better, a MAKEBUF is not required in such a server I'd say: you'd use it to separate what you place in the stack from what is there already, but as you code DROPBUF 0, there is surely nothing anymore to separate your stuff from. 2009/9/15 Schuh, Richard > Do you want "DROPBUF" or "DROPBUF 0"? Without a number, only the last > buffer created is dropped; 0 implies all buffers, not just the last. A > sequence of > > 'DROPBUF 0' > MAKEBUF' > 'WAKEUP ...' > > might be preferable if you are unsure of what called routines might have > done. > > > Regards, > Richard Schuh > > > > > -- > *From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *On > Behalf Of *Kris Buelens > *Sent:* Monday, September 14, 2009 11:40 PM > *To:* IBMVM@LISTSERV.UARK.EDU > *Subject:* Re: Problem that is a blast from the past... > > When one uses DESBUF, it should be preceeded by CONWAIT as DESBUF also > clears CMS' console output buffer. > In my young years, I was debugging an EXEC1 exec with an &TRACE ALL, and I > didn't see all executed lines. I was almost convinced that I found a bug in > EXEC1 as in the console trace I saw it jump from exec line xxx to yyy > without an &GOTO to explain the jump... But, you guessed it: at line yyy-1 > there was a DESBUF... > In my experience, DESBUF is no longer of any use since the arrival of > DROPBUF, and that was together with EXEC2, maybe in VM/SP Rel 2. > So, in a bigger WAKEUP based server, where one isn't sure some other called > exec leaves stacked lines behind, it might be better to code > 'DROPBUF' > 'WAKEUP .' with or without CONS, it wouldn't matter anymore. > > 2009/9/14 Colleen Brown > >> >> I really think Kris's first response about the CONS option is the correct >> one. You don't want to use this option unless you have some specific need. >> WAKEUP will wake and give a rc 6 when you hit enter on the console without >> this option. I have done traces before and 'watched' the rc 6 occur because >> of something being put temporarily on the stack by CMS. In those cases >> WAKEUP is too efficient and catches what you don't want caught. >> Another quirky thing with WAKEUP is using DESBUF without CONWAIT. DROPBUF >> works much better with WAKEUP and isn't as finicky about whether or not >> CONWAIT is used. >> (It has been too long since I chased some of these things. Memory fades >> ...) >> >> Colleen M Brown >> IBM z/VM and Related Products Development and Service >> >> >> *Kris Buelens * >> Sent by: The IBM z/VM Operating System >> >> 09/14/2009 04:03 PM >> Please respond to >> The IBM z/VM Operating System >> >>To >> IBMVM@LISTSERV.UARK.EDU cc >> Subject >> Re: Problem that is a blast from the past... >> >> >> >> >> As far as I know: CP FOR can only be used to execute CP commands on behalf >> of the target user, it does not generate console interrupts as opposed to CP >> SEND. >> >> 2009/9/14 Mike Walter <*mike.wal...@hewitt.com* > >> 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. >> >> >> >> >> >> -- >> Kris Buelens, >> IBM Belgium, VM customer support >> > > > > -- > Kris Buelens, > IBM Belgium, VM customer support > > -- Kris Buelens, IBM Belgium, VM customer support
Re: Problem that is a blast from the past...
You all have great memories! I didn't mean to imply a current problem with DESBUF versus DROPBUF. I was just recalling other 'quirkiness' when using WAKEUP. This DESBUF versus DROPBUF thing is not isolated to just execs using WAKEUP. However, because of WAKEUP's fielding of interrupts you can see results you didn't expect. And yes, it is better to specify a number with DROPBUF with 0 meaning all the program stack buffers. Colleen M Brown IBM z/VM and Related Products Development and Service "Schuh, Richard" Sent by: The IBM z/VM Operating System 09/15/2009 11:36 AM Please respond to The IBM z/VM Operating System To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Problem that is a blast from the past... Do you want "DROPBUF" or "DROPBUF 0"? Without a number, only the last buffer created is dropped; 0 implies all buffers, not just the last. A sequence of 'DROPBUF 0' MAKEBUF' 'WAKEUP ...' might be preferable if you are unsure of what called routines might have done. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Kris Buelens Sent: Monday, September 14, 2009 11:40 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problem that is a blast from the past... When one uses DESBUF, it should be preceeded by CONWAIT as DESBUF also clears CMS' console output buffer. In my young years, I was debugging an EXEC1 exec with an &TRACE ALL, and I didn't see all executed lines. I was almost convinced that I found a bug in EXEC1 as in the console trace I saw it jump from exec line xxx to yyy without an &GOTO to explain the jump... But, you guessed it: at line yyy-1 there was a DESBUF... In my experience, DESBUF is no longer of any use since the arrival of DROPBUF, and that was together with EXEC2, maybe in VM/SP Rel 2. So, in a bigger WAKEUP based server, where one isn't sure some other called exec leaves stacked lines behind, it might be better to code 'DROPBUF' 'WAKEUP .' with or without CONS, it wouldn't matter anymore. 2009/9/14 Colleen Brown I really think Kris's first response about the CONS option is the correct one. You don't want to use this option unless you have some specific need. WAKEUP will wake and give a rc 6 when you hit enter on the console without this option. I have done traces before and 'watched' the rc 6 occur because of something being put temporarily on the stack by CMS. In those cases WAKEUP is too efficient and catches what you don't want caught. Another quirky thing with WAKEUP is using DESBUF without CONWAIT. DROPBUF works much better with WAKEUP and isn't as finicky about whether or not CONWAIT is used. (It has been too long since I chased some of these things. Memory fades ...) Colleen M Brown IBM z/VM and Related Products Development and Service Kris Buelens Sent by: The IBM z/VM Operating System 09/14/2009 04:03 PM Please respond to The IBM z/VM Operating System To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Problem that is a blast from the past... As far as I know: CP FOR can only be used to execute CP commands on behalf of the target user, it does not generate console interrupts as opposed to CP SEND. 2009/9/14 Mike Walter 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. -- Kris Buelens, IBM Belgium, VM customer support -- Kris Buelens, IBM Belgium, VM customer support
Re: Problem that is a blast from the past...
Do you want "DROPBUF" or "DROPBUF 0"? Without a number, only the last buffer created is dropped; 0 implies all buffers, not just the last. A sequence of 'DROPBUF 0' MAKEBUF' 'WAKEUP ...' might be preferable if you are unsure of what called routines might have done. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Kris Buelens Sent: Monday, September 14, 2009 11:40 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problem that is a blast from the past... When one uses DESBUF, it should be preceeded by CONWAIT as DESBUF also clears CMS' console output buffer. In my young years, I was debugging an EXEC1 exec with an &TRACE ALL, and I didn't see all executed lines. I was almost convinced that I found a bug in EXEC1 as in the console trace I saw it jump from exec line xxx to yyy without an &GOTO to explain the jump... But, you guessed it: at line yyy-1 there was a DESBUF... In my experience, DESBUF is no longer of any use since the arrival of DROPBUF, and that was together with EXEC2, maybe in VM/SP Rel 2. So, in a bigger WAKEUP based server, where one isn't sure some other called exec leaves stacked lines behind, it might be better to code 'DROPBUF' 'WAKEUP .' with or without CONS, it wouldn't matter anymore. 2009/9/14 Colleen Brown mailto:brown...@us.ibm.com>> I really think Kris's first response about the CONS option is the correct one. You don't want to use this option unless you have some specific need. WAKEUP will wake and give a rc 6 when you hit enter on the console without this option. I have done traces before and 'watched' the rc 6 occur because of something being put temporarily on the stack by CMS. In those cases WAKEUP is too efficient and catches what you don't want caught. Another quirky thing with WAKEUP is using DESBUF without CONWAIT. DROPBUF works much better with WAKEUP and isn't as finicky about whether or not CONWAIT is used. (It has been too long since I chased some of these things. Memory fades ...) Colleen M Brown IBM z/VM and Related Products Development and Service Kris Buelens mailto:kris.buel...@gmail.com>> Sent by: The IBM z/VM Operating System mailto:IBMVM@LISTSERV.UARK.EDU>> 09/14/2009 04:03 PM Please respond to The IBM z/VM Operating System mailto:IBMVM@LISTSERV.UARK.EDU>> To IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU> cc Subject Re: Problem that is a blast from the past... As far as I know: CP FOR can only be used to execute CP commands on behalf of the target user, it does not generate console interrupts as opposed to CP SEND. 2009/9/14 Mike Walter mailto:mike.wal...@hewitt.com>> 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. -- Kris Buelens, IBM Belgium, VM customer support -- Kris Buelens, IBM Belgium, VM customer support
Re: Problem that is a blast from the past...
When one uses DESBUF, it should be preceeded by CONWAIT as DESBUF also clears CMS' console output buffer. In my young years, I was debugging an EXEC1 exec with an &TRACE ALL, and I didn't see all executed lines. I was almost convinced that I found a bug in EXEC1 as in the console trace I saw it jump from exec line xxx to yyy without an &GOTO to explain the jump... But, you guessed it: at line yyy-1 there was a DESBUF... In my experience, DESBUF is no longer of any use since the arrival of DROPBUF, and that was together with EXEC2, maybe in VM/SP Rel 2. So, in a bigger WAKEUP based server, where one isn't sure some other called exec leaves stacked lines behind, it might be better to code 'DROPBUF' 'WAKEUP .' with or without CONS, it wouldn't matter anymore. 2009/9/14 Colleen Brown > > I really think Kris's first response about the CONS option is the correct > one. You don't want to use this option unless you have some specific need. > WAKEUP will wake and give a rc 6 when you hit enter on the console without > this option. I have done traces before and 'watched' the rc 6 occur because > of something being put temporarily on the stack by CMS. In those cases > WAKEUP is too efficient and catches what you don't want caught. > Another quirky thing with WAKEUP is using DESBUF without CONWAIT. DROPBUF > works much better with WAKEUP and isn't as finicky about whether or not > CONWAIT is used. > (It has been too long since I chased some of these things. Memory fades > ...) > > Colleen M Brown > IBM z/VM and Related Products Development and Service > > > *Kris Buelens * > Sent by: The IBM z/VM Operating System > > 09/14/2009 04:03 PM > Please respond to > The IBM z/VM Operating System > > To > IBMVM@LISTSERV.UARK.EDU cc > Subject > Re: Problem that is a blast from the past... > > > > > As far as I know: CP FOR can only be used to execute CP commands on behalf > of the target user, it does not generate console interrupts as opposed to CP > SEND. > > 2009/9/14 Mike Walter <*mike.wal...@hewitt.com* > > 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. > > > > > > -- > Kris Buelens, > IBM Belgium, VM customer support > -- Kris Buelens, IBM Belgium, VM customer support
Re: Problem that is a blast from the past...
I really think Kris's first response about the CONS option is the correct one. You don't want to use this option unless you have some specific need. WAKEUP will wake and give a rc 6 when you hit enter on the console without this option. I have done traces before and 'watched' the rc 6 occur because of something being put temporarily on the stack by CMS. In those cases WAKEUP is too efficient and catches what you don't want caught. Another quirky thing with WAKEUP is using DESBUF without CONWAIT. DROPBUF works much better with WAKEUP and isn't as finicky about whether or not CONWAIT is used. (It has been too long since I chased some of these things. Memory fades ...) Colleen M Brown IBM z/VM and Related Products Development and Service Kris Buelens Sent by: The IBM z/VM Operating System 09/14/2009 04:03 PM Please respond to The IBM z/VM Operating System To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Problem that is a blast from the past... As far as I know: CP FOR can only be used to execute CP commands on behalf of the target user, it does not generate console interrupts as opposed to CP SEND. 2009/9/14 Mike Walter 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. -- Kris Buelens, IBM Belgium, VM customer support
Re: Problem that is a blast from the past...
As far as I know: CP FOR can only be used to execute CP commands on behalf of the target user, it does not generate console interrupts as opposed to CP SEND. 2009/9/14 Mike Walter > 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. > > > -- Kris Buelens, IBM Belgium, VM customer support
Re: Problem that is a blast from the past...
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" Sent by: "The IBM z/VM Operating System" 09/14/2009 09:08 AM Please respond to "The IBM z/VM Operating System" 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 > >> 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" >> To: >> 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 sai
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 > >> 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" >> To: >> 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 >>>> 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 >
Re: Problem that is a blast from the past...
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 > 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" > To: > 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 >>> 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
Re: Problem that is a blast from the past...
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/ My Navy memoirs http://www.the-fishers.com/cal/Navy - Original Message - From: "Martha McConaghy" To: 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 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
Re: Problem that is a blast from the past...
Isn't that the interrupt you would expect to see from the +5 interval? Normally, that would cause a return code of 2. Could this be a case of nearly simultaneous occurring events, with RC=6 taking precedence over RC=2? Admittedly, I am spoiled by KWAKEUP's much friendlier interface, so I have no recent experience with WAKEUP. I last wrestled with it over 20 years ago. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark > Sent: Wednesday, September 09, 2009 2:51 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Problem that is a blast from the past... > > On Wednesday, 09/09/2009 at 05:26 EDT, Martha McConaghy > 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 >
Re: Problem that is a blast from the past...
Sorry, sending that to the list was an error on my part. Please ignore it! David Wakser -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Mike Walter Sent: Wednesday, September 09, 2009 6:17 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problem that is a blast from the past... > VMUTIL DMSEXT072E Error in EXEC file IDLEUESR, line 0 - not found Hmmm. Could it be as simple as a typo for your problem? "line 0 - not found" usually means that the exec can't be found. "IDLEUESR" is an unusual spelling for what would seem to be "IDLEUSER". Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. "Wakser, David" Sent by: "The IBM z/VM Operating System" 09/09/2009 04:42 PM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Problem that is a blast from the past... Here is a screen copy of all the times it has happened recently. I was looking for a pattern. It's always the same time. CONSERVE Console DisplayIFOX z/VM 5.3 (ZVMESA5) VMUTIL DMSEXT072E Error in EXEC file IDLEUESR, line 0 - not found 7:00:00 --- * End of 08/11/09 * Start of 08/18/09 * --- VMUTIL DMSEXT072E Error in EXEC file IDLEUESR, line 0 - not found 7:00:01 --- * End of 08/18/09 * Start of 08/25/09 * --- VMUTIL DMSEXT072E Error in EXEC file IDLEUESR, line 0 - not found 7:00:00 --- * End of 08/25/09 * Start of 09/01/09 * --- VMUTIL DMSEXT072E Error in EXEC file IDLEUESR, line 0 - not found 7:00:00 --- * End of 09/01/09 * Start of 09/08/09 * --- VMUTIL DMSEXT072E Error in EXEC file IDLEUESR, line 0 - not found 7:00:01 >>Overlap<< 08/11/09 Redisplay ===> PF1=Help PF2=TrackPF3=Quit PF6=?PF7=Bwd PF8=Fwd -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Wandschneider, Scott Sent: Wednesday, September 09, 2009 5:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problem that is a blast from the past... Where is HOBBIT TIMES located? If the file changes should that disk be re-accessed ? Thank you, Scott -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Martha McConaghy Sent: Wednesday, September 09, 2009 4:13 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Problem that is a blast from the past... Well, I got to pull out my old System/370 reference "green card" (really a yellow book) for the first time in quite a while. That was quite nostalgic. The reason for using it isn't quite as much fun, though. I'm trying to get the Xymon client for VM working, which uses WAKEUP. I haven't used that in a number of years and am running into a weird problem. It will work for hours without a problem and then just drop out of WAKEUP due to an "external interrupt". WAKEUP is being called as follows: 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. Any ideas on how I can get it to stop doing that? Martha Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or "Protected Health Information," within the meaning of the regulations under the Health Insurance Portability & Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, inc
Re: Problem that is a blast from the past...
> VMUTIL DMSEXT072E Error in EXEC file IDLEUESR, line 0 - not found Hmmm. Could it be as simple as a typo for your problem? "line 0 - not found" usually means that the exec can't be found. "IDLEUESR" is an unusual spelling for what would seem to be "IDLEUSER". Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. "Wakser, David" Sent by: "The IBM z/VM Operating System" 09/09/2009 04:42 PM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Problem that is a blast from the past... Here is a screen copy of all the times it has happened recently. I was looking for a pattern. It's always the same time. CONSERVE Console DisplayIFOX z/VM 5.3 (ZVMESA5) VMUTIL DMSEXT072E Error in EXEC file IDLEUESR, line 0 - not found 7:00:00 --- * End of 08/11/09 * Start of 08/18/09 * --- VMUTIL DMSEXT072E Error in EXEC file IDLEUESR, line 0 - not found 7:00:01 --- * End of 08/18/09 * Start of 08/25/09 * --- VMUTIL DMSEXT072E Error in EXEC file IDLEUESR, line 0 - not found 7:00:00 --- * End of 08/25/09 * Start of 09/01/09 * --- VMUTIL DMSEXT072E Error in EXEC file IDLEUESR, line 0 - not found 7:00:00 --- * End of 09/01/09 * Start of 09/08/09 * --- VMUTIL DMSEXT072E Error in EXEC file IDLEUESR, line 0 - not found 7:00:01 >>Overlap<< 08/11/09 Redisplay ===> PF1=Help PF2=TrackPF3=Quit PF6=?PF7=Bwd PF8=Fwd -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Wandschneider, Scott Sent: Wednesday, September 09, 2009 5:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problem that is a blast from the past... Where is HOBBIT TIMES located? If the file changes should that disk be re-accessed ? Thank you, Scott -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Martha McConaghy Sent: Wednesday, September 09, 2009 4:13 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Problem that is a blast from the past... Well, I got to pull out my old System/370 reference "green card" (really a yellow book) for the first time in quite a while. That was quite nostalgic. The reason for using it isn't quite as much fun, though. I'm trying to get the Xymon client for VM working, which uses WAKEUP. I haven't used that in a number of years and am running into a weird problem. It will work for hours without a problem and then just drop out of WAKEUP due to an "external interrupt". WAKEUP is being called as follows: 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. Any ideas on how I can get it to stop doing that? Martha Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or "Protected Health Information," within the meaning of the regulations under the Health Insurance Portability & Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you. Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or "Protected
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 > 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
Re: Problem that is a blast from the past...
On Wednesday, 09/09/2009 at 05:26 EDT, Martha McConaghy 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
Re: Problem that is a blast from the past...
Its definitely not a disk access issue. Its running on its own private 191 disk on each of the systems. I had originally thought it was a problem with the filemode, but I changed it to A6 and the problem still occurs. I'm not sure if the external interrupt is a "red herring" though. Wakeup is stopping with RC=6 which indicates a console interrupt, not an external one. Its really weird problem. Martha
Re: Problem that is a blast from the past...
Here is a screen copy of all the times it has happened recently. I was looking for a pattern. It's always the same time. CONSERVE Console DisplayIFOX z/VM 5.3 (ZVMESA5) VMUTIL DMSEXT072E Error in EXEC file IDLEUESR, line 0 - not found 7:00:00 --- * End of 08/11/09 * Start of 08/18/09 * --- VMUTIL DMSEXT072E Error in EXEC file IDLEUESR, line 0 - not found 7:00:01 --- * End of 08/18/09 * Start of 08/25/09 * --- VMUTIL DMSEXT072E Error in EXEC file IDLEUESR, line 0 - not found 7:00:00 --- * End of 08/25/09 * Start of 09/01/09 * --- VMUTIL DMSEXT072E Error in EXEC file IDLEUESR, line 0 - not found 7:00:00 --- * End of 09/01/09 * Start of 09/08/09 * --- VMUTIL DMSEXT072E Error in EXEC file IDLEUESR, line 0 - not found 7:00:01 >>Overlap<< 08/11/09 Redisplay ===> PF1=Help PF2=TrackPF3=Quit PF6=?PF7=Bwd PF8=Fwd -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Wandschneider, Scott Sent: Wednesday, September 09, 2009 5:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Problem that is a blast from the past... Where is HOBBIT TIMES located? If the file changes should that disk be re-accessed ? Thank you, Scott -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Martha McConaghy Sent: Wednesday, September 09, 2009 4:13 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Problem that is a blast from the past... Well, I got to pull out my old System/370 reference "green card" (really a yellow book) for the first time in quite a while. That was quite nostalgic. The reason for using it isn't quite as much fun, though. I'm trying to get the Xymon client for VM working, which uses WAKEUP. I haven't used that in a number of years and am running into a weird problem. It will work for hours without a problem and then just drop out of WAKEUP due to an "external interrupt". WAKEUP is being called as follows: 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. Any ideas on how I can get it to stop doing that? Martha Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or "Protected Health Information," within the meaning of the regulations under the Health Insurance Portability & Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you. Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or "Protected Health Information," within the meaning of the regulations under the Health Insurance Portability & Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: Problem that is a blast from the past...
Where is HOBBIT TIMES located? If the file changes should that disk be re-accessed ? Thank you, Scott -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Martha McConaghy Sent: Wednesday, September 09, 2009 4:13 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Problem that is a blast from the past... Well, I got to pull out my old System/370 reference "green card" (really a yellow book) for the first time in quite a while. That was quite nostalgic. The reason for using it isn't quite as much fun, though. I'm trying to get the Xymon client for VM working, which uses WAKEUP. I haven't used that in a number of years and am running into a weird problem. It will work for hours without a problem and then just drop out of WAKEUP due to an "external interrupt". WAKEUP is being called as follows: 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. Any ideas on how I can get it to stop doing that? Martha Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or "Protected Health Information," within the meaning of the regulations under the Health Insurance Portability & Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: Problem that is a blast from the past...
On Sep 9, 2009, at 4:13 PM, Martha McConaghy wrote: Well, I got to pull out my old System/370 reference "green card" (really a yellow book) for the first time in quite a while. That was quite nostalgic. The reason for using it isn't quite as much fun, though. I'm trying to get the Xymon client for VM working, which uses WAKEUP. I haven't used that in a number of years and am running into a weird problem. It will work for hours without a problem and then just drop out of WAKEUP due to an "external interrupt". WAKEUP is being called as follows: 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. Any ideas on how I can get it to stop doing that? Well, if you know the line that's failing Why can't you also catch the external interrupt code 1004 and then put WAKEUP back to sleep? Adam
