MB> I have a Squish question that I have not been able to 
 MB> find the answer for in the documents.
 BJ>  ...
 MB> The question I have is:  With Squish and a *.msg 
 MB> message base, is there a maximum message number that 
 MB> can be handled?  Back in "the old days" I would use the 
 MB> renumbering feature of CONFMAIL to renumber the 
 MB> messages periodically to keep the ranges more 
 MB> reasonable.

 BJ> It depends on your OS, 

Windows for Workgroups 3.11 (I know, obsolete.  But it has been running
virtually error free and non-stop for about 11 years now, with only a
memory upgrade and a harddrive upgrade in that period.  Oh, and a couple
monitors too.)

 BJ> the binary you are running, 

It came from the archive SQSH_111, and refers to version 111 in the docs.

 BJ> the type of
 BJ> message base you have and how you have formated the disk partition
 BJ> you store the messages on.     

It is a subdirectory of the root, so there are fewer directory related issues.

 MB> And I am using *.msg format because I have become 
 MB> rather comfortable with them over the last 15 years or 
 MB> more of being a point, and why change a known good 
 MB> thing?  :-)

 BJ> Since you are using *.msg, I believe your limits will come from the
 BJ> partition you are using for the message base.  If I remember
 BJ> correctly, there is a maximum of about 512 files in the root
 BJ> directory of a FAT partition.  Since there is one file per message
 BJ> in *.msg format, that gives you an idea of the limit.  Since
 BJ> subdirectories on a FAT partition are not as limited to the space
 BJ> taken up by the directory contents, subdirectories on FAT
 BJ> partitions can have significantly more files....  

That has not been a problem as there are only a few thousand messages
there, but the message numbers are getting up there (in the 22,000 range).

 BJ> But too many files will hit access speed  issues. 

It is a bit slow at times, but an occasional cleanup and defrag works wonders.

 BJ>  I'm not sure what the limits
 BJ> are on HPFS and NTFS paritions, but I expect those are relatively
 BJ> high.

Virtually unlimited, with any reasonable disk size, for NTFS.  I don't have
much OS/2 experience.

 BJ> For Max itself, (if using the BBS code to read the areas), there
 BJ> may be a 32K limit in that code (due to access via a message
 BJ> number).  Maybe the limit is 64K.  Maybe the limit is 4Gb....  I
 BJ> haven't looked at the code to see. 

No BBS here, just a point with TimEd, with the Y2K patches.

 BJ> As to squish message bases, running under OS/2, with the sq386p
 BJ> version of the code, I think I've had areas with over 20K messages
 BJ> in them.  There is a point at which some of the related tools will
 BJ> break (such as the squish tools used to fix broken databases).  And
 BJ> I have had squish process squish style message bases that the
 BJ> squish tools (under OS/2) couldn't handle due to number of
 BJ> messages.  I think the limit is around 10K to 16K messages under
 BJ> regular DOS.  I don't think I took any message bases above about 5K
 BJ> messages when running the DOS (16 bit) version of the squish
 BJ> code....                                 

No squish message bases.

 BJ> For dupe file checking, from memory, just over 3K was the limit of
 BJ> what is handled by the dupe checker, so make sure you don't toss
 BJ> old message back out of your system on a rescan....  

I'm pretty careful about that, and do not automatically send out packets. 
I manually run an "export" to send out messages.

 MB> I guess that I could get the SQUISH source and check it 
 MB> out myself, but with only most weekends and about every 
 MB> third or fourth workweek in town, that might take a while.

I guess that I will need to look at the code.  Or I could just catch up
while I am in town for a few days.  :-)

Mike Bourne

--- timEd 1.10.y2k