It is 1:1 - one END response on the stack for each command. The commands are built in the pipe. Each command must have an END (interpreted as End-of-Command, not End-of-Command-List) response before it will execute anything. There is no command output until after an END is read from the stack, it just keeps posting VM Reads until it gets the END response.
It still seems that the fanout with the stack on the primary and the command on the secondary is the simpler solution and should always work. If there were 1000 commands generated and each of the first 999 failed without clearing the stack, the last one would pull the first END from the stack, execute, and then clear the remaining 999 ENDs. I plan to also clear the stack following the Pipe in case the last command fails. Regards, Richard Schuh > -----Original Message----- > From: CMSTSO Pipelines Discussion List > [mailto:cms-pipeli...@vm.marist.edu] On Behalf Of John P. Hartmann > Sent: Tuesday, August 11, 2009 12:36 AM > To: CMS-PIPELINES@VM.MARIST.EDU > Subject: Re: Is there a better way? > > 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 > >> >
