From: ERIC@SEARN.BITNET (Eric Thomas)
Newsgroups: bit.listserv.lstsrv-l
Subject: Changes from release 1.7d to 1.7e
Date: 12 Nov 92 02:26:46 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Comments: To: Revised LISTSERV Maintainers <LSTSRV-M@SEARN.BITNET>


         Description of the changes for release 1.7e of LISTSERV
         -------------------------------------------------------
                           November 11th, 1992

**************
* Highlights *
**************

Version 1.7e introduces the following major enhancements:

- Support for the popular VMSDUMP  format, both for incoming and outgoing
  files. BACKUP savesets  can now be stored as native  LISTSERV files and
  conveniently retrieved in VMSDUMP format.

- Support for MIME  (RFC1341) for outgoing files. Internet  users may now
  order text  files via  e-mail without having  to worry  about truncated
  lines or incorrect ASCII to EBCDIC translation.

- LISTSERV internals,  DISTRIBUTE and inter-server  communication methods
  were changed  in preparation for release  2.09 of the VM  mailer, which
  will have the  ability to handle lines longer than  80 bytes. Note that
  it was  unfortunately not  possible to  test this  code in  a realistic
  setup, and further adjustments might thus be needed before LISTSERV can
  actually use that feature of MAILER V2.09.

- Performance  and robustness  improvements  through the  use of  private
  formatting  routines   rather  than   IBM-supplied  commands   for  the
  generation of files  in Netdata and other NJE  delivery formats (except
  CARD DUMP).  This change makes it  possible to use a  SFS directory for
  LISTSERV's work disk (D-disk).

- Additional improvements  have been  made to  the notifications  sent by
  LISTSERV to list owners such that the proposed commands can be executed
  without  retyping  by  simply   forwarding  the  notification  back  to
  LISTSERV.

****************
* Availability *
****************

Release 1.7 is available free of  charge to sites which qualify under one
(or more) of the categories listed below:

a. Members of CREN or one of the CREN Cooperating Networks, excluding:

   1. Members of the European Academic and Research Network (EARN).

   2. Members whose computing facilities are located in an EEC country.

b. Members  of EARN, CREN or  a CREN Cooperating Network  whose computing
   facilities are located in a nordic country (Denmark, Finland, Iceland,
   Norway, Sweden).

c. Members of  EARN whose computing facilities are not  located in an EEC
   country and  which have formally  applied (in writing) for  a license,
   and  complied  with  the appropriate  EARN  directives.  International
   organizations are not  considered as belonging to  the EEC, regardless
   of where their computing facilities are physically located.

Release 1.6 licenses from EEC countries remain valid for release 1.6, but
will not be carried over to release 1.7.

*******************************
* Supported operating systems *
*******************************

Release 1.7  introduces the  following changes to  the list  of supported
operating systems:

- (1.7a) Withdrawal of support for CMS release 3.

- (1.7a) Support for the CP components of VM/SP release 7 and VM/ESA.

- (1.7b) Support for CMS release 7 in both 370 and XA/ESA/XC modes.

- (1.7b)  Support for  the Shared  File System,  with a  few restrictions
  concerning the  setup of  the A  and D-disks  and the  default filepool
  setting. See  the corresponding section  of the 1.7b release  notes for
  more information.

- (1.7c) Support for CMS release 8 in both 370 and XA/ESA/XC modes.

- (1.7e) Support for the Shared File System for the D-disk.

Support for other versions of CP and CMS is unchanged from 1.6e.

**************************
* External Compatibility *
**************************

