No I am simply trying to fix the situation where a contractor is now not a contractor anymore, but their old address is still on a mailing list (which I have to resolve to rfc822 format and actually forward mail to). I want to try to look them up in the dircat and if (and ONLY if) not found, try to look them up without the /contr, and then if they are found, use that as the target address. -- bc
On Fri, Aug 7, 2009 at 10:29 AM, John P. Hartmann<[email protected]> wrote: > 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 >>>>> >>>> >>> >> >
