I've got just one last question. Does it seem reasonable behavior for the original (admittedly flawed) pipeline I posted to end up waiting forever when there was no response from RSCS? What exactly was it waiting for? -- bc
On Mon, Nov 3, 2014 at 2:27 PM, Bob Cronin <[email protected]> wrote: > I guess what I was missing is that TOTARGET finding the end-of-response > line would terminate the STARMSG. I thought I had to force the gate closed > when that happened. > -- > bc > > On Mon, Nov 3, 2014 at 2:05 PM, Glenn Knickerbocker <[email protected]> > wrote: > >> On 11/1/2014 6:11 PM, Bob Cronin wrote: >> > Since the whole point of the pipe is to trap the query response and >> process >> > it (and secondarily to complete as soon as the end of response is seen, >> or >> > 5 seconds max if not), totarget seemed the logical choice. I'm not sure >> I >> > see how to achieve the same thing in as clear a way in the fashion you >> > suggest. >> >> Just replace TOTARGET with NOT. >> >> In your pipeline, you're splitting the file once at "End of command >> response" with TOTARGET, and then feeding the first line of the second >> part to GATE to split it again at the same point. Essentially, you're >> using two GATEs to do the same thing. >> >> Instead, you can just send that one line to the primary of GATE, to stop >> reading right there. It doesn't matter which stream the rest of the >> file after that would have gone to, because you'll never read it. >> >> Alternatively, instead of using FANINANY to combine the inputs to the >> one GATE, you could use TOTARGET to watch for the end of the response >> and GATE for the timeout. But you have to be careful to put them in the >> order that you saw worked before, so that the timeout successfully >> severs the output of STARMSG: >> >> > pipe (end ?) strliteral /+5/ >> > | delay >> > | b: gate >> > ? starmsg cp smsg rscs the-query >> > | b: >> > | c: totarget pick w-4;* == /End of command response/ >> > <stuff to process the response> >> >> And if whatever's downstream severs its input before the end of the >> response, you'll see the same problem again, but mitigated by the >> successful timeout: EOF won't propagate upstream through TOTARGET, and >> you'll wind up waiting for the timeout. >> >> ¬R >> > >
