ML> Though I'm *not* a moderator of the Muffin echo, I was going to ask those 
 ML> of you that post _long_ messages (in excess of 15k) to 
 ML> please split them into Fido sized chunks.  Squish in 
 ML> particular, will mark the .pkt the messages appear in 
 ML> as ".LNG" and set it aside, not tossing your message.  
 ML> Then an external message splitter like PktSort has to 
 ML> be run on the .pkt to make it toss properly.  Lots of 
 ML> folks *don't* have PktSort nor know how to use it, so 
 ML> the messages don't get seen on that system (or its 
 ML> downlinks).

If squish is choking on the message size of recent large messages, then you
have it set to run with smaller buffers than it can run with.  And
therefor, you are choosing to limit what messages are processed on your end
based on message length.  Based on your tear line (timEd/2), you're running
under OS/2.  Considering that I'm also running squish under OS/2, I know
you have an option that will handle the longer messages that have been
posted here recently.....  [At least the ones I've seen in the echo.]

What this does bring up is that it would be an potientially good feature to
add to Max or to Squish to have that code (optionally) break messages apart
into multiple messages *when* a configuration sepecified size is hit, and
the message was originated on the system. Another option might be to add
such feature to squish for passing messages on to downlinks, maybe
configurable per downlink.....  Yes, this is a problem, but the long
messages are within the FTSC standards.....  Yes, messages can be made long
enough to even break my setup and still be within FTSC standards.....  And
a (major?) code change would be needed to squish (and maybe Max) to handle
very large messages.....

Now for those still running the 16-bit version of squish in an old DOS (MS
or PC) environment, some of the messages could have hit limits.  I know I
did generate one message over the size that one member in my net has
problems with (who is not using squish).  Those with older software have to
realize the limitations of their software and take appropriate actions.  In
our net's case, I see the long messages that go through my system and hit
our other members system come back to me as dupes, caused because the end
of the message gets trucated.  I've seen two of those recently, one which I
generated the original message....  So, I am aware when it happens in this
echo, and yes it has impact to me and to the one other node in this net....
 [And it keeps exercising the dupe checker on this system until I can get
the other node in my net to delete the problem message on his system.]  But
that is our choice in continuing to use the older tosser within our local
net.....  I would suggest that you implement what you need to within your
local net for dealing with large messages.  They are going to happen.  At
least the messages I generate are limited by what Maximus BBS sowftware
running under OS/2 or Linux can generate.  [I believe that is set to 250
lines, with a maximum of 80 characters per line ringt now.  Then add kludge
lines as the message gets processed.]

As to zone 1 distribution, I don't believe any of the top level zone 1 hubs
are running software that chokes on the message sizes I've seen here
recently, but I could be wrong....

Side note:  The large message I generated would have been longer, but it
hit the limitations in Maximus running under OS/2....

 ML> Thanks in advance!!



Good luck.....

Take care.....

Bob Jones, 1:343/41


--- Maximus/2 3.01