Are you discriminating against contractors? If both of them are there, shouldn't they get the message both, particularly if they are different persons?
j. 2009/8/7 Bob Cronin <[email protected]>: > 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 >>>> >>> >> >
