Sorry, I did not see the full pipe on my phone. I missed part of the topology. I think you're biting in your own tail with the "End" record feeding into "gate" while that is still holding that record on it's secondary output. You'd put a "copy" in the primary input of "gate" so it gets consumed and "gate" can turn around to look at the primary input.
I normally also put a 'take' in the primary input of 'gate' but the book says that it terminates by itself. Happy Plumbing. Rob On 31 October 2014 20:45, Bob Cronin <[email protected]> wrote: > If you mean something like this > > pipe (end ?) strliteral /+5/ > | delay > | a: faninany > | b: gate > ? starmsg cp smsg rscs the-query > | b: > | c: totarget pick w-4;* == /End of command response/ > <stuff to process the response> > ? c: > | d: Fanout > ? d: > | a: > > then no, it doesn't work either (but using PipeStop on the secondary of > ToTarget sure does, though it seems a bit crude). > -- > bc > > On Fri, Oct 31, 2014 at 3:29 PM, Rob van der Heij <[email protected]> > wrote: > > > Shouldn't you fanout that end response into the faninany? Looks like you > > close after the end on next record. > > On Oct 31, 2014 8:16 PM, "Bob Cronin" <[email protected]> wrote: > > > > > Hm, except now the thing is stalling on me when the "End of command > > > response" IS coming back. That is when the secondary output of totarget > > is > > > fed to the faninany, it isn't closing the gate and terminating things > > > nicely. Whew this is fiddly. What am I (still) missing here? > > > -- > > > bc > > > > > > On Fri, Oct 31, 2014 at 2:55 PM, Rob van der Heij <[email protected]> > > > wrote: > > > > > > > But totarget is still supposed to write to its secondary output, so > it > > > does > > > > not care that you sever the primary. > > > > With the gate in front of that selection you cut the output of > starmsg > > > and > > > > the input of totarget. That rolls up the stuff. > > > > Rob > > > > On Oct 31, 2014 7:51 PM, "Bob Cronin" <[email protected]> wrote: > > > > > > > > > I am probably missing something subtle here about how gate behaves. > > > > > > > > > > I have a pipeline using starmsg to issue a structured query to an > > rscs > > > > > machine. It is supposed to terminate after the last line of the > > > response > > > > or > > > > > 5 seconds have elapsed. Yet, it never terminated. > > > > > > > > > > The reason it didn't is that the RSCS machine never responded > because > > > at > > > > > the time there was a RACF outage that affected IUCV (there was an > > IUCV > > > > > error 3 on the console). > > > > > > > > > > As written, the pipe looked something like this: > > > > > > > > > > pipe (end ?) strliteral /+5/ > > > > > | delay > > > > > | a: faninany > > > > > | b: gate > > > > > ? starmsg cp smsg rscs the-query-command > > > > > | c: totarget pick w-4;* == /End of command response/ > > > > > | b: > > > > > <stuff to process the response> > > > > > ? c: > > > > > | a: > > > > > > > > > > When I trace this I see the +5 being produced after 5 seconds, yet > > the > > > > pipe > > > > > does not terminate. If I restructure the pipeline as such: > > > > > > > > > > pipe (end ?) strliteral /+5/ > > > > > | delay > > > > > | a: faninany > > > > > | b: gate > > > > > ? starmsg cp smsg rscs the-query > > > > > | b: > > > > > | c: totarget pick w-4;* == /End of command response/ > > > > > <stuff to process the response> > > > > > ? c: > > > > > | a: > > > > > > > > > > > > > > > Then all is well, it terminates after 5 seconds when no response > > > arrives. > > > > > > > > > > I'm sure this is pipelines 101, but exactly why this is happening > is > > > not > > > > > entirely clear to me. Could someone explain? > > > > > -- > > > > > bc > > > > > > > > > > > > > > >
