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)

.