Hello All !

What are Squish's area, messages and size limitations ?

A RA_SUPPORT guy said JAM had a 10,000 area limit and unlimited messages.

Maximus has a Squish "Renum Max" keyword limit of 65535 (I think). Is this a limitation of Squish or Maximus ?

From Squish.Doc, it appears that Squish has the following limitations,

====================================================================
Maximum areas: Unlimited (depending on available memory)
Maximum messages per area: 5,400 (16 bit), "almost any size" (32 bit)
Maximum message size: 63k (16 bit), 256k (32 bit)
Maximum area size: N/a ====================================================================

But the information is inconclusive / non definitive, as they're based on SQFix
and <msgbuf>.

The only definitive information is regarding the maximum number of echo areas.

Here're the details I could garner,

+---------------+
| Maximum areas |
+---------------+

Unlimited:

Any number of EchoMail areas can be defined, limited by available
memory.

+---------------------------+
| Maximum messages per area |
+---------------------------+

5,400 msgs for 16 bit and "almost any size" for 32 bit:

While the 16-bit version of SQFIX is limited to areas of roughly
5400 messages in size, SQFIX32 can rebuild message areas of
almost any size.

+----------------------+
| Maximum message size |
+----------------------+

63k (16 bit) and 256k (32 bit):

The defaults for the 16-bit versions of Squish (SQUISH and
SQUISHP) are:

BUFFERS writebuf outbuf msgbuf
Small 16k 16k 16k
Medium 26k 40k 32k
Large 57k 57k 63k

The defaults for the 32-bit versions of Squish (SQ386 and
SQ386P) are:

BUFFERS writebuf outbuf msgbuf
Small 64k 64k 64k
Medium 76k 128k 128k
Large 128k 512k 256k

+-------------------+
| Maximum area size |
+-------------------+

I'll assume this will be the maximum Operating System file size.

Or ~332 mbs for 16 bit Squish (5,400 * 63k = 340,200 kbs).

--- Msged/386 4.30
* Origin: ypan.dyndns.org loves Msged... (3:712/104)

Minh Van Le wrote in a message to All:

Sorry if this has been addressed... this is an echo I don't usually read.

What are Squish's area, messages and size limitations ?
From Squish.Doc, it appears that Squish has the following
limitations,

Maximum message size: 63k (16 bit), 256k (32 bit)

I've been wondering for long time about the message size as well. I think around the beginning of each month Squish boots out messages (I think in the STATS echo) that are big and renames the .pkt files to *.LNG.

I've looked around before and never found any way to deal with these long messages or the *.lng packet files. Is there a way to do this?

THANKS!!!!


*Paul*
--- timEd/386 1.10.y2k+
* Origin: Dumb Guy's!!! (1:124/5025)

Hello, Paul...

Mar 15, 2008 at 14:48, Paul Lentz wrote to ALL:

I've been wondering for long time about the message size as well. I
think around the beginning of each month Squish boots out messages (I think in the STATS echo) that are big and renames the .pkt files to *.LNG.

I've looked around before and never found any way to deal with these
long messages or the *.lng packet files. Is there a way to do this?

I just delete them when I think of it. They are stats reports from one of the hubs.

Regards,

Jerry Schwartz

mailto:jerryschwartz@comfortable.com
http://www.writebynight.com

--- Msged/NT 6.0.1
* Origin: Write by Night (1:142/928)

Hello Paul!

15 Mar 08 14:48, Paul Lentz wrote to ALL:

Maximum message size: 63k (16 bit), 256k (32 bit)

I've been wondering for long time about the message size as well. I
think around the beginning of each month Squish boots out messages (I think in the STATS echo) that are big and renames the .pkt files to
*.LNG.

OS/2 exe (which you may be running?) can be configured to toss as large as OS/2
has resources to support. 256K is just the largest Scott Dudley tested with and supported by the canned keyword "Buffers Large". You have to define buffers manually to go higher...and have the resources to support them available, of course. If you want 1gb messages, Squish (SQ386P) can process them...but maybe your other utils (BBS, online readers, offline readers) or downlinks can't.

