You could play games with the secondary output from COMMAND: pipe (end \) i:fanin|spec /END/ 1|literal END|stack lifo\< command list |c:command|...\c:|copy|i:
And you'll have an END on the stack when it terminates. If you know how many commands up front (or can compute it), you can add a TAKE in front of STACK. j. 2009/8/11 Schuh, Richard <rsc...@visa.com>: > Not a problem. All of the responses are the same, "END". The next one will > read the first queued response and then clear the stack. > > Regards, > Richard Schuh > > > >> -----Original Message----- >> From: CMSTSO Pipelines Discussion List >> [mailto:cms-pipeli...@vm.marist.edu] On Behalf Of Glenn Knickerbocker >> Sent: Monday, August 10, 2009 3:13 PM >> To: CMS-PIPELINES@VM.MARIST.EDU >> Subject: Re: Is there a better way? >> >> "Schuh, Richard" wrote: >> > 'PIPE (end \) ... build commands ... | f: fanout | spec >> /response/ 1 | stack \ f: | command | cons' >> >> > if the command fails and crashes the pipe, the worst that >> can happen >> > after the crash is one unrecognized command. >> >> How about when one command fails to read its response from >> the stack but >> *doesn't* kill the whole pipe, though? If you're really >> using the same response every time, it won't matter, but >> otherwise all the remaining commands will read the wrong >> responses. You can avoid this by using another copy of the >> input record to empty the stack after each command: >> >> \ f: | specs /callpipe stack || *:/ 1 | pipcmd | ... report >> errors ... >> >> If you don't care about these errors, I suppose you could use >> STACK LIFO and just let the unread responses pile up. >> Actually, STACK LIFO might be a good idea either way, so you >> don't have to worry about what might be on the stack when you start. >> >> ¬R >>
