Xref: utzoo comp.mail.misc:3435 comp.mail.uucp:4323
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sdd.hp.com!ucsd!nosc!crash!bblue
From: bblue@crash.cts.com (Bill Blue)
Newsgroups: comp.mail.misc,comp.mail.uucp
Subject: Re: pathalias breaks on latest map distribution - HELP!
Message-ID: <2902@crash.cts.com>
Date: 30 May 90 05:40:58 GMT
References: <1990May29.182555.27806@pmsmam.uucp> <3438@rex.cs.tulane.edu>
Organization: Crash TimeSharing, El Cajon, CA
Lines: 29

In article <3438@rex.cs.tulane.edu> mb@rex.cs.tulane.edu (Mark Benard) writes:
>In article <1990May29.182555.27806@pmsmam.uucp> wwm@pmsmam.uucp (Bill Meahan) writes:
>>Since the latest distribution I've received from comp.mail.maps, my attempts
>>to build a new pathalias database result in pathalias hanging forever while
>>taking up about 4.5 MEGS of core.
>>
>>After spending far too much time chasing the problem, I've found that
>>keeping u.usa.nm.1 out of the input stream solves(?) the problem.  Apparently
>>something in the lastest bunch of maps (which do NOT include nm.1 so far)
>>is inconsistent with the Apr 25 version of u.usa.nm.1.
>
>I had the same problem and tracked it down to an infinite loop involving
>bcsinc (in u.usa.ca.1) and rt1 (in u.usa.nm.1).  Since the NM map was not
>changed recently and that CA map arrived last night, I concluded that it was
>a problem with bcsinc.  Sure enough, commenting the bcsinc entry out of the
>CA map solved the problem.
>
>However, I do not know exactly why the loop occurred.  Can anyone explain?

It's even more interesting when you consider that the bcsinc map
entry hasn't changed since late August '89, and the rti entry
hasn't changed since mid September '89.  Something else seems to
be bringing this to a head.

--Bill Blue
	Southern California, Arizona Regional Uucpmap Coordinator
        UUCP: {nosc, ucsd, hplabs!hp-sdd}!crash!bblue
        ARPA: crash!bblue@nosc.mil
        INET: bblue@crash.cts.com