ML> folks *don't* have PktSort nor know how to use it, so the messages 
 ML> don't get seen on that system (or its downlinks).

 BJ> If squish is choking on the message size of recent large messages,
 BJ> then you have it set to run with smaller buffers than it can run
 BJ> with.  And therefor, you are choosing to limit what messages are
 BJ> processed on your end based on message length.  Based on your tear
 BJ> line (timEd/2), you're running under OS/2.  

 ML> It's not for me, Bob.  It's for 2 of my downlinks that are running small 
 ML> DOS systems with limited memory.  

Ok.  Again, I'll say they have choosen to run in that environment.  Part of
the reason I run under OS/2 is because I was hitting similar size
limitations.....  Those sysops need to realize their limitations...... 
Until BBS software is setup to easily allow for message spliting, such
action isn't going to happen by most message posters.  Yes, I could dig out
PktSort.  From memory, there isn't an OS/2 native version of the program. 
While the dos version of the program will run on an OS/2 box, it will have
its limitations.  I seem to recall some major speed impact on the first box
I think I played with that code.....  And promptly decided *not* to use
PktSort.......  

I know at least two of the remaining BBSes in my local net are running
rather old software, possibly on rather old hardware, so yes, this is a
problem from the standpoint of attrition.....  

So, from my perspective, for now, my choice is either to post the long
message as a whole or not post at all.  When I'm answering a question, I'll
post.....  And on rare occations, it will be long.....  But I am still
limited to the buffer sizes that Maximus/2 has for messages....

Any way....

Thanks for the point.  As I previously said, sounds like an option for an
enhancement to Max and/or Squish for messages processed on the originating
system.  This isn't something that will get looked at any time soon by me.

Take care......

Bob Jones, 1:343/41

--- Maximus/2 3.01