Hi Rick,

>>>> NLMaint has caused a variety of problems - unpredictably.

>>> User error?

>> No :)  From what I understand, the dos version is very bad and doesn't
>> process segments correctly, and I've heard that it drops regions.

> Well I've never used the dos version so I can't comment, maybe the compiler
> used did something odd.

Same here.. I've never run it..

>> The Linux version I am running worked fine for me in the begining,
>> then
>> randomly would not process new segments that came in from RCs. Sometimes
>> it would drop whole regions from the nodelist.

>> I got around that problem by having my script copy all new segments into
>> nlmaints' Inbound directory, running it in test mode to move them into
>> the Update directory, and then touching files in the update directory
>> and in the Master directory before the zone 1 list run on Tuesday
>> nights, and the thursday nodediff run. In recent weeks and months, there
>> was no problem at all with it. The problems I mentioned happened perhaps
>> a year ago..

>> Then, this Tuesday's Zone 1 segment was created for the other zones, and
>> my own listings in net 261 (1:261/38 and 1:261/100) were missing..as
>> though my RC had submitted a segment from a period before I moved to
>> that region in June (he hadn't done that though) :(  There may have been
>> other errors in that zone list, but this one is the one that I've heard
>> about 

>> I didn't notice that error, but was made aware of it by one of my
>> downlinks from Z2 on Friday afternoon, well after the Thursday nodediff
>> run.

>> This thursday, around the time the nodediff should have been processed
>> on my system, I was curious because I was on my bbs checking mail, and
>> didn't get the normal, "Nodelist.298 has been updated to
Nodelist.305"
>> message from my bbs..

>> I stopped all the cron jobs so I could check the nodediff before it got
>> sent out all over zone 1, and took a look.. NlMaint had an erroneous
>> date (sometime in 2001, not this Friday's date in 2002), and the wrong
>> CRC on the diff, and that's why my bbs's nodelist compiler wouldn't
>> apply the diff.

>> I removed all the *305 files from nlmaint's subdirectories, and ran my
>> nodelist/nodediff script again manually.. this time, it created a
>> perfect Zone 1 segment, and a perfect diff.. as far as I know, at least.
>> I haven't heard of any problems down the line :)

>> So.. it can be flukey.. I'll be watching it very carefully in the next
>> few weeks 

> The occurrences you describe seem to remind me of the things it will do if it
> gets a bad segment. Completely leaving things out etc from bad dates,
> formatting etc.

heh.. interesting.. though why no problems on the second run with the same data?

> Does it often give you errors? I find that it doesn't agree with a lot of
> practices occuring within the nodelist(s) but generally most of these will
> produce error reports and the segment/list will still compile.

Same here - Tons of warnings, not errors, regarding non-redundant hub
entries.. Errors for sure with embedded white space, though, when they turn
up. That will cause rejection of a line, and mark it with ;E-

> The particular problem noted above seems to be a date issue, whether that
> occurred there or due to a date in a segment I couldn't say.

Well one thing I have to do is check whether there was a previous year's
*.305 file in any of the directories where it imports files from.. haven't
done that yet.. I don't expect I'll find one .

I've also got to find the source for the linux version.. I had it here for
a while.. so I can look through the source.. can't imagine it's overwriting
memory, but could be.. perhaps it's importing too much data or something..
I remember when we ran into a problem with the original TICK program.. the
prg. read the entire config file into memory, and with a huge number of
file echos over here, and the large number of downlinks, it was just too
much for it. That's when work on allfix started .

Take care,
Janis

--- BBBS/LiI v4.01 Flag-4