Thanks, the copy does solve the stall. > while that is still holding that record on it's secondary output
I guess this is what I don't understand. Why is it still holding that record exactly? -- bc On Fri, Oct 31, 2014 at 5:14 PM, Rob van der Heij <[email protected]> wrote: > 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 > > > > > > > > > > > > > > > > > > > > >
