Re: Trapping SMSG messages
The "heartbeat problem" has been around, and solved, for years. I remember it even being written up in one of the IBM Journals by someone at Yorktown *lots* of years ago. These days you simply go to your friendly VM Download Library and pick one of the Disconnected Service Machine packages, like VMSERVE (now owned by Bruce Hayden, since I've retired), or the more modern PIPESERVE (sp?) and only worry about the application side of the problem. As a bonus, you get a general purpose DSM that you can use to automate (or test) any number of mundane tasks, like checking that all the other dsm's had closed their console spool file (via the TIMES file) on the hour, by it's arrival in the rdr. In a network of cpu's, that even helps watch that RSCS is working. I do realize, from following this list, that there is now a lot of automation commercially available, but sometimes a quick 'out of your back pocket' solution is reassuring to management and can be used as a Proof Of Concept that leads to a Requirement. Not to mention that telling your manager "I can solve that problem before lunch and don't need a maintenance window to do it." doesn't hurt your reputation! Les Frank M. Ramaekers wrote: Well, I did try using just the WAKEUP RESET (which changes the SMSG to ON from SMSG IUCV), but I still missed the first IUCV MSG. Frank M. Ramaekers Jr. From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Scott Rohling Sent: Thursday, August 04, 2011 12:45 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Trapping SMSG messages You might try 'WAKEUP RESET' just before you do the 'WAKEUP +0 (IUCVMSG' (You didn't say, but assuming you tried this and it worked?). You should also end your routine with WAKEUP RESET (just before you restore msg values - RESET does a SET MSG ON, which may not be what it was). It's not clear in the doc - but I 'think' doing a RESET clears IUCV.. Scott Rohling On Thu, Aug 4, 2011 at 11:37 AM, Frank M. Ramaekers wrote: Good points. I've had the problem with MSG/SMSGs still in limbo and the WAKEUP receives those first. Is there a way to clear these prior to issuing the WAKEUP (or sending the SMSG)? Frank M. Ramaekers Jr. From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Scott Rohling Sent: Thursday, August 04, 2011 10:55 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Trapping SMSG messages Another couple of points -- - Since you can't control who might send a message to you when - you probably want to loop until there are no more rc=5.It could be a msg from another user is stacked in IUCV. - DESBUF is kind of brute force -- it wipes out the stack -- and there could conceivably be things stacked and needed by whatever calls you. Better to do a 'MAKEBUF';buf=rc ... and then 'DROPBUF' buf ... then you only drop the things in your 'own' stack.. and you aren't affected by what may already be in the stack for whatever called you. Scott Rohling On Thu, Aug 4, 2011 at 9:44 AM, Scott Rohling wrote: Try turning the 'SET MSG IUCV' to 'WAKEUP +0 (IUCVMSG' .. I think this gets WAKEUP ready - and also issues the SET MSG IUCV. The example under 'HELP WAKEUP' shows it done this way and I seem to recall needing to do it in something I'd written. Scott Rohling On Thu, Aug 4, 2011 at 9:28 AM, Frank M. Ramaekers wrote: I don't quite understand why I'm missing the first IUCV MSG sent to my virtual machine after an IPL. The basics of this program is: 1) Send a SMSG to VMUTIL of 'RUOKAY' 2) VMUTIL, if alive, will send back a MSG response "IMOKAY" 3) If the proper response is received the RC is set to zero, all other cases it's set to 1 My short REXX: Trace "O" "PIPE LITERAL QUERY SET", "| CP", "| SPLIT AT ,", "| STRIP", "| FIND MSG"||, "| SPEC W2 1", "| VAR SETMSG" "CP SET MSG IUCV" "CP SMSG VMUTIL RUALIVE" "WAKEUP +00:02 (QUIET IUCVMS
Re: Trapping SMSG messages
Since you showed yours, here's mine. Admittedly not as pretty, but then I
don't have a user community.
It also handles being used on a service machine that has a secuser.
It reduces Frank's original exec to:
/* */
Address Command
'PIPE Rexx SMSGRPY VMUTIL RUALIVE|Locate /IMOKAY/|Count lines|Aggrc'
Exit ^rc
Isn't this fun???
/*
** SMSG's an arbitrary target SVM, captures responses and inserts
** into the pipeline.
*/
Parse Upper arg tgtmach what '(' opts ')' ignored
Call InitRtn
'CallPipe (Name GetSMsgResp End ?)',
'Literal' timeout_value,
'|Delay',
'|stopper:Faninany',
'|xx:Gate',
'?',
'Starmsg *MSG CP SMSG' tgtmach what ||,
'|xx:',
'|ours:Find 0001' || Left(tgtmach,8,'_') ||,
'|dec:Fanout',
'|Take 1',
'|Spec /' || msg_wait || '/ 1',
'|Elastic',
'|Delay',
'|stopper:',
'?dec:',
'|Spec 17-* n',
'|*:',
'?ours:',
'|obnd:Pick 17.10 == /HCPMSG045E/',
'|Elastic',
'|stopper:',
'?obnd:',
'|Spec /From/ 1 9.8 strip nw /:/ n 17-* nw',
'|Cons'
Call CleanUp
Exit xRc
InitRtn:
timeout_value = '+20';msg_wait='+1'
what = Strip(what)
Parse value Diag(8,'Q SET') with . 'MSG' wasmsg ',' . 'CPCONIO' wascpcio
',' .
iRc = 0
popts=''
Do while opts <> ''
Parse var opts opt opts
Select
When Abbrev('TIMEOUT',opt,1) |,
Abbrev('DELAY',opt,3) then Do
Parse var opts timeout_value opts
If Pos('.',timeout_value)=1 then
timeout_value='0'timeout_value
timeout_value = '+' || timeout_value
End
When Abbrev('WAITCONT',opt,1) |,
Abbrev('WAITON',opt,1) then Do
Parse var opts msg_wait opts
If pos('.',msg_wait)=1 then msg_wait='0'msg_wait
msg_wait = '+' || msg_wait
End
Otherwise popts = Strip(popts opt)
End /* select */
End
If popts<>'' then what = what'('popts')'
If iRc <> 0 then Exit iRc
/*>---<*>---<*>---<*>---<*>---<*>---<*/
/* Ensure secuser isn't directing msgs elsewhere */
/*>---<*>---<*>---<*>---<*>---<*>---<*/
dscd = Word(Diag(8,'Q CONS'),3) == 'DISCONNECTED'
If dscd then Do
Parse value DiagRc(8,'Q PRIV') with . '15'x . ':' myprivs . '15'x
If Verify(myprivs,'AC','M')>0 then do_me = '*'
Else do_me = ''
Parse value DiagRc(8,'Q SECUSER *'),
with . '15'x . '15'x suinfo '15'x
Parse var suinfo . whoisit .
If whoisit<>'not'
then Parse value DiagRc(8,'SET SECUSER' do_me 'OFF') with .
Else whoisit = ''
End
'Commit 0' /* hot to trot */
x=Diag(8,'SET MSG IUCV' || '15'x || 'SET CPCONIO IUCV')
Return
CleanUp:
xRc = Rc
x = Diag(8,'SET MSG' wasmsg || '15'x || 'SET CPCONIO' wascpcio)
If dscd then if whoisit<>''
then Parse value Diag(8,'SET SECUSER' do_me whoisit) with .
Return
--
Mike Harding
z/VM System Support
mhard...@us.ibm.com
mike.b.hard...@kp.org
mikehard...@mindless.com
(925) 926-3179 (w)
(925) 323-2070 (c)
IM: VMBearDad (AIM), mbhcpcvt (Y!)
The IBM z/VM Operating System wrote on 08/04/2011
10:48:04 AM:
> From: Mike Walter
> To: IBMVM@LISTSERV.UARK.EDU
> Date: 08/04/2011 11:07 AM
> Subject: Re: Trapping SMSG messages
> Sent by: The IBM z/VM Operating System
>
> Frank,
>
> See below for an old, generalized, EXEC that I’ve been using and re-
> using for years to use WAKEUP reliably. We have it in our tools
> disk, available to all applications programmers as a sample, using
> the WAKEUP operands I use most often. It requires requires anyone
> using it to plug in their processing at the appropriate points.
>
> Mike Walter
> Aon Corporation
> The opinions expressed herein are mine alone, not my employer's.
Re: Trapping SMSG messages
I agree with Mike. Either way, you need to account for the following comma's possibly abutting the MSG setting. My preferred method: Parse value Diag(8,'Q SET') with . 'MSG' msgset ',' . Then there's no chance of an error when you later 'SET MSG' msgset -- Mike Harding z/VM System Support mhard...@us.ibm.com mike.b.hard...@kp.org mikehard...@mindless.com (925) 926-3179 (w) (925) 323-2070 (c) IM: VMBearDad (AIM), mbhcpcvt (Y!) The IBM z/VM Operating System wrote on 08/04/2011 10:44:28 AM: > From: Mike Walter > To: IBMVM@LISTSERV.UARK.EDU > Date: 08/04/2011 10:44 AM > Subject: Re: Trapping SMSG messages > Sent by: The IBM z/VM Operating System > > There's nothing wrong at all with that Pipe. I *love* Pipes, > feeling that a day without Pipes is a day without sunshine. > > But there's a lot more overhead in setting up a Pipe to trap a CP > reply than in using rexx's built-in code as described. > > I am frugal with CPU usage, trying to use the *best* tool for the > job, not just the one that's most familiar. Otherwise we'd all be > using TSO (perish the thought!). ;-) > > See again: > -- > When all you have is Pipes, every problem is a plumbing problem. > But sometimes old-fashioned methods work more cheaply. > In this case, using "parse value diag(08,'some cp command') with ..." > does not require a Pipe to be created. It's just native rexx code. > -- > > Mike Walter > Aon Corporation > The opinions expressed herein are mine alone, not my employer's. > > > > -Original Message- > From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] > On Behalf Of Frank M. Ramaekers > Sent: Thursday, August 04, 2011 12:39 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Trapping SMSG messages > > What's wrong with the PIPE method: > > "PIPE LITERAL QUERY SET", > "| CP", > "| SPLIT AT ,", > "| STRIP", > "| FIND MSG"||, > "| SPEC W2 1", > "| VAR SETMSG" > > > Frank M. Ramaekers Jr. > > > > -Original Message- > From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] > On Behalf Of Mike Walter > Sent: Thursday, August 04, 2011 11:02 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Trapping SMSG messages > > Unrelated to the reported problem, but a simpler/cheaper way to save > the CP MSG setting for later restoration: > > parse value diag(08,'CP QUERY SET') with w1 w2 . > If w1='MSG' then $msg=w2/* Save CP MSG setting before it is changed */ > 'CP SET MSG IUCV' > . perform processing ... > 'CP SET MSG' $msg /* Restore CP MSG setting from before */ > > When all you have is Pipes, every problem is a plumbing problem. > But sometimes old-fashioned methods work more cheaply. > In this case, using "parse value diag(08,'some cp command') with ... > Does not require a Pipe to be created. It's just native rexx code. > > One could have code that parse as: parse value diag(08,'CP QUERY > SET') with . 'MSG ' $msg . > But if IBM *ever* inserted a new argument before the MSG setting > containing the string "MSG ", then the results become muddled. > Granted, IBM would NEVER do such a thing because it would break > untold applications. But it is described as a teaching example > since other messages from unknown sources could make just that type > of unexpected message change. > > Mike Walter > Aon Corporation > The opinions expressed herein are mine alone, not my employer's. > > > > > From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] > On Behalf Of Scott Rohling > Sent: Thursday, August 04, 2011 10:45 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Trapping SMSG messages > > Try turning the 'SET MSG IUCV' to 'WAKEUP +0 (IUCVMSG' .. I think > this gets WAKEUP ready - and also issues the SET MSG IUCV. The > example under 'HELP WAKEUP' shows it done this way and I seem to > recall needing to do it in something I'd written. > > Scott Rohling > On Thu, Aug 4, 2011 at 9:28 AM, Frank M. Ramaekers > wrote: > I don't quite understand why I'm missing the first IUCV MSG sent to > my virtual machine after an IPL. The basics of this program is: > > 1) Send a SMSG to VMUTIL of 'RUOKAY' > 2) VMUTIL, if alive, will send back a MSG response "IMOKAY" > 3) If the proper response is recei
Re: Trapping SMSG messages
You might try 'WAKEUP RESET' just before you do the 'WAKEUP +0 (IUCVMSG' (You didn't say, but assuming you tried this and it worked?). You should also end your routine with WAKEUP RESET (just before you restore msg values - RESET does a SET MSG ON, which may not be what it was). It's not clear in the doc - but I 'think' doing a RESET clears IUCV.. Scott Rohling On Thu, Aug 4, 2011 at 11:37 AM, Frank M. Ramaekers wrote: > ** ** ** ** ** ** > > Good points. I’ve had the problem with MSG/SMSGs still in limbo and the > WAKEUP receives those first. Is there a way to clear these prior to issuing > the WAKEUP (or sending the SMSG)? > > ** ** > > > > Frank M. Ramaekers Jr. > > ** ** > > ** ** > -- > > *From:* The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] *On > Behalf Of *Scott Rohling > *Sent:* Thursday, August 04, 2011 10:55 AM > > *To:* IBMVM@LISTSERV.UARK.EDU > *Subject:* Re: Trapping SMSG messages > > > ** ** > > Another couple of points -- > > ** ** > > - Since you can't control who might send a message to you when - you > probably want to loop until there are no more rc=5.It could be a msg > from another user is stacked in IUCV. > > - DESBUF is kind of brute force -- it wipes out the stack -- and there > could conceivably be things stacked and needed by whatever calls you. > Better to do a 'MAKEBUF';buf=rc ... and then 'DROPBUF' buf ... then > you only drop the things in your 'own' stack.. and you aren't affected by > what may already be in the stack for whatever called you. > > ** ** > > Scott Rohling > > On Thu, Aug 4, 2011 at 9:44 AM, Scott Rohling > wrote: > > Try turning the 'SET MSG IUCV' to 'WAKEUP +0 (IUCVMSG' .. I think this > gets WAKEUP ready - and also issues the SET MSG IUCV. The example under > 'HELP WAKEUP' shows it done this way and I seem to recall needing to do it > in something I'd written. > > ** ** > > Scott Rohling > > ** ** > > On Thu, Aug 4, 2011 at 9:28 AM, Frank M. Ramaekers > wrote: > > I don’t quite understand why I’m missing the first IUCV MSG sent to my > virtual machine after an IPL. The basics of this program is: > > > > 1) Send a SMSG to VMUTIL of ‘RUOKAY’ > > 2) VMUTIL, if alive, will send back a MSG response > “IMOKAY” > > 3) If the proper response is received the RC is set to > zero, all other cases it’s set to 1 > > > > My short REXX: > > > > Trace "O" > > "PIPE LITERAL QUERY SET", > > "| CP", > > "| SPLIT AT ,", > > "| STRIP", > > "| FIND MSG"||, > > "| SPEC W2 1", > > "| VAR SETMSG" > > "CP SET MSG IUCV" > > "CP SMSG VMUTIL RUALIVE" > > "WAKEUP +00:02 (QUIET IUCVMSG CONS" > > wurc=rc > > XRC=1 /* Assume bad */ > > Select > > When wurc==5 then /* Message arrived */ > > Do queued() > > Parse pull WuType WuWho WuMsg > > If WuType=="*MSG" & WuWho=="VMUTIL" & WuMsg="IMOKAY" then > > XRC=0 > > End > > When wurc==6 then /* Console interrupt */ > > Say "Interrupted" > > Otherwise > > Nop > > End /* Select */ > > "CP SET MSG" SetMsg > > /* Flush everything */ > &g
Re: Trapping SMSG messages
There's nothing wrong at all with that Pipe. I *love* Pipes, feeling that a day without Pipes is a day without sunshine. But there's a lot more overhead in setting up a Pipe to trap a CP reply than in using rexx's built-in code as described. I am frugal with CPU usage, trying to use the *best* tool for the job, not just the one that's most familiar. Otherwise we'd all be using TSO (perish the thought!). ;-) See again: -- When all you have is Pipes, every problem is a plumbing problem. But sometimes old-fashioned methods work more cheaply. In this case, using "parse value diag(08,'some cp command') with ..." does not require a Pipe to be created. It's just native rexx code. -- Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's. -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Frank M. Ramaekers Sent: Thursday, August 04, 2011 12:39 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Trapping SMSG messages What's wrong with the PIPE method: "PIPE LITERAL QUERY SET", "| CP", "| SPLIT AT ,", "| STRIP", "| FIND MSG"||, "| SPEC W2 1", "| VAR SETMSG" Frank M. Ramaekers Jr. -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Mike Walter Sent: Thursday, August 04, 2011 11:02 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Trapping SMSG messages Unrelated to the reported problem, but a simpler/cheaper way to save the CP MSG setting for later restoration: parse value diag(08,'CP QUERY SET') with w1 w2 . If w1='MSG' then $msg=w2/* Save CP MSG setting before it is changed */ 'CP SET MSG IUCV' . perform processing ... 'CP SET MSG' $msg /* Restore CP MSG setting from before */ When all you have is Pipes, every problem is a plumbing problem. But sometimes old-fashioned methods work more cheaply. In this case, using "parse value diag(08,'some cp command') with ... Does not require a Pipe to be created. It's just native rexx code. One could have code that parse as: parse value diag(08,'CP QUERY SET') with . 'MSG ' $msg . But if IBM *ever* inserted a new argument before the MSG setting containing the string "MSG ", then the results become muddled. Granted, IBM would NEVER do such a thing because it would break untold applications. But it is described as a teaching example since other messages from unknown sources could make just that type of unexpected message change. Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's. From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Scott Rohling Sent: Thursday, August 04, 2011 10:45 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Trapping SMSG messages Try turning the 'SET MSG IUCV' to 'WAKEUP +0 (IUCVMSG' .. I think this gets WAKEUP ready - and also issues the SET MSG IUCV. The example under 'HELP WAKEUP' shows it done this way and I seem to recall needing to do it in something I'd written. Scott Rohling On Thu, Aug 4, 2011 at 9:28 AM, Frank M. Ramaekers wrote: I don't quite understand why I'm missing the first IUCV MSG sent to my virtual machine after an IPL. The basics of this program is: 1) Send a SMSG to VMUTIL of 'RUOKAY' 2) VMUTIL, if alive, will send back a MSG response "IMOKAY" 3) If the proper response is received the RC is set to zero, all other cases it's set to 1 My short REXX: Trace "O" "PIPE LITERAL QUERY SET", "| CP", "| SPLIT AT ,", "| STRIP", "| FIND MSG"||, "| SPEC W2 1", "| VAR SETMSG" "CP SET MSG IUCV" "CP SMSG VMUTIL RUALIVE" "WAKEUP +00:02 (QUIET IUCVMSG C
Re: Trapping SMSG messages
What's wrong with the PIPE method: "PIPE LITERAL QUERY SET", "| CP", "| SPLIT AT ,", "| STRIP", "| FIND MSG"||, "| SPEC W2 1", "| VAR SETMSG" Frank M. Ramaekers Jr. -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Mike Walter Sent: Thursday, August 04, 2011 11:02 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Trapping SMSG messages Unrelated to the reported problem, but a simpler/cheaper way to save the CP MSG setting for later restoration: parse value diag(08,'CP QUERY SET') with w1 w2 . If w1='MSG' then $msg=w2/* Save CP MSG setting before it is changed */ 'CP SET MSG IUCV' . perform processing ... 'CP SET MSG' $msg /* Restore CP MSG setting from before */ When all you have is Pipes, every problem is a plumbing problem. But sometimes old-fashioned methods work more cheaply. In this case, using "parse value diag(08,'some cp command') with ... Does not require a Pipe to be created. It's just native rexx code. One could have code that parse as: parse value diag(08,'CP QUERY SET') with . 'MSG ' $msg . But if IBM *ever* inserted a new argument before the MSG setting containing the string "MSG ", then the results become muddled. Granted, IBM would NEVER do such a thing because it would break untold applications. But it is described as a teaching example since other messages from unknown sources could make just that type of unexpected message change. Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's. From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Scott Rohling Sent: Thursday, August 04, 2011 10:45 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Trapping SMSG messages Try turning the 'SET MSG IUCV' to 'WAKEUP +0 (IUCVMSG' .. I think this gets WAKEUP ready - and also issues the SET MSG IUCV. The example under 'HELP WAKEUP' shows it done this way and I seem to recall needing to do it in something I'd written. Scott Rohling On Thu, Aug 4, 2011 at 9:28 AM, Frank M. Ramaekers wrote: I don't quite understand why I'm missing the first IUCV MSG sent to my virtual machine after an IPL. The basics of this program is: 1) Send a SMSG to VMUTIL of 'RUOKAY' 2) VMUTIL, if alive, will send back a MSG response "IMOKAY" 3) If the proper response is received the RC is set to zero, all other cases it's set to 1 My short REXX: Trace "O" "PIPE LITERAL QUERY SET", "| CP", "| SPLIT AT ,", "| STRIP", "| FIND MSG"||, "| SPEC W2 1", "| VAR SETMSG" "CP SET MSG IUCV" "CP SMSG VMUTIL RUALIVE" "WAKEUP +00:02 (QUIET IUCVMSG CONS" wurc=rc XRC=1 /* Assume bad */ Select When wurc==5 then /* Message arrived */ Do queued() Parse pull WuType WuWho WuMsg If WuType=="*MSG" & WuWho=="VMUTIL" & WuMsg="IMOKAY" then XRC=0 End When wurc==6 then /* Console interrupt */ Say "Interrupted" Otherwise Nop End /* Select */ "CP SET MSG" SetMsg /* Flush everything */ "DESBUF" If Externals()>0 then Parse external . Exit XRC l maint
Re: Trapping SMSG messages
Good points. I've had the problem with MSG/SMSGs still in limbo and the WAKEUP receives those first. Is there a way to clear these prior to issuing the WAKEUP (or sending the SMSG)? Frank M. Ramaekers Jr. From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Scott Rohling Sent: Thursday, August 04, 2011 10:55 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Trapping SMSG messages Another couple of points -- - Since you can't control who might send a message to you when - you probably want to loop until there are no more rc=5.It could be a msg from another user is stacked in IUCV. - DESBUF is kind of brute force -- it wipes out the stack -- and there could conceivably be things stacked and needed by whatever calls you. Better to do a 'MAKEBUF';buf=rc ... and then 'DROPBUF' buf ... then you only drop the things in your 'own' stack.. and you aren't affected by what may already be in the stack for whatever called you. Scott Rohling On Thu, Aug 4, 2011 at 9:44 AM, Scott Rohling wrote: Try turning the 'SET MSG IUCV' to 'WAKEUP +0 (IUCVMSG' .. I think this gets WAKEUP ready - and also issues the SET MSG IUCV. The example under 'HELP WAKEUP' shows it done this way and I seem to recall needing to do it in something I'd written. Scott Rohling On Thu, Aug 4, 2011 at 9:28 AM, Frank M. Ramaekers wrote: I don't quite understand why I'm missing the first IUCV MSG sent to my virtual machine after an IPL. The basics of this program is: 1) Send a SMSG to VMUTIL of 'RUOKAY' 2) VMUTIL, if alive, will send back a MSG response "IMOKAY" 3) If the proper response is received the RC is set to zero, all other cases it's set to 1 My short REXX: Trace "O" "PIPE LITERAL QUERY SET", "| CP", "| SPLIT AT ,", "| STRIP", "| FIND MSG"||, "| SPEC W2 1", "| VAR SETMSG" "CP SET MSG IUCV" "CP SMSG VMUTIL RUALIVE" "WAKEUP +00:02 (QUIET IUCVMSG CONS" wurc=rc XRC=1 /* Assume bad */ Select When wurc==5 then /* Message arrived */ Do queued() Parse pull WuType WuWho WuMsg If WuType=="*MSG" & WuWho=="VMUTIL" & WuMsg="IMOKAY" then XRC=0 End When wurc==6 then /* Console interrupt */ Say "Interrupted" Otherwise Nop End /* Select */ "CP SET MSG" SetMsg /* Flush everything */ "DESBUF" If Externals()>0 then Parse external . Exit XRC l maint ENTER PASSWORD (IT WILL NOT APPEAR WHEN TYPED): HCPLNM101E DASD 0CF1 forced R/O; R/O by SYSTEM; stable by SYSTEM HCPLNM101E DASD 0CF2 forced R/O; R/O by SYSTEM; stable by SYSTEM z/VM Version 5 Release 4.0, Service Level 1003 (64-bit), built on IBM Virtualization Technology There is no logmsg data FILES: 0066 RDR, 0007 PRT, NO PUN LOGON AT 10:25:22 CDT THURSDAY 08/04/11 z/VM V5.4.02011-03-31 08:13 PIPINX086I CMS/TSO Pipelines, 5654-030/5655-A17 1.0112 (Version.Release/Mod) - Generated 3 Jul 2010 at 11:32:36. Source: Princeton Runtime Distribution Ready; T=0.02/0.02 10:25:24 vmutil 10:25:25 * MSG FROM VMUTIL : IMOKAY Ready(1); T=0.01/0.01 10:25:27 vmutil Ready; T=0.01/0.01 10:25:41 vmutil Ready; T=0.01/0.01 10:25:44 vmutil Ready; T=0.01/0.01 10:25:44 vmutil Ready; T=0.01/0.01 10:25:45 Any way to avoid missing this first MSG? Frank M. Ramaekers Jr. Systems Programmer MCP, MCP+I, MCSE & RHCE American Income Life Insurance Co. Phone: (254)761-6649 1200 Wooded Acres Dr. Fax: (254)741-5777
Re: Trapping SMSG messages
Unrelated to the reported problem, but a simpler/cheaper way to save the CP MSG setting for later restoration: parse value diag(08,'CP QUERY SET') with w1 w2 . If w1='MSG' then $msg=w2/* Save CP MSG setting before it is changed */ 'CP SET MSG IUCV' . perform processing ... 'CP SET MSG' $msg /* Restore CP MSG setting from before */ When all you have is Pipes, every problem is a plumbing problem. But sometimes old-fashioned methods work more cheaply. In this case, using "parse value diag(08,'some cp command') with ... Does not require a Pipe to be created. It's just native rexx code. One could have code that parse as: parse value diag(08,'CP QUERY SET') with . 'MSG ' $msg . But if IBM *ever* inserted a new argument before the MSG setting containing the string "MSG ", then the results become muddled. Granted, IBM would NEVER do such a thing because it would break untold applications. But it is described as a teaching example since other messages from unknown sources could make just that type of unexpected message change. Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's. From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Scott Rohling Sent: Thursday, August 04, 2011 10:45 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Trapping SMSG messages Try turning the 'SET MSG IUCV' to 'WAKEUP +0 (IUCVMSG' .. I think this gets WAKEUP ready - and also issues the SET MSG IUCV. The example under 'HELP WAKEUP' shows it done this way and I seem to recall needing to do it in something I'd written. Scott Rohling On Thu, Aug 4, 2011 at 9:28 AM, Frank M. Ramaekers wrote: I don't quite understand why I'm missing the first IUCV MSG sent to my virtual machine after an IPL. The basics of this program is: 1) Send a SMSG to VMUTIL of 'RUOKAY' 2) VMUTIL, if alive, will send back a MSG response "IMOKAY" 3) If the proper response is received the RC is set to zero, all other cases it's set to 1 My short REXX: Trace "O" "PIPE LITERAL QUERY SET", "| CP", "| SPLIT AT ,", "| STRIP", "| FIND MSG"||, "| SPEC W2 1", "| VAR SETMSG" "CP SET MSG IUCV" "CP SMSG VMUTIL RUALIVE" "WAKEUP +00:02 (QUIET IUCVMSG CONS" wurc=rc XRC=1 /* Assume bad */ Select When wurc==5 then /* Message arrived */ Do queued() Parse pull WuType WuWho WuMsg If WuType=="*MSG" & WuWho=="VMUTIL" & WuMsg="IMOKAY" then XRC=0 End When wurc==6 then /* Console interrupt */ Say "Interrupted" Otherwise Nop End /* Select */ "CP SET MSG" SetMsg /* Flush everything */ "DESBUF" If Externals()>0 then Parse external . Exit XRC l maint ENTER PASSWORD (IT WILL NOT APPEAR WHEN TYPED): HCPLNM101E DASD 0CF1 forced R/O; R/O by SYSTEM; stable by SYSTEM HCPLNM101E DASD 0CF2 forced R/O; R/O by SYSTEM; stable by SYSTEM z/VM Version 5 Release 4.0, Service Level 1003 (64-bit), built on IBM Virtualization Technology There is no logmsg data
Re: Trapping SMSG messages
Another couple of points -- - Since you can't control who might send a message to you when - you probably want to loop until there are no more rc=5.It could be a msg from another user is stacked in IUCV. - DESBUF is kind of brute force -- it wipes out the stack -- and there could conceivably be things stacked and needed by whatever calls you. Better to do a 'MAKEBUF';buf=rc ... and then 'DROPBUF' buf ... then you only drop the things in your 'own' stack.. and you aren't affected by what may already be in the stack for whatever called you. Scott Rohling On Thu, Aug 4, 2011 at 9:44 AM, Scott Rohling wrote: > Try turning the 'SET MSG IUCV' to 'WAKEUP +0 (IUCVMSG' .. I think this > gets WAKEUP ready - and also issues the SET MSG IUCV. The example under > 'HELP WAKEUP' shows it done this way and I seem to recall needing to do it > in something I'd written. > > Scott Rohling > > > On Thu, Aug 4, 2011 at 9:28 AM, Frank M. Ramaekers > wrote: > >> ** ** ** ** ** ** >> >> I don’t quite understand why I’m missing the first IUCV MSG sent to my >> virtual machine after an IPL. The basics of this program is: >> >> ** ** >> >> **1) **Send a SMSG to VMUTIL of ‘RUOKAY’ >> >> **2) **VMUTIL, if alive, will send back a MSG response >> “IMOKAY” >> >> **3) **If the proper response is received the RC is set >> to zero, all other cases it’s set to 1 >> >> ** ** >> >> My short REXX: >> >> ** ** >> >> Trace "O" >> >> "PIPE LITERAL QUERY SET", >> >> "| CP", >> >> "| SPLIT AT ,", >> >> "| STRIP", >> >> "| FIND MSG"||, >> >> "| SPEC W2 1", >> >> "| VAR SETMSG" >> >> "CP SET MSG IUCV" >> >> "CP SMSG VMUTIL RUALIVE" >> >> "WAKEUP +00:02 (QUIET IUCVMSG CONS" >> >> wurc=rc >> >> XRC=1 /* Assume bad */ >> >> Select >> >> When wurc==5 then /* Message arrived */ >> >> Do queued() >> >> Parse pull WuType WuWho WuMsg >> >> If WuType=="*MSG" & WuWho=="VMUTIL" & WuMsg="IMOKAY" then >> >> XRC=0 >> >> End >> >> When wurc==6 then /* Console interrupt */ >> >> Say "Interrupted" >> >> Otherwise >> >> Nop >> >> End /* Select */ >> >> "CP SET MSG" SetMsg >> >> /* Flush everything */ >> >> "DESBUF" >> >> If Externals()>0 then >> >> Parse external . >> >> Exit XRC >> >> l >> maint >> >> >> ENTER PASSWORD (IT WILL NOT APPEAR WHEN >> TYPED):** >> ** >> >> >> >> >> >> HCPLNM101E DASD 0CF1 forced R/O; R/O by SYSTEM; stable by >> SYSTEM >> >> HCPLNM101E DASD 0CF2 forced R/O; R/O by SYSTEM; stable by >> SYSTEM >> >> z/VM Version 5 Release 4.0, Service Level 1003 >> (64-bit), >> >> built on IBM Virtualization >> Technology >> >> >> There is no logmsg >> data >> >> >> FILES: 0066 RDR, 0007 PRT, NO >> PUN >> >> >> LOGON AT 10:25:22 CDT THURSDAY >> 08/04/11 >> >> >> z/VM V5.4.02011-03-31 >> 08:13 >> >> >> >> >> >> >> PIPINX086I CMS/TSO Pipelines, 5654-030/5655-A17 1.0112 >> (Version.Release/Mod) - Generated 3 Jul 2010 at 11:32:36. >> >> Source: **Princeton** Runtime >> Distribution >> >> >> Ready; T=0.02/0.02 >> 10:25:24 >> >> >> vmutil >> >> >> >> 10:25:25 * MSG FROM VMUTIL : >> IMOKAY >> >> >> Ready(1); T=0.01/0.01 10:25:27 >> >> >> vmutil >> >> Ready; T=0.01/0.01 10:25:41 >> >> vmutil >> >> Ready; T=0.01/0.01 10:25:44 >> >> vmutil >> >> Ready; T=0.01/0.01 10:25:44 >> >> vmutil >> >> Ready; T=0.01/0.01 10:25:45 >
Re: Trapping SMSG messages
Try turning the 'SET MSG IUCV' to 'WAKEUP +0 (IUCVMSG' .. I think this gets WAKEUP ready - and also issues the SET MSG IUCV. The example under 'HELP WAKEUP' shows it done this way and I seem to recall needing to do it in something I'd written. Scott Rohling On Thu, Aug 4, 2011 at 9:28 AM, Frank M. Ramaekers wrote: > ** ** ** ** ** ** > > I don’t quite understand why I’m missing the first IUCV MSG sent to my > virtual machine after an IPL. The basics of this program is: > > ** ** > > **1) **Send a SMSG to VMUTIL of ‘RUOKAY’ > > **2) **VMUTIL, if alive, will send back a MSG response > “IMOKAY” > > **3) **If the proper response is received the RC is set > to zero, all other cases it’s set to 1 > > ** ** > > My short REXX: > > ** ** > > Trace "O" > > "PIPE LITERAL QUERY SET", > > "| CP", > > "| SPLIT AT ,", > > "| STRIP", > > "| FIND MSG"||, > > "| SPEC W2 1", > > "| VAR SETMSG" > > "CP SET MSG IUCV" > > "CP SMSG VMUTIL RUALIVE" > > "WAKEUP +00:02 (QUIET IUCVMSG CONS" > > wurc=rc > > XRC=1 /* Assume bad */ > > Select > > When wurc==5 then /* Message arrived */ > > Do queued() > > Parse pull WuType WuWho WuMsg > > If WuType=="*MSG" & WuWho=="VMUTIL" & WuMsg="IMOKAY" then > > XRC=0 > > End > > When wurc==6 then /* Console interrupt */ > > Say "Interrupted" > > Otherwise > > Nop > > End /* Select */ > > "CP SET MSG" SetMsg > > /* Flush everything */ > > "DESBUF" > > If Externals()>0 then > > Parse external . > > Exit XRC > > l > maint > > > ENTER PASSWORD (IT WILL NOT APPEAR WHEN > TYPED):*** > * > > > > > > HCPLNM101E DASD 0CF1 forced R/O; R/O by SYSTEM; stable by > SYSTEM > > HCPLNM101E DASD 0CF2 forced R/O; R/O by SYSTEM; stable by > SYSTEM > > z/VM Version 5 Release 4.0, Service Level 1003 > (64-bit), > > built on IBM Virtualization > Technology > > > There is no logmsg > data > > > FILES: 0066 RDR, 0007 PRT, NO > PUN > > > LOGON AT 10:25:22 CDT THURSDAY > 08/04/11 > > > z/VM V5.4.02011-03-31 > 08:13 > > > > > > > PIPINX086I CMS/TSO Pipelines, 5654-030/5655-A17 1.0112 > (Version.Release/Mod) - Generated 3 Jul 2010 at 11:32:36. > > Source: **Princeton** Runtime > Distribution > > > Ready; T=0.02/0.02 > 10:25:24 > > > vmutil > > > > 10:25:25 * MSG FROM VMUTIL : > IMOKAY > > > Ready(1); T=0.01/0.01 10:25:27 > > > vmutil > > Ready; T=0.01/0.01 10:25:41 > > vmutil > > Ready; T=0.01/0.01 10:25:44 > > vmutil > > Ready; T=0.01/0.01 10:25:44 > > vmutil > > Ready; T=0.01/0.01 10:25:45 > > ** ** > > Any way to avoid missing this first MSG? > > ** ** > > Frank M. Ramaekers Jr. > > ** ** > > ** ** > > Systems Programmer > > MCP, MCP+I, MCSE & RHCE > > ** ** > > American Income Life Insurance Co. > > Phone: (254)761-6649 > > ** ** > > 1200 Wooded Acres Dr. > > Fax: (254)741-5777 > > ** ** > > Waco**, **Texas** **76701 > > ** ** > > ** ** > > ** ** > > ** ** > _ This message > contains information which is privileged and confidential and is solely for > the use of the intended recipient. If you are not the intended recipient, be > aware that any review, disclosure, copying, distribution, or use of the > contents of this message is strictly prohibited. If you have received this > in e
