MT> and each user needs to use it.  Squish will still skip 
 MT> over messages with grunged dates that were uploaded 
 MT> from unfixed readers (Bluewave, compatible, or 
 MT> otherwise) and not scan them out.  You get one "grunged 

 SD> ECHOFIX has damaged every message base that it's touched.  I'm not
 SD> sure what's going on, but I've just about written off BW; it's
 SD> become more trouble than it's worth for the little usage it would
 SD> get on my board.

this sounds like a version mismatch between echofix and your bbs
software... very possible if echofix is coded for a specific version of the
bbs but the bbs is using another version of the config format or such... i
run into the same on my RA system when i check out older software... since
i'm running the last beta of RA that was given to the beta team for
testing, things can get hairy when old software is using an older config
format... i have actually have to create several "split" tools
which will split certain files into the old format and save the newer
format stuff, then run the tool/door, and then unsplit the config parts
merging them back together in the new format with the updated data from the
tool/door activities...

dunno if your problem is steming from config file differences or message
base format differences, though... the problem i describe above has been
from older tools/doors using smaller record sizes then what the system is
currently using... this has been especially true after a new version of the
bbs was released and the tool/door was lagging behind where the tool/door's
maintainer had not grabbed the new config structures and recompiled their
tool/door and released the update...

)\/(ark