fwiw ...
Pipelines stalled.
... Issued from stage 2 of pipeline 1.
... Running "Delay".
Stage is in state wait out.
... Issued from stage 1 of pipeline 1.
... Running "Strliteral /+5/".
Stage is in state wait out.
... Issued from stage 2 of pipeline 1.
... Running "Delay".
Stage is in state wait out.
... Issued from stage 3 of pipeline 1.
... Running "Faninany".
Stage is in state wait out.
... Issued from stage 4 of pipeline 1.
... Running "Gate".
Stage is in state wait out.
... Issued from stage 1 of pipeline 2.
... Running "Starmsg CP SMSG RSCSB (ST.) QUERY LINKS NETWOR".
Stage is in state unavail.
... Issued from stage 3 of pipeline 2.
... Running "Totarget Pick W-4;* == /End of command resp".
Stage is in state returned.
... Issued from stage 4 of pipeline 2.
... Running "Console".
Stage is in state returned.
Stage is in state returned.
Stage is in state returned.
Stage is in state returned.
+++ RC(-4095) +++
On Fri, Oct 31, 2014 at 3: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
>> >
>>
>
>
