Yes indeed, something I didn't notice in your code: *MSGALL intercepts all console traffic that is *not* set to IUCV. So, if you issue CPSET MSG IUCV, *MSGALL does not intercept MSG, but it does intercept CP and VM console IO. *MSGALL was created for CMS Fullscreen, it intercepts everything programs like WAKEUP do not want to grab.
-- Kris Buelens, IBM Belgium, VM customer support 2007/10/10, Schuh, Richard <[EMAIL PROTECTED]>: > > I have found a combination that seems to work: > > > > 1. Change the communication back to the client machine from MSG to > SMSG. > > 2. Change the SET MSG IUCV to SET SMSG IUCV in the client. > > 3. Change PIPE starmsg *MSGALL to PIPE starmsg *MSG, also in the > client. > > > > Regards, > Richard Schuh > > > ------------------------------ > > *From:* The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] *On > Behalf Of *Kris Buelens > *Sent:* Wednesday, October 10, 2007 11:09 AM > *To:* [email protected] > *Subject:* Re: FW: Pipelines Starmsg > > > > Now I hate to say that there *must* be a big difference if there is a > secondary machine for the user running the EXEC. > > As you code CP SET MSG IUCV, I guess(?) the server answers with a MSG. > When you then know that a message sent to a disconnected user that has a > secondary user simply bypasses the disconnected user, it is delivered to the > secondary user. With other words: users that want to trap MSG's sent to > them using PIPE STARMSG or WAKEUP (IUCVMSG must *not* have a secondary > user. > > -- > Kris Buelens, > IBM Belgium, VM customer support > > 2007/10/10, Schuh, Richard <[EMAIL PROTECTED]>: > > In my haste at the end of a long day, I left one key piece of information > out – when connected, the EXEC works as expected; it only fails if running > in a disconnected machine. Before you ask, whether there is or is not a > SECUSER for the disconnected machine is irrelevant, both cases fail. > > > > Regards, > Richard Schuh > > > ------------------------------ > > *From:* The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] *On > Behalf Of *Kris Buelens > *Sent:* Tuesday, October 09, 2007 11:56 PM > *To:* [email protected] > *Subject:* Re: Pipelines Starmsg > > > > I don't see a reason directly. But, why don't you use ADDRESS COMMAND in > your exec? > > 2007/10/10, Schuh, Richard <[EMAIL PROTECTED] >: > > I have a very simple exec that has a pipe that, reduced to its simplest > form, looks like thi s: > > /* TEST EXEC > */ > > ipaserver = 'IPSERV' > > say 'IPSERV returned' getip () > > > exit > > > > getip: > > 'CP SET MSG IUCV' > > arg ipaddr . > > > > 'PIPE (end \ name GetIPA)', > > '\ starmsg *msgall cp smsg' ipaserver 'GETIP' ipaddr, > > '| pick substr w1 of 9-* == /'ipaserver'/', > > '| take 1', > > '| spec 17-* 1', > > '| b: beat 15 /-99 Timeout waiting for the IP Address server./', > > '| fi: faninany', > > '| take 1', > > '| var ipresp', > > '| pipestop', > > '\ b:', > > '| copy', > > '| fi:' > > parse var ipresp iprc ipresp > > if iprc ¬= 0 then call exit iprc, ipresp > > return ipresp > > > > exit: > > parse arg myrc, msg > > if msg ¬= '' then say msg > > exit myrc > > > If this EXEC is executed from the command line, the IP Address is returned > as expected. It is also returned if called by another simple exec. If > another exec is inserted into the mix, there is always an error that > consists of the message from IPSERV being displayed on the console and, some > seconds later, a timeout message from the above EXEC. > > The two other EXECs do nothing other than call the next in line. Thus, > TEST1 consists of a 'EXEC TEST' command'; TEST2 consists of a 'EXEC TEST1' > command. The 3 cases are: > > 1. TEST command entered from the command line. (works – message > trapped by the pipe) > > 2. TEST1 entered from the command line. (works) > > 3. TEST2 entered from the command line. (message is not trapped and a > timeout occurs approximately 15 seconds after the message is displayed) > > Is this normal? Or even explainable? > > pipe > q > > > FPLINX086I CMS/TSO Pipelines, 5741-A05/5655-A17 1.0110 (Version.Release/Mod) > - Generated 11 Oct 2005 at 12:04:21 > > q cmslevel > > CMS Level 22, Service Level 701 > > > > Regards, > Richard Schuh > > > > > -- > Kris Buelens, > IBM Belgium, VM customer support >
