Your LOOKUP reads all of the secondary input first, because it is designed to do so. That is the initial master. You can elect not to have such a stream and add masters dynamically, but that would involve other streams than the secondary input.
On 13 September 2011 08:58, DUGALEIX Michaël <[email protected]> wrote: > Hello Rob, > > I do understand the "not fanout" trick, but there's a fact that I first > overlooked, and now that's the "lookup" I don't understand ... :-( > > I know I'm making a mistake somewhere, but I don't know where : > Could you help me to understand where I'm wrong ? > > > Here's how I understand your pipeline : > > For the first two records : KEY1_A_1, KEY1_A_2 : > "lookup" writes them. I'm ok with that : it sees them in its master (or > rather : With PIPEDEMO, I see that "lookup" can see them in both detail and > master) > > For KEY1_B_3 : > "lookup" doesn't write it. > Well, its key is not currently in the master (which has only one key at this > moment, shows PIPEDEMO), but how does "lookup" know that the key WILL NOT be > in the master later ? > PIPEDEMO shows me that when "lookup" gets rid of "KEY1_B_3", all the keys > have not yet arrived in the master. > They seem to get to the secondary input of "lookup" only just after "not > fanout" had read them. Very slowly. > > > This is very different from what I would have expected from lookup. > > When I read the "lookup" doc (pipe ahelp lookup on my z/VM), it says : > When a detail record has a key that is not present in any master record, > it is passed to the secondary output stream. > ... > The secondary input stream is read and stored as the initial reference > before the other streams are read. > > ... and that's what I see in PIPEDEMO with this simple other pipeline : > pipe (endchar %) > < FILE 1 A > | L: lookup detail > | console > % > < FILE 2 A > | L: > > > Would my problem be PIPEDEMO which doesn't display things in a live way ? > > Or is there a fundamental/topological difference between your pipeline ("not > fanout" + "lookup" + ...) and my simple previous pipeline (with the little > lookup) ? > > Why does MY lookup read all the secondary input stream, and why yours > doesn't explode/stall ? > It seems to me that "lookup" is adapting to each situation, but how ? > > If the explanations are available in some document, can you tell me which > one ? > > Thanks > Michaël > > -----Message d'origine----- > De : Rob van der Heij <[email protected]> > Envoyé : 08/09/2011 15:22 > À : [email protected] > <[email protected]> > Cc : > Objet : Re: "unique" stage, keys and sub-keys : How to keep enough "first > lines" ? >> >> On Thu, Sep 8, 2011 at 3:04 PM, Frank M. Ramaekers >> <[email protected]> wrote: >> >>> That got me too! "not fanout". I know what a "not" and a "fanout" >>> does, but the "not fanout" is not intuitive. >> >> I guess I can't imagine my audience to remember my posts when I also >> forget them ;-) >> http://rvdheij.wordpress.com/2011/06/29/it-works-better-with-lookup/ >> >> Maybe "not command" is more intuitve then? >> >> | Sir Rob the Plumber >