I've looked around before and never found any way to deal with
these long messages or the *.lng packet files. Is there a way to
do this?

PKTSORT is a pre-toss utility that can split/unsplit large messages to user-defined sizes and recreate the inbound PKTs accordingly. If you dupe-check headers though, you need to set the config option that tells it to prepend the "1/5", "2/5", "3/5", etc to the subject line rather than append it (default behavior). Squish only looks at the first 24 chars of the subj, so you
may get false dupes if the extra info is appended to a long subj.

IMHO, messages too long for "Buffers Large" were messages I didn't care to actually read anyway.<g>

.\\ike

--- GoldED/2 2.50+
* Origin: -=( The TechnoDrome )=- Austin,TX 512-327-8598 33.6k (1:382/61)

Maximum message size: 63k (16 bit), 256k (32 bit)

I've been wondering for long time about the message size as well. I
think around the beginning of each month Squish boots out messages
(I think in the STATS echo) that are big and renames the .pkt files
to *.LNG.

I've looked around before and never found any way to deal with
these long messages or the *.lng packet files. Is there a way to do
this?

shirley, you jest! ;)

there is the packet split stuff... there's a fido technical document about the split proposal to break messages up into smaller units but my bitch about it is/was that it puts the onus on the feeder instead of the feedee with the size problems...

i'm thinking that the pktsort package does the split stuff as well as sorting messages in the pkts together by area name which also helps tossing to go faster...

if you can't find a copy, let me know and i'll give you some more info ;)

)\/(ark


* Origin: (1:3634/12)

mark lewis wrote in a message to Paul Lentz:

Maximum message size: 63k (16 bit), 256k (32 bit)

there is the packet split stuff... there's a fido technical document

<snippage>

my bitch about it is/was that it puts the onus on the feeder instead
of the feedee with the size problems...

i'm thinking that the pktsort package does the split stuff as well
as sorting messages in the pkts together by area name which also
helps tossing to go faster...

I've had squish split up a big email I have gotten on more than one occasion. Iirc from when I ran pktsort it did this as well.
My old way of doing it was to run gus on anything in an inbound where echomail was permitted, then run pktsort on the resulting packets. NOw technique is the
same, but I do it with pktdate to make sure that my robot doesn't send any y2k problems upstream.



Regards,
Richard
... Just when you think you're winning the rat race along come faster rats!
--- timEd 1.10.y2k+
* Origin: Radio REscue net operations BBS (1:116/901)

Mike Tripp wrote in a message to Paul Lentz:

Maximum message size: 63k (16 bit), 256k (32 bit)

I've been wondering for long time about the message size as well. I
think around the beginning of each month Squish boots out messages (I think in the STATS echo) that are big and renames the .pkt files to
*.LNG.

OS/2 exe (which you may be running?) can be configured to toss as
large as OS/2 has resources to support. 256K is just the largest
Scott Dudley tested with and supported by the canned keyword
"Buffers Large". You have to define buffers manually to go
higher...and have the resources to support them available, of
course. If you want 1gb messages, Squish (SQ386P) can process
them...but maybe your other utils (BBS, online readers, offline
readers) or downlinks can't.

I'm actually running it on a semi-modern Winders98Se machine with like only 256
(or maybe it's 512, can't remember) mego-rams... but I might toy with the buffers statement and see if it does anything else.

IMHO, messages too long for "Buffers Large" were messages I didn't
care to actually read anyway.<g>

The main point is tht I'd like Squish to at least pretend to handle them and not create annoying renamed .LNG files I have to delete by hand from time to time. I know I don't want to read those longy things my own self.

*Paul*
--- timEd/386 1.10.y2k+
* Origin: Dumb Guy's!!! (1:124/5025)

Hello Paul!

19 Mar 08 02:10, Paul Lentz wrote to Mike Tripp:

I'm actually running it on a semi-modern Winders98Se machine with like only 256 (or maybe it's 512, can't remember) mego-rams... but I might
toy with the buffers statement and see if it does anything else.

Scott basically tried to support whatever the environment had to offer...which is why the 16-bit DOS, 32-bit DOS, OS/2, etc. versions as released all had different limits. Don't know about the Win32 flavor, myself, as it was released solo, after the general release of the others...sort of a "So long and
thanks for all the fish", before he left Fido.

The main point is tht I'd like Squish to at least pretend to handle
them and not create annoying renamed .LNG files I have to delete by
hand from time to time. I know I don't want to read those longy things
my own self.

In that case you just need to add the undocumented Winders command "DEL *.LNG" somewhere in your mail processing routine's tossing block.<g> Seriously, if they're breaking Squish, they're probably gonna break something else you're running later once you adjust Squish to pass them further into the food chain.

I've also had good luck negotiating with the originator of the long messages...since it seems that most don't mind folks actually being able to read them. A little whining about the BinkD FAQ got it split down to chunks that DOS GoldEd could swallow at the source. I run the DOS version under DOS, OS/2, and Windows...since it is the only one that will.<g> Before that, I'd have to switch to the OS/2 box and fire up GoldEd/2 just to kill the offending message in order to regain normal access to the area everywhere else.

.\\ike

--- GoldED/2 2.50+
* Origin: -=( The TechnoDrome )=- Austin,TX 512-327-8598 33.6k (1:382/61)

Hello Paul !

On 15-Mar'08 14:48, Paul Lentz wrote to ALL:

Maximum message size: 63k (16 bit), 256k (32 bit)

I've been wondering for long time about the message size as
well. I think around the beginning of each month Squish
boots out messages (I think in the STATS echo) that are big
and renames the .pkt files to *.LNG.

I only got questions, not answers :)

