Ahh, thank you Sir Rob.
--
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
> >
>

Reply via email to