WG>> However, I appreciate you pointing out the limits in the
 WG>> older products; I need to make a checklist of "limits to
 WG>> remove". Message size limits are a big one; I firmly believe
 WG>> I should be able to handle messages which are at least half
 WG>> as big as the amount of virtual memory available.

 MT> Keep in mind that the 256K limit is only on the pre-defined
 MT> keyword ("Large") that Scott provided and tested.  If you
 MT> specify the individual numeric parameters manually, SQ386P
 MT> (1.10) is supposedly capable of handling messages until they
 MT> his some OS/2 API limit around 2gb (max size for a single
 MT> file?).

just to toss this into the max message size discussion...

the ^ASPLIT proposal... IMO, it was implemented on the wrong side of the
problem... systems that cannot handle large messages should split those
messages for tossing into their message areas... anyone feeding from that
system should get the original, unsplit message and split it themselves if
needed... the same goes for those QWK doors... they should split the
messages down into what the user's reader can handle...

the current implementation of the ^ASPLIT stuff actually increases the load
on the entire distribution system... the first part of the load is the
actual split processing... the second part of the load is the additional
56bytes of data put on each split part... the third part of the load is
whatever trailing control paragraphs are needed (origin line, seenby lines
and path lines)... there's more, too but i won't go into it right now...

and i'll mention, once again, about the specs for packed messages stating
that the message body is unbounded... ie: no size limit...

)\/(ark