To make life easier for EARN users  who were used to a similar feature in
LISTEARN, version 1.8a introduces support for a new command line keyword,
SPLIT=, which  can be  used when  ordering files  to request  delivery as
multi-part MIME messages with the  specified maximum size (in kilobytes).
Thus  for instance  you could  GET BLAH.ZIP  SPLIT=100 if  you know  your
gateway only supports messages of 100k  or less. LISTSERV will not accept
to cut  files into  pieces of  less than  20k each,  mostly to  avoid bad
surprises if you forget a zero.
 
To  avoid confusion,  it is  important to  note that  SPLIT=nnn is  not a
delivery  format  like  F=NETDATA  or F=MIME/APPL,  but  an  option  that
instructs LISTSERV to further cut the  file in a number of smaller pieces
before sending it  to you, in addition  to whatever else it had  to do to
encode the  file and get it  to you. One  does not order files  "in SPLIT
format", and indeed 'GET SOME.ZIP F=SPLIT'  is not valid. You both select
a format and tell LISTSERV what the maximum message size for your gateway
is (in most cases  you will just type SPLIT=nnn and  let LISTSERV use the
default format, which is "plain mail").
 
The SPLIT=nnn option  is valid only for mail  delivery formats: UUENCODE,
XXENCODE, MIME/TEXT, MIME/APPL and of course MAIL. You cannot use it with
NJE formats such as F=NETDATA because it would make little sense to order
a NETDATA deck in 6 pieces which have to be assembled using PUNCH (NOH in
the right  sequence before you can  RECEIVE the file. At  any rate BITNET
accepts much larger messages  and there is no need to  split NJE files in
segments of 100k in the first place.
 
The MIME  multipart format was  chosen because it is  straightforward and
reasonably  intuitive to  a  human  reader: people  without  a MIME  user
interface are not being sacrificed to a "chosen few". I have attempted to
decode the messages  using an old copy  of MH (V6.7) I  installed about a
year ago  on a  local unix  box and it  claims the  message is  not valid
and/or the last part is missing. I  on the other hand claim the last part
is not  missing and/and the  message is valid,  it just doesn't  have the
"total=" indicator on all  segments, nor does it need to,  nor am I going
to make two passes through the file just to supply it. I would appreciate
feedback on  the ability of current  versions of MIME user  interfaces to
handle the  output of  both 'GET  PEERS NAMES  F=MIME SPLIT=20'  and 'GET
PEERS NAMES SPLIT=20' (I have just installed the code on LISTSERV@SEARN).
 
  Eric