"Hughes, Jim" wrote:
> <Set Learn On>
> What is this PIPE and CALLPIPE attempting to do?
Nothing useful, besides illustrating the problem.
The PIPE presents five records to input 0 and one record to input 1 of
LOOKBAD REXX:
pipe (end /) literal 1 2 3 4 5|split|a:lookbad|cons /literal 3|a:
The CALLPIPE reads the records on input 0 up to the one that matches
input 1:
"callpipe (end /) *..0: | exact: lookup detail | end: gate
/ *..1: | exact: | end: | *..0:"
* First, LOOKUP reads on its input 1 the file from input 1 of LOOKBAD
(just the one record "3").
* Then, LOOKUP reads on its input 0 each record of the file from input
0 of LOOKBAD. It writes the nonmatching records to its output 1,
which is connected through GATE to output 0 of LOOKBAD, which is
connected to CONSOLE, so "1" and "2" get written to the console.
* When LOOKUP gets to "3" on input 0 and matches the "3" from input 1,
it writes it to its output 0, connected to input 0 of GATE. GATE
sees this input record and terminates immediately, LOOKUP sees all of
its outputs disconnected, and the whole CALLPIPEd pipeline shuts down.
When all this is done, the "3" shouldn't have been released on input 0
of GATE or input 0 of LOOKUP, so it should still be available on input 0
of LOOKBAD. When LOOKBAD issues PEEKTO, though, instead of seeing "3"
it sees "4"--the "3" has vanished without having a chance to be passed
on to any stage downstream.
So what was I going to use this for in my application? I want to split
a log file at the last record I saw--which might have been pruned from
the log already, or might come in the middle of other records with the
same timestamp. I was going to use COLLATE to find the first match of
the timestamp, use LOOKUP to match the exact record, save what came in
between, write out those saved records to the "before" output if there's
an exact match or the "after" output if not, and then short the rest of
the file to the "after" output. Problem was, when I did have an exact
match, it disappeared from the pipeline before I had a chance to pass it
on.
I can work around this by saving the exact match in my CALLPIPE and
rewriting it afterward. But that introduces unnecessary record delay.
I was hoping to buffer only the records whose disposition couldn't be
determined right away: the ones with matching timestamps before I reach
an exact match.
>From PIPELINE NEWS1111, it looks like this is probably what fixes the
other test case:
> -------- Shipped to VMTOOLS 29 Jun 1999 10:58:08 -----------------------
> PIPELINE MODULE Modification 1.0110 sublevel 002A (42 in decimal)
...
> FROMTARGET and TOTARGET are now implemented using FILLUP and FANOUTWO.
FILLUP is one of those "new" stages that still aren't in my regular
repertoire. I could probably use it here to mash the whole mess into a
single pipeline set and then not have to worry about what's left in the
pipeline.
¬R