I think I got those limits from the documentation but have never tested them. I've never had *.lng files, or a "stats" echo. I'm not aware that Squish creates statistics in an echoarea. Can you paste the output of that echo ?;

Are you using Squish/386 (32 bit) or Squish (16 bit) ?

I've looked around before and never found any way to deal
with these long messages or the *.lng packet files. Is
there a way to do this?

Maybe get a utility that reads pkt files directly ?

Maybe Amax or Bonk does it, or inbuilt mailer readers.

--- Msged/386 4.30
* Origin: ypan.dyndns.org loves Msged... (3:712/104)

Minh Van Le wrote in a message to Paul Lentz:

Hello Paul !

On 15-Mar'08 14:48, Paul Lentz wrote to ALL:

Maximum message size: 63k (16 bit), 256k (32 bit)

I've been wondering for long time about the message size as
well. I think around the beginning of each month Squish
boots out messages (I think in the STATS echo) that are big
and renames the .pkt files to *.LNG.

I only got questions, not answers :)

I think I got those limits from the documentation but have never
tested them. I've never had *.lng files, or a "stats" echo. I'm not
aware that Squish creates statistics in an echoarea. Can you paste
the output of that echo ?;

The STATS echo is a fidonet echo where somebody periodicaly posts looooong messages about all the echomail traffic. When Squish sees those looooong messages, it skips over them (Because they bust some size limit) and renames the 12345678.PKT file they came in to 12345678.LNG.

There is a utility called SQREPORT.EXE that will work up some stats. It's included in the package and is kinda nice. Here's a small piece of what it spits out...


EchoMail Traffic Report From 1:124/5025
Squish Log Report for 19 MAR 00:04 through 19 MAR 23:51
-------------------------------------------------------

Inbound Messages
----------------
754 Messages from 1:123/500.0
24 Messages from 1:106/1.0
5 Messages from 1:124/1113.0
1 Messages from 1:124/6308.0


Outbound Packets (uncompressed)
-------------------------------
2.12 Megs sent to 1:124/6308
488.65 Kb sent to 1:124/2700
313.61 Kb sent to 1:124/5013
182.14 Kb sent to 1:124/3006
171.76 Kb sent to 1:130/803
158.66 Kb sent to 1:124/1113
144.76 Kb sent to 1:393/11
28.87 Kb sent to 1:123/500
28.08 Kb sent to 1:124/7013

