The  following  REXX-callable functions  have  been  selected as  "stable
programming interfaces" for REXX user exits in version 1.8a:
 
  LSVADR   LSVALLOW LSVCC    LSVCD1   LSVDD1   LSVERR   LSVFIF   LSVFILER
  LSVKEYWD LSVLTELL LSVMAIL  LSVPEND  LSVPMV   LSVSR1   LSVTELL  LSVTMAIL
  LSVU@N
 
What this means  is that it is expected that  these functions will remain
available "forever", and  every reasonable attempt will be  made to avoid
making  incompatible   changes  to  their  calling   sequence,  with  the
exceptions  noted below  and with  the understanding  that L-Soft  is not
guaranteeing anything, but  just giving you some advice  based on current
plans. Furthermore these  functions will be made  available to high-level
exit languages in other environments, whenever possible.
 
Exceptions:
 
1. Some of these  functions are VM or REXX specific and  will not be made
   available on other environments unless we  happen to need to port them
   in order to port LISTSERV itself.
 
2. Functions ending  in '1' may contain  temporary programming interfaces
   which  are  needed  for  migration support,  and  will  be  eventually
   removed.  When using  one of  these  functions, you  should check  the
   source  code to  see if  the subfunction  you are  planning to  use is
   likely to be  a temporary interface, and search the  REXX files to see
   how many "customers" there are for the call. For instance, LSVDD1 used
   to have a subfunction call to calculate "type 1" (LISTEARN compatible)
   CRC's,  which someone  might  conceivably have  attempted  to use  for
   purposes unrelated  to LISTEARN  compatibility. The one  routine which
   needed to perform this calculation was rewritten in PASCAL in 1.8a and
   the corresponding LSVDD1 subfunction was removed.
 
The reason working but  obsolete code is removed is that  it would end up
being ported to  other environments otherwise, which would be  a waste of
money. Besides  which, temporary  interfaces usually  contain VM-specific
code which cannot be ported directly.
 
Many of the functions missing from this list are still reasonably stable,
however for  one reason or  another they did  not qualify as  a permanent
programming interface.  For instance, one  of the subfunctions  of LSVDS4
can  be used  to initiate  a new  DISTRIBUTE job.  This would  be a  good
candidate for a permanent interface,  but all the other subfunction codes
are temporary, and it would need  better error checking for a programming
interface. It may be added under another name at a later time.
 
  Eric