In your original (iirc) the stage between starmsg and gate was keeping starmsg from seeing its output severed, so it would have waited forever (or until a pipestop).
-- Mike Harding z/VM System Support /sp CMSTSO Pipelines Discussion List <[email protected]> wrote on 11/03/2014 01:02:07 PM: > From: Bob Cronin <[email protected]> > To: [email protected] > Date: 11/03/2014 01:03 PM > Subject: Re: Gate behavior > Sent by: CMSTSO Pipelines Discussion List <[email protected]> > > 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 > >> > > > > >