It then spits out traffic by specific echos live/dead, which I won't paste in here cause it can take pages... But I use a thing called carve to turn them into 3 or 4 messages.

Are you using Squish/386 (32 bit) or Squish (16 bit) ?

SQ386.EXE


*Paul*
--- timEd/386 1.10.y2k+
* Origin: Dumb Guy's!!! (1:124/5025)

Paul Lentz wrote in a message to Minh Van Le:

There is a utility called SQREPORT.EXE that will work up some stats.
It's included in the package and is kinda nice. Here's a small piece
of what it spits out...

It then spits out traffic by specific echos live/dead, which I won't
paste in here cause it can take pages... But I use a thing called
carve to turn them into 3 or 4 messages.

OOOPS... I forgot that SQREPORT automagically splits up the ECHO AREA reports into message size files... No CARVE needed.

*Paul*
--- timEd/386 1.10.y2k+
* Origin: Dumb Guy's!!! (1:124/5025)

Hello Paul!

15 Mar 08 14:48, Paul Lentz wrote to ALL:

I've been wondering for long time about the message size as well. I
think around the beginning of each month Squish boots out messages (I think in the STATS echo) that are big and renames the .pkt files to *.LNG.

I've looked around before and never found any way to deal with these
long messages or the *.lng packet files. Is there a way to do this?

I wrote a small utility program in VB4 to dig through the *.lng files and rebuild the packet, splitting the long messages into smaller ones (the size is configurable). Did you say you run Win98? I can run it through the 16 bit compiler if you want to try it out.


Regards,
Fred

--- Msged/NT 6.0.1
* Origin: Somewhere in New Hampshire's White Mountains (1:132/174)

|03Quoting message from |11Fred Riccio |03to |11Paul Lentz
|03on |1120 Mar 08 22:02:04|03.

I wrote a small utility program in VB4 to dig through the *.lng files and rebuild the packet, splitting the long messages into smaller ones (the size configurable). Did you say you run Win98? I can run it through the 16 bit compiler if you want to try it out.

I wouldn't mind a copy of that utility. I run win98 myself here. You can
send it to sysop@gamemasterbbs.darktech.org or marty@atcc.net if you want to do that. If not I will understand.

... I FELT something was wrong. Multitasking causes schizophrenia.

--- Renegade v01-28.8/Alpha
* Origin: gamemasterbbs.darktech.org The GameMaster BBS (1:2320/303)

Hello, Mike...

Mar 19, 2008 at 11:12, Mike Tripp wrote to Paul Lentz:

Scott basically tried to support whatever the environment had to offer...which is why the 16-bit DOS, 32-bit DOS, OS/2, etc. versions
as released all had different limits. Don't know about the Win32
flavor, myself, as it was released solo, after the general release of
the others...sort of a "So long and thanks for all the fish", before
he left Fido.

There's a specific Win32 version of Squish?

Regards,

Jerry Schwartz

mailto:jerryschwartz@comfortable.com
http://www.writebynight.com

--- Msged/NT 6.0.1
* Origin: Write by Night (1:142/928)

Hello Jerry!

01 Apr 08 20:48, Jerry Schwartz wrote to Mike Tripp:

Scott basically tried to support whatever the environment had to
offer...which is why the 16-bit DOS, 32-bit DOS, OS/2, etc.
versions as released all had different limits. Don't know about
the Win32 flavor, myself, as it was released solo, after the
general release of the others...sort of a "So long and thanks for
all the fish", before he left Fido.

There's a specific Win32 version of Squish?

Oops...forgot that "maybe" never materialized. Toldja that would be the flavor I didn't know about.<g>

.\\ike

--- GoldED/2 2.50+
* Origin: -=( The TechnoDrome )=- Austin,TX 512-327-8598 33.6k (1:382/61)