Whew... Furballs, burps etc? Heck that was more like projectile vomit.

Having said that, while this can happen to ANY tosser/scanner software (including my own ViaMail/ViaToss), the key here is it's the SysOp's responsibility to keep an eye on things.

After a shuffling of conferences, the next time a SCAN of the message
bases is done by the tosser, the SysOp should closely monitor what the
tosser does. Literally, stand there and watch it! So if a SCAN
produced 20mb+ of extracted messages (which is what happened) no big
deal. The SysOp would simply STOP the delivery of the outbound
generated archives/PKTs and physically move the archives (or delete
them) along with the associated netmail messages so that the mailer
wouldn't send them out.

Now the SCAN should have updated all the message base 'last extract'
pointers so that anything entered by users, the system would now extract
them normally. So life should be good. Archives saved off for future reference (or deleted).

Now the SysOp should be concerned enough that if this happens, he/she
would go back and review the messages that were extracted to get a good understanding of what just happened -- very important.

Scenerio: So let's say that the BBS's conferences were lined up
properly with the echos and that the existing messages from the local
message base were from a different echo but were reconfigured for a new
echo.

Bad news, you should NEVER do this! Why, because if a downlink performs
a rescan of the new echo, their system would now get a mixture of both
old echo messages AND the new echo messages. You as the SysOp have
several choices here:

1) Ensure that the message base is empty before using it.

2) Carefully rename/move the existing message base so that it lines
up with the SAME NAMED echo. ie: What was WILDCAT_SUPPORT (conference
#100) is renamed to WILDCAT_SUPPORT (conference #150) or put another
way, MSG100.DAT/IX is renamed to MSG150.DAT/IX.

Now #2 implies that the SysOp fully understands the implication of
renaming message base data files (users last read pointers etc). So if
you don't have that level of confidence, you should stick with option
#1 (empty message bases).

Okay, so why did I take the time to lay this all out? Simple, we have
all taken short cuts and crossed our fingers to see if "we got it
right". The key here is keeping your eye on the ball. If the tosser
extracts a whole bunch of messages immediately after re-configuration,
it's the SysOp's responsibility to prevent those messages from going out
to the masses as well as investigate what just happened. More
importantly (almost anyway) you'll prevent yourself (and your software)
from being the target of significant criticism.

So this message is not an attempt point blame, but rather to get folks
to pay attention to what they're doing so that this type of situation
doesn't occur moving forward.

If anyone has questions, feel free to send them my way.

Regards,

Joe Martin

--- ViaMAIL!/WC v2.00
* Origin: ViaSoft Support BBS - Back online at 303-953-0568 (1:104/57)