If I do that then any mail sent to a mailing list that has some contractor on it for which there is also another person with the same address, just without the /contr, will be sent to both of them. I'd like to try to avoid that. -- bc
On Fri, Aug 7, 2009 at 1:39 AM, John P. Hartmann<[email protected]> wrote: > What the heart is full of... Rob meant TOTARGET LOCATE 1. And he > really should mean PICK TO 1 == // (a null string). > > Given that few are both contractors and not contractors, I'd try them > both rather than messing with inherently unreliable topologies. After > all, fanintwo is also at the mercy of the dispatcher. > > j. > > 2009/8/7 Bob Cronin <[email protected]>: >> I did add a null record, but I don't have a "TOTARGET NOT LOOKUP 1", I >> am still using the COUNT and using the alternate output as the >> mechanism to terminate the GATE that the records being fed to the >> primary input of LOOKUP flow through on their way there. >> >> Look folks, I didn't mean to incite a religious war, I just needed a >> way to modify some records that didn't match the first time and then >> go look them up again. If you all think it would be >> safer/more-efficient to FANOUT the reference for the existing lookup >> and use it again as the reference for a second LOOKUP on the secondary >> output of the existing LOOKUP, I can do that (although I worry about >> how much storage that'll take, this is a seriously large chunk of >> data, more than half-a-million records). >> >> The only reason I thought of this approach was that I read the LOOKUP >> help and saw all the nice facilities for adding records to the >> reference on the fly and (naively) wondered if the same sort of thing >> might be doable for the detail records so that I didn't have to make a >> second copy of the reference. >> >> How about we forget whats gone on so far and start afresh. What's the >> very best way to do what I need to do? Can we get some sort of >> consensus from the experts? >> -- >> bc >> >> On Thu, Aug 6, 2009 at 5:56 PM, Rob van der Heij<[email protected]> wrote: >>> On Thu, Aug 6, 2009 at 11:20 PM, Glenn Knickerbocker<[email protected]> >>> wrote: >>> >>>> Actually, because it delays the record, your solution has the same >>>> problem. The alternate output of TAKE LAST may be written anytime after >>>> the last record on the primary is released, just the same as the >>>> alternate output of COUNT. >>> >>> Sigh. This isn't trivial plumbing... so I guess we need a "pipeline >>> pig" append a null record and let it go through the lookup. That will >>> not match and be written to the secondary output where we can produce >>> the eof (with a "totarget not lookup 1") >>> >>> Rob >>> >> >
