Jack Smith wrote in a message to David Chord:
 JS> Not much, if at all, Dave.  PktSort is extremely fast. 
I'll say!  Here are some snips from its log file:
  02 Feb 21:13:46 PSRT 475 messages were processed in 4 seconds. (118/sec)
  02 Feb 21:33:32 PSRT 63 messages were processed in 1 seconds. (63/sec)
  03 Feb 00:34:52 PSRT 2 messages were processed in 0 seconds.
  03 Feb 00:45:44 PSRT 195 messages were processed in 4 seconds. (48/sec)
  03 Feb 01:12:27 PSRT 297 messages were processed in 3 seconds. (99/sec)
  03 Feb 02:11:23 PSRT 142 messages were processed in 2 seconds. (71/sec)
  03 Feb 06:00:14 PSRT 244 messages were processed in 2 seconds. (122/sec)
  03 Feb 06:13:40 PSRT 330 messages were processed in 2 seconds. (165/sec)
I'd love to see numbers like that with Squish...   :-)
 JS> However, there's a way around that if it concerns you.  You can 
 JS> "look" at the inbound, determine the size of the mail bundle(s) 
 JS> or packet(s) and have PktSort run or not (depending on the 
 JS> size) before Squish tosses.  One can do this easily with 4DOS 
 JS> but four years ago (before I saw 4DOS), I wrote a program 
 JS> called "NetSize" that can compare the size of mail files with a 
 JS> numerical value and exit with an errorlevel which can be 
 JS> trapped in the batch file.  
I use bink's errorlevels 20 and 30 to make that distinction now,  which isn't 
real terrific sometimes when I get largish bunches of email in. 
 JS> You could use this to keep PktSort from running if the mail was 
 JS> under a certain size.  I can f/attach it to your Internet email 
 JS> address if you're interested.  And it's F'Reqable as 
 JS> NSIZE101.ZIP -- 8211 bytes (a real monster :-).
Please feel free to send that along to me,  if you don't mind.  Also feel 
free to hit my fileserv for my list,  if you like.
files: fileserv%tanstaaf@frackit.com
email: roy.j.tellason%tanstaaf@frackit.com 
--- 
---------------