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 >
