I wanted to read a file in XEDIT twice, using LOOKUP to match up two
fields. I started with this, which worked fine:
(end /) xedit | see: chop 0 | hole
| strliteral append "TOP" | subcom xedit | hole
| append xedit | seen: lookup ...
/ see: | seen:
At EOF on the first XEDIT, the first HOLE closes and STRLITERAL can
write the command to SUBCOM. At EOF on SUBCOM, the next HOLE closes,
APPEND XEDIT reads the file again, and everybody's happy.
I had to fix some of my processing, and while I was at it I thought, why
even create the extra null records when TAKE LAST could do the waiting
without any extra work? So I took out CHOP|HOLE and made it:
(end /) xedit | see: take last 0
| strliteral etc.
I was very puzzled to get just *some* of the expected results--and even
more puzzled when inserting CONSOLE stages *changed* what results I got.
Eventually I noticed that both XEDIT stages were running at the same
time, each one getting part of the file, and which records went to which
one changed with every little change in the pipeline. It was a great
illustration of just how unpredictable a timing issue can make the results.
So it turns out TAKE was too smart for my little ruse: Seeing the 0, it
just shorts the input to the alternate and terminates without waiting
for anything. TAKE LAST 1 does the trick, though it might be a little
obscure:
(end /) xedit | strliteral append "TOP" | see: take last 1
| subcom xedit | hole
| append xedit | seen: lookup ...
/ see: | seen:
As it turned out, I didn't actually need this lesson for the task at
hand after all. I really only had to match records from earlier in the
file, so I could skip the second pass entirely by using input 2 of
LOOKUP to add each record to the reference after it arrived:
(end /) xedit | see: fanout | seen: lookup ...
/ seen:
/ see: | seen:
(I'm still a little puzzled by why LOOKUP AUTOADD doesn't allow
different key fields--it would have served perfectly here.)
¬R