Release 1.7e is  generally compatible with 1.7d, from  the perspective of
the  end-user (including  list managers  and maintainers),  and with  the
exception  of the  changes listed  below. Release  1.7e introduces  major
changes  to the  LISTSERV  internals, making  compatibility with  locally
developed extensions  or local  modifications problematic.  These changes
are briefly  described in the next  section, and only affect  sites which
made alterations or additions to  the LISTSERV code. Changes which affect
all  LISTSERV sites  are highlighted  below; note  that more  details are
available, when appropriate, from the longer descriptive section of these
release notes.

 1. The changes to support mail items with lines longer than 80 bytes are
    not transparent for  peered lists if some of the  peers are running a
    version  which does  not support  the  long lines.  More details  are
    provided further down.

 2. The  changes to DISTRIBUTE  to support  mail items with  lines longer
    than 80 bytes can cause problems  with LISTEARN and older versions of
    LISTSERV. See further down for more details.

 3. Release 1.7e  internally uses DISTRIBUTE for all  postings to mailing
    lists, in order to avoid having to  duplicate the code that had to be
    added to support  CRC verification of messages with  long lines. When
    "Mail-via= Direct" is specified, a  new internal DISTRIBUTE option is
    used to  prevent the message  from being forwarded to  other servers,
    but the  message is still  formatted and  delivered to the  mailer by
    DISTRIBUTE code. As a result, the SHOW command no longer displays the
    amount of  postings that were processed  through DISTRIBUTE; instead,
    it shows the total amount of recipients.

 4. LISTSERV now removes control characters from mail messages by default
    and  expands tabs  in the  process. Control  characters usually  have
    undesirable and unexpected results, as they seldom survive the double
    ASCII->EBCDIC->ASCII translation  and cause the  recipient's terminal
    to execute  sequences different  from the ones  meant by  the message
    sender  - not  to mention  the case  of ASCII  control characters  on
    EBCDIC  terminals.  Furthermore,   certain  combinations  of  control
    characters  were found  to create  problems with  IBM's SMTP  (due to
    unexpected CRLF sequences  appearing in the middle of  a record after
    translation).  Lists  which  absolutely  require  control  characters
    must have a "Translate= No" keyword added to their header.

Release 1.7e is  to be installed directly  on top of the  base 1.7d code,
and includes all the fixes available from LISTSERV@SEARN for release 1.7d
(ie  all  the "17Dnnnt  FIX"  files  from  filelist "LFIXES"),  with  the
exception of those containing replacement "recommended user exits", which
always have to be installed manually.

**************************
* Internal Compatibility *
**************************

Major changes  have been made  to LISTSERV internals. The  most important
ones are briefly described below; refer to the LSTSRV-L archives for more
information.

 1. FFORMAT/FCLASS  information is no  longer kept in  GLOBALV variables,
    and must be accessed/changed via calls to LSVCD1.

 2. LSVRECV no longer forces the filemode to D if a value was specified.

 3. The  UUENCODE and  LISTSERV-Punch file  formats are  now provided  by
    built-in LISTSERV code rather than  standalone MODULE's. As a result,
    PDUTIL,  LSVPUNCH  and LSV$UUE  will  be  automatically erased  after
    installation of 1.7e. If you  have local applications which depend on
    them, make a copy before  installing 1.7e. Furthermore, the format of
    SYSFF FILE has changed; if you had installed new file formats on your
    server, you will need to make  a few adjustments. See the comments in
    SYSFF FILE for more information.

 4. Authors of local command packages  should note that LISTSERV does not
    guarantee that the program stack is  in any particular state when the
    command  processor is  invoked. MAKEBUF  and DROPBUF  should be  used
    wherever necessary.

The following REXX files have been converted to PREXX with release 1.7e:

   LSV$UUE   LSVMAIL   LSVSENDF  MIG_*

The following MODULE files have become obsolete with release 1.7e:

   LSVPUNCH  PDUTIL

**************************
* Compatibility Warnings *
**************************

This new section describes planned changes which may affect compatibility
(both external and internal). The release  in which the change is planned
to be  introduced is indicated, with  the letter 'x' denoting  an unknown
release of the specified major  version (not necessarily posterior to the
last release  explicitly mentioned).  Note that  conversion of  more REXX
files to PREXX is assumed to take  place with each new release and is not
indicated here.

