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