Subj : *.MSG vs. packed help?
To   : Jonathan de Boyne Pollard
From : Mike Luther
Date : Tue Jul 17 2001 03:24 am

Yes and No, John ..

JdBP> Am I to gather than the problem is not the SQUISH
JdBP> messagebase format, but the triggering of the scan
JdBP> itself ?

The problem is because my custom executable that I wrote to do this called
MSG2ASK.EXE was written to go through the new message directory and cull off
only the new *.MSG files.  It carefully extracted each of the *.MSG files in
order sequence into the pure ASCI format which is used to import them into the
askSam.

It suffers from the same seizure mode that *.MSG suffers from as the message
base gets bigger and bigger.  OS/2 is a WONDERFUL game with HPFS.  And, you
really can get away with murder compared to what you would see on a pure DOS
386 BBS box!  But as the number of message bases goes way up and the number of
messages in the directory goes way up, even HPFS bogs.

Which isn't as bad with SQUISH .. obviously.

JdBP> Why not trigger it with the same mechanism that you
JdBP> use to trigger SQUISH ?  At some point you know when
JdBP> to run the tosser.  So just before you run the
JdBP> tosser, make copies of the ARCmail and *.PKT files,
JdBP> decompress them, convert the contents to "askSam"
JdBP> format, and import them into the database.

That was the substance of a couple suggesstions here.  It's probably the
easiest of the solutions.  In that OS/2 is threaded, we could do that
extraction run at precisely the point you suggest.  Then we can start a
separate threaded session doing the askSam import, which takes time.  While
that is going on, we let the BBS system go back on line for the next use,even
while the askSam import is still running.

I'm working at how best to do this now.

JdBP> An alternative, and very different, approach is to essentially have a
JdBP> purpose designed "scanner", that maintains its own
JdBP> set of "last read" pointers for each area in your
JdBP> messagebase.  When run, it scans each area, updating
JdBP> the last read pointers as it goes, exporting newly
JdBP> entered messages from the messagebase into the
JdBP> "askSam" database.  All that you then need do is
JdBP> trigger it whenever something new is added to your
JdBP> messagebase, or simply run it at regular intervals.

Curiously, I already have that exact code dormant in the .CMD file (was an old
.BAT file!) that runs BINK/MAX/SQUISH!  Currently, the part of it which is
still active in re askSam, is only the part which keeps the message cap
pointers for the askSam MSG2ASK.EXE control file updated!  What is already
necessary is to make sure that after each MR call in the MAX operations, we
massage the file MSG2ASK.CTL to reset the cap number for the re-numbered
message areas we are capturing to askSam.  The askSam doesn't, at least here,
capture NETMAIL, and can be selectively employeed just line configuring SQUISH
or AREAS.BBS or MSGAREA.CTL for example.

This update is done as part of the DAILY housekeeping segment.

I hadn't thought about making the actual import only a daily game until you
posted this.

Now I'm sitting here pondering if it would be better to do that, and suffer the
delay time in being able to find what all the dog did today in a near-real-time
deal, or just chain Fido to the doghouse once a day until he sings for his dog
bowl!

Your way would only disable the system for the time needed for that at some
normally un-used time anyway.  Maybe that's an acceptable answer.

Thanks!

--> Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001



--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)