- (1.7x) The internal format of  FILELIST/FILEID and attendant files such
  as AFDLIST FILE will change dramatically. Applications which alter them
  directly will no longer work.

- (1.7x) The internal  format of LIST and attendant  files (CACHE, STATS,
  et al) will change dramatically. Applications which alter them directly
  will no longer work.

- (1.7x)  LSVDIAD4,  LSVFRD1, LSVFWR1  and  RXLSVUHF  will be  eventually
  removed. You should avoid using them.

********************************
* Minor fixes and enhancements *
********************************

REMINDER: Manual installation  is not supported for release  1.7, and the
code that  implemented it has  been removed with version  1.7e. Automatic
installation with local  password validation must be  used instead. Sites
which insist on installing manually should note that shipments contain an
installation pre- and post-processing exit. If that exit is not executed,
or if  it is  executed in  a different order  or environment  than during
automatic installation, serious problems may occur.

This  section contains  a brief  description of  all the  "small yet  not
unimportant worries" that have been fixed in release 1.7e, along with the
affected  releases, if  known ("All"  meaning "any  release in  which the
facility  is  available", ie  the  problem  was  present since  the  very
beginning).

Minor enhancements which  do not warrant a detailed  description are also
included; they  are all  located at the  bottom of the  list, and  can be
identified by the word "New" in the "Affected releases" column.

Affected
releases    Description of the bug, problem or enhancement
--------    ----------------------------------------------
  1.7d      Servers running  on VM/SP or VM/HPO  were occasionally unable
            to purge incoming job files  if a severe error occured during
            processing;  the job  would be  reprocessed about  15 minutes
            later and cause multiple error notifications.

  1.7d      LISTSERV will no longer generate addresses of the form:

                  From: "(Joe Smith)" <JSMITH@Somewhere.EDU>

            These  addresses were  not  generated  intentionally and  are
            unnecessarily complex,  but they  are perfectly  valid. There
            exist  popular mail  programs which  cannot handle  them, but
            that only means they are in error.

  1.7a      The recipients counts for network-wide lists produced by LIST
            SUMMARY were  incorrectly calculated. The totals  reported by
            pre-1.7e code happened to be lower than the correct values at
            the time the fix was written.

  All       Some components  of LISTSERV were  unable to append  to files
            with more than  64k records, due to  the unexpected behaviour
            of FSWRITE with RECNO=0 but without FORM=E.

  New       Plural forms  ('Owners' and 'Editors') are  now supported for
            access-level keywords, with the  same meaning as the singular
            forms.

  New       JOIN and LEAVE are now accepted as synonyms for SUBSCRIBE and
            SIGNOFF, respectively, in order to improve compatibility with
            Mailbase.  Mailbase  appears  to   be  the  most  robust  and
            comprehensive  unix-based list  manager currently  available,
            with  the  added advantage  of  not  confusing the  users  by
            claiming to  be a  unix version of  the BITNET  LISTSERV. The
            addition  of  these two  synonyms  will  hopefully remove  an
            obstacle to the use of Mailbase by a larger community.

  New       In order  to make  it easier to  implement "sub-lists"  (a la
            Mailbase) with  LISTSERV, the  syntax of  the "Subscription="
            keyword   has  been   enhanced   to  support   access-control
            specifications,  in  addition  to  the  previously  supported
            keywords ("Open", "Closed" and  "By_Owner"). Sub-lists can be
            convenient when  a rather large  forum is to  discuss several
            sub-topics in  parallel and  participants are  to be  free to
            join and  leave the various  sub-lists as they see  fit. This
            change  makes  it  possible   to  implement  sub-lists  where
            membership is not open.

  New       A side-effect  of the previous change  is that "Subscription=
            Public" is  now a synonym for  "Subscription= Open", removing
            one of the most common mistakes made by new list owners.

  New       LISTSERV no longer needs to swap its work minidisk (192) from
            mode D  to mode Z  and back. This  makes it possible  for the
            work disk to be replaced with a SFS directory, as long as you
            make sure  the directory  is already accessed  R/W as  mode D
            when  LISTSERV  is  started.  Mode  Z  remains  reserved  for
            LISTSERV use (dynamic minidisks, et al).

*******************************************************
* Usability/Performance: Support for new file formats *
*******************************************************

Release 1.7e introduces  support for a number of new  file formats, which
can be  specified on the  'F=' keyword of  commands such as  GET, REVIEW,
etc.

- VMSDUMP, the popular file transfer format for VMS systems running JNET.
  LISTSERV  only  supports  sequential  files. For  incoming  files,  the
  variable portion of  VFC files (usually a time stamp)  is discarded and
  UNDEFINED files are  not supported (but the other 3  stream types are).
  For outgoing  files, LISTSERV only  generates FIXED or  VARIABLE files.
  This  is still  sufficient  to conveniently  store  BACKUP savesets  as
  native LISTSERV files.

- XXENCODE, a version  of UUENCODE modified to use a  more sensible table
  so that the resulting messages survive ASCII to EBCDIC translation.

- Two flavours of MIME base64-encoded messages. Users with a MIME-capable
  user  interface can  use 'F=MIME'  to  order text  files which  contain
  characters that  do not survive  ASCII to EBCDIC translation,  or lines
  longer than the  gateways in the way will  support. LISTSERV translates
  the  text to  ASCII, adds  CRLF sequences,  and sends  the result  as a
  base64-encoded message  of type 'text/appl'. 'F=MIME/APPL'  can be used
  as a  replacement for  UUENCODE to order  binary stream  files (content
  type 'application/octet-stream'). It is important to note that this has
  exactly the  same functionality  as UUENCODE: the  input file  is read,
  ignoring  file attributes  and  record boundaries,  and  turned into  a
  stream of bytes, which are then  encoded and sent. In other words, this
  is not  a suitable method for  transferring text files on  binary VM or
  VMS files.

In addition, release 1.7e no longer uses the IBM-supplied system commands
to generate  files in Netdata and  other formats - with  the exception of
CARD DUMP  format, for which a  modified version of CARD  MODULE is used.
This change improves robustness, performance, and considerably simplifies
functions such as AFD and GET which no longer need to copy files and swap
the work disk around in order to have the right information in the header
or to avoid unwanted side effects of the system commands. The new code is
about 3-4 times faster for both Netdata and DISK DUMP formats.

***************************************************************
* Usability: Support for mail with lines longer than 80 bytes *
***************************************************************

LISTSERV  internals  and  inter-server communication  methods  have  been
changed to support  mail with lines longer than 80  bytes, in preparation
for a new version of the VM mailer with support for Netdata format. There
is no  way to make use  of that support  with the current version  of the
mailer (2.08) and it is perfectly  normal that lines continue to be split
at column 80 after the installation of 1.7e.

These changes introduce a number of problems when communication has to go
through servers not running 1.7e.  Three major components of LISTSERV are
impacted:

1. Inter-server commands: older servers  (including LISTEARN) are able to
   process the new  commands without problem. However,  in certain cases,
   they may  truncate the command if  they, in turn, need  to forward the
   request to other servers. In practice this only affects unlikely cases
   such as e-mail  addresses longer than 80 bytes (the  command itself is
   never  truncated,  but list  of  addresses  passed  in DD's  might  be
   truncated at column 80).

2. Peered lists: a problem will occur if a message with lines longer than
   80 bytes  is posted to  a peered  list and some  of the peers  are not
   running  version 1.7e.  The  message  would be  truncated  as per  the
   following table:

            +---------+-------------------+-----------------+
            | Version | Header truncated  |  Body truncated |
            +---------+-------------------+-----------------+
            |   1.7e  |     Never (*)     |    Never (*)    |
            +---------+-------------------+-----------------+
            |   1.7d  |   Folded at 80    | Truncated at 80 |
            +---------+-------------------+-----------------+
            |  Other  | Truncated at 255, | Truncated at 80 |
            |         | then folded at 80 |                 |
            +---------+-------------------+-----------------+

   (*) If the  local mailer does not support lines  longer than 80 bytes,
       the headers and body will have to be folded at column 80.

   The truncation of the message  text is obviously undesirable, but will
   only happen  if there  were lines  longer than 80  bytes in  the first
   place;  in other  words,  it is  not  an issue  until  mailer 2.09  is
   released. From then on peered lists  will require that all servers run
   release 1.7e.  A temporary keyword,  "Long-lines= No", is  provided to
   assist migration  in cases  where one of  the peers  absolutely cannot
   install 1.7e in time (note that peered LISTSERV-LISTEARN lists are not
   formally supported, but  can benefit from that migration  aid while it
   is being provided). When "Long-lines= No" is specified, LISTSERV folds
   text lines longer than 80 bytes  to bypass this problem at the expense
   of usability.

   The truncation of header lines at  column 255 is potententially a very
   serious problems. Long  header lines may be present  regardless of the
   version of the  mailer being used, as LISTSERV  must internally unfold
   RFC822 fields in order to process them and does not re-fold them until
   necessary  (and since  inter-server jobs  support lines  of up  to 64k
   bytes,  it never  turns out  to be  necessary). Although  header lines
   longer than 255 are rare, this  new mechanism can create problems with
   peered lists unless  all the peers run 1.7d or  1.7e. Because there is
   no problem with the previous version  and older versions are no longer
   supported, no migration aid was provided.

3. DISTRIBUTE: LISTSERV  now uses Netdata format for  DISTRIBUTE jobs, so
   that long mail  lines (up to 64k  and thus well beyond  the 1000 bytes
   SMTP standard)  can be  supported. While  older servers  are perfectly
   capable of  processing such jobs,  the same truncation problems  as in
   point 2 exist. Fortunately, version  1.7e is being released before the
   new VM mailer and it should be possible to remove the few non-LISTEARN
   sites which are  still running 1.7d from the backbone  when the mailer
   is  released, thus  solving the  problem for  non-LISTEARN sites.  The
   structure of  the LISTSERV backbone  in Europe is such  that countries
   running LISTSERV will seldom be affected by truncation due to LISTEARN
   sites, so  this is fortunately  a private LISTEARN problem  which will
   have to be solved separately.

IMPORTANT:  The use  of  Netdata for  DISTRIBUTE  will cause  significant
performance problems  to sites running  a version older than  1.7d. There
will be  a noticeable impact for  1.7c sites and  a factor of 2  or worse
degradation for  1.7b and older.  The impact of  this change on  1.7d and
1.7e sites is negligible, and, for  1.7e, it is more than compensated for
by other performance changes to DISTRIBUTE.

*********************************************************************
* Usability: Enhanced subject on administrative mail to list owners *
*********************************************************************

In order to  make it easier for  list owners to process  large amounts of
administrative mail from LISTSERV, the 'Subject:' field of these messages
has been modified as follows:

<1.7c> Delivery error notice sent to list XYZ-L
<1.7d> XYZ-L: error report from sun3.abc.edu

<1.7c> New subscription to list XYZ-L
<1.7d> XYZ-L: Joe@VAX3.ABC.EDU joined the list

<1.7c> User signing off the XYZ-L list
<1.7d> XYZ-L: Joe@VAX3.ABC.EDU left the list

This  makes it  possible  for  experienced list  owners  to process  most
messages without having to actually read the message text, without making
any difference to inexperienced owners.

*************************************************************
* Usability/Performance: Enhancements to the REVIEW command *
*************************************************************

