What happens is:
1. LOCATE writes a record to its primary output.
2. GATE shorts its primary input to its primary output.
Things are now indeterminate (so the change to short the primary input
was a mistake).
3a. EOF propagates back to LOCATE before the GATE terminates.
3b. GATE terminates and EOF then propagates.
However, whatever the dispatcher does, it should always do that, but all
bets are off if you change the pipeline topology.
GATE terminates at the latest when a record arrives at its secondary
input stream. This record is not consumed.
LOCATE then terminates without consuming this record.
On 09/14/2016 05:26 AM, Glenn Knickerbocker wrote:
I had a crazy error pop up where a sipping stage failed to write some
sections of a file, as if it had kept reading past where GATE should
have shut everything down. When I tried to reproduce it with the same
input, I couldn't with the current level but I did at least once with
the z/VM 6.3 level (110A002D) that the user was presumably using. But
then after I added more tracing to my stage, I could never reproduce it
again. And the pipeline is awfully simple, with just 4 stages still in
the picture when the problem might have occurred.
Just to make extra sure, is there any chance something like this could
read past the first separator record that hits the primary of GATE?
'callpipe (end /) *.in.1:' ,
'| time: locate' sep ,
'| chop 15' ,
'| var rdrtime' ,
'| stop: gate' ,
'/ time:' ,
'| stop:' ,
etc.
Record arrives, GATE shuts down, VAR consumes the record, and then
everybody should see EOF and terminate, right? Is there any chance
LOCATE might keep reading until it tried to write to the primary again?
The input is a huge mess of GETFILES, MERGE, and JUXTAPOSE, but that
wasn't involved when I reproduced the error. My input then was just
DISK|INSERT.
(I'm writing it off to some fluke of corrupted minidisk cache that has
since evaporated. But there was a weekend between the user's problem
and my reproducing it, so that's mostly wishful thinking.)
¬R
