Subj : *.MSG vs. packed help?
To : Mike Luther
From : Mike Tripp
Date : Mon Jul 09 2001 04:03 am
Hello Mike!
08 Jul 01 14:54, Mike Luther wrote to All:
ML> But what is missing, if I go to, for example SQUISH and a SQUISH
ML> message base, is the fact that in the toss process, we don't get a new
ML> cap and a new stack of *.MSG's in a directory to clue the askSam
ML> thread task, to "Aha! traffic! Munch in all from the old cap to the
ML> new one!" That's how I wrote the interface code hard coded untility
ML> which is called now to do the task I wrote ass MSG2ASK.EXE all these
ML> years ago.
You could use something like NETMGR or SQTOOL to dupe messages from their
Squishbases to *.MSG copies for your utility to process. Depending on your
code, you could probably eliminate the watermark test conditions in your util
so that it always processes all .MSGs and then nuke them afterwards,
eliminating the expire/renumber maintenance that you're switching to avoid.
You're still going to suffer from load with volume, generating one file per
message, though. You could eliminate the rest of the drawbacks of *.MSG (all
those file open/close/find-next ops) if you rewrote the util to handle a
multi-message ASCII dump (like you could get from the previously suggested
TopicX) as input. If you so desire, this extract could contain all the new
messages from all areas, in one file. Of course, that would involve swapping
human time for computer time...and most of us have more of the latter than the
former to burn. :)
However, a *.MSG-free life contains more spare time of both types. I gave up
on them back when the BBS box was 4.77Mhz XT w/2 x 20mb ST225's. The
differences in overhead were = p a i n f u l l y = obvious on that gear. ;)
Many thanks to Scott Dudley for writing code efficiently enough to run on that
box and for providing the incentive to explore OS/2 (and Netware, for that
matter) as soon as I could get my hands on 386's.