The REVIEW  command has been  partly rewritten  in PREXX and  enhanced to
allow  the user  to indicate  how  he wants  the subscribers  list to  be
sorted. This  is accomplished through a  new option, 'BY', which  must be
followed by one  of the following field names  (minimum abbreviations are
shown in upper case, as usual):

- 'Name': sort  by subscriber name.  LISTSERV uses some heuristics  in an
  attempt to  separate the  first name  and last  name from  any possible
  organization name,  title or  affiliation, and sorts  the list  by last
  name, then  first name. There are  of course cases where  this does not
  have the expected effect.

- 'NODEid' or  'Hostname': sort  by nodeid/hostname  (whatever is  to the
  right of the '@' sign in the subscriber's address - the two options are
  synonyms).

- 'Userid/USERName': sort  by username (the part  to the left of  the '@'
  sign).

- 'Country/ies':  sort by  country  of origin  and  produce a  statistics
  summary listing  the various  countries encountered  and the  number of
  subscribers in  each country. Note that  the list is sorted  by country
  name (Switzerland),  and not by  country code (CH). Sorting  by country
  causes comments with the country names  to be inserted in the list (see
  example  below), since  it would  otherwise be  difficult to  associate
  country names  with e-mail addresses.  Because of this  difficulty, you
  may  not use  the country  name  as a  secondary sort  field; that  is,
  'REVIEW XYZ-L  (BY (COUNTRY  NAME)' is valid,  but 'BY  (NAME COUNTRY)'
  would be rejected.

---------- Example of comments inserted for the COUNTRY option ----------
* Netherlands:
SOND0008@HASARA11                 peter vons
U001222@HEARN                     Jos Wennmacker
EVERS@HUTRUU53                    Evert Jan Evers / Univ. Utrecht, NL
* Spain:
ZCOCBF01@EBCESCA1                 Cristina Blanxer
* Sweden:
ERIC@SEARN                        Eric Thomas
-------------------------------------------------------------------------

The default sort fields are  'BY (HOSTNAME USERNAME)', for compatibility.
Unless requested otherwise, entries with  the same primary field are then
sorted by  hostname/username to ensure  results are predictable  (ie that
reviewing the same list twice with the same options always gives the same
results).

Finally, the old COUNTRY options (as in 'REVIEW XYZ-L (COUNTRY') is now a
synonym for 'BY  COUNTRY'. There is no way to  get the country statistics
report without also ordering the subscribers list by country name.

***************************************************************
* Usability: Changed 'Reply-To:' field on administrative mail *
***************************************************************

Most admnistrative  messages sent  by LISTSERV  to end  users now  have a
'Reply-To:'  field pointing  to 'LISTNAME-request@LOCALNODE',  an address
which LISTSERV expects to point to  the list owners (see next paragraph).
This prevents  hasty users  from inadvertently  replying to  the LISTSERV
userid, only to discover that the long  letter they had not saved as been
processed as a set of commands and discarded.

In order for the address in question to work as advertised, you must have
the automatic  owner-/-request support installed  in your mailer.  If you
are running  version 2.08  of the  VM mailer, you  can get  the necessary
changes from  LISTSERV@SEARN; please refer  to the description  posted to
the LSTSRV-L archives on 26 Nov 1991 for more details. If you are running
version 2.09  or higher, it should  be possible for you  to activate this
function  simply  by setting  a  configuration  variable; the  syntax  is
unknown at the time of this writing, as 2.09 was not yet available.

*****************************************************************
* Performance/Reliability: Internal incoming spool file decoder *
*****************************************************************

In order to  improve performance when processing incoming  spool files in
Netdata format, which might become the norm rather than the exception due
to planned  changes to the VM  mailer, and to decrease  the dependence on
unexpected  changes to  standard VM  commands, LISTSERV  now has  its own
internal decoder for incoming spool files. This decoder accepts the three
major formats (Netdata, DISK and CARD), plus of course "raw" PUNCH files.
It is considerably  faster than native commands, except  for CARD format,
but even then  performance is better since  the data does not  need to be
staged through a disk file.

Noteworthy points:

1. You may now submit jobs to LISTSERV in CARD format. Previous versions
   did not support CARD for input files.

2. With  CARD and  DISK  formats, only  the  first file  in  the deck  is
   extracted  and  processed. As  mentioned  in  previous release  notes,
   LISTSERV does not accept multiple jobs per spool file because it would
   not  be  able   to  properly  checkpoint  them.   Jobs  are  generally
   transferred to the postmaster for manual examination and retry in case
   of severe failure, and this requires  each job to reside in a separate
   file.

3. LISTSERV does  not support the pre-VM/SP (1970's) version  of the DISK
   format.  While there  is no  VM/370 system  on BITNET,  some very  old
   emulator software might still use this ancient format.

*************************************************************************
* Usability: Automatic conversion of DISTRIBUTE to mail-only recipients *
*************************************************************************

The addition of the internal spool  file decoder has made it possible for
LISTSERV to automatically convert DISTRIBUTE FILE jobs to plain text when
the recipient is only reachable via mail.

Scenario: a user sends  a file to a list without a  mail envelope (ie via
SENDFILE, SEND/FILE or equivalent), because  the file is large or because
he does  not want  it logged to  the archives. The  typical example  is a
large  postscript file  which may  need to  be revised  and resent  a few
times. Unfortunately,  some of the  recipients do not have  BITNET access
and can be reached only via mail.

Former  behaviour:  LISTSERV  encapsulates  the NJE  file  in  an  RFC822
envelope and delivers it to the mail-only  users. If the file was sent in
an encoded format such as Netdata or DISK DUMP, the data in question will
contain binary characters  which will not survive delivery.  In any case,
the recipient is unlikely to have software that can decode such files.

New behaviour:  LISTSERV examines the  first record  of the NJE  file and
realizes that it contains binary characters. It runs the file through its
internal decoder and  gets a successful return code,  confirming that the
file  was indeed  in  a supported  network format  (see  note on  VMSDUMP
below). LISTSERV sends the decoded text to the recipients, along with the
following message:

----------------------- Message sent to recipient -----------------------
Note: conversion from a BITNET  transmission format not suitable for mail
delivery was  locally attempted.  This type  of conversion  may sometimes
require "choices"  to be  made by  the conversion  program, based  on the
(lack  of) support  for  various  file formats  on  the target  operating
system. The "choices" made by LISTSERV  may not be the ones you expected,
since it does not know anything  about the system you are using. However,
you would not  have been able to use  the file at all if it  had not been
converted. If you have trouble using  the file as you received it, please
contact the  person who  sent it  and arrange  for an  alternate delivery
method.
-------------------------------------------------------------------------

Important remarks:

1. LISTSERV  can only decode  the formats it understands.  In particular,
   VMSDUMP format  and some types  of Netdata files originating  from MVS
   systems cannot be decoded. In  such cases, behaviour is unchanged from
   the previous versions.  Note that VMSDUMP is a  proprietary format for
   which no specifications are available.

2. The decoded file  might still be unusable if it  was, for instance, an
   executable file.  LISTSERV attempts  the conversion on  the assumption
   that binary characters  do not survive ASCII to  EBCDIC translation in
   mail gateways  anyway, thus there  is a choice between  something that
   might work and something that assuredly will not work.

3. The  server that  converts the  file is the  server that  performs the
   final  delivery to  the user.  Backbone servers  which relay  the file
   onwards  do not  examine the  delivery lists  of other  servers. Thus,
   submitting a job to a 1.7d server is no guarantee that conversion will
   take  place for  all  recipients;  it is  the  version  of the  server
   delivering to the recipient that matters.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU