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: ---<snip>--- 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. ---<snip>--- 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 <framaek...@ailife.com> 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.0 2011-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(00001); 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 error, please destroy it immediately and notify us at privacy...@ailife.com. _____________________________________________________ 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 error, please destroy it immediately and notify us at privacy...@ailife.com.