Description of the changes for release 1.8b of LISTSERV(TM) ----------------------------------------------------------- Copyright 1995 L-Soft international, Inc. May 8th, 1995 ************************************************************************* ********************** LISTSERV maintainer's notes ********************** ************************************************************************* The release notes for version 1.8b of LISTSERV(TM) have been split into three documents: executive notes, list owner's notes, and LISTSERV maintainer's notes. The present LISTSERV maintainer's notes describe changes that are specific to server or host machine configuration, or too technical to be included in the list owner's notes. LISTSERV maintainers should also read the owners' notes. Note to non-VM customers: the present release notes describe all the changes from the date of release of version 1.8a (7 Dec 93). Because the first VMS(TM) and unix(R) versions of LISTSERV were released in June 94, the improvements made during the first half of 1994 were already included in the code released as "1.8a" for non-VM systems. Similarly, due to the release date of the Windows NT(TM) version, very few of the changes in these release notes will be new to Windows NT(TM) customers. ************** * Highlights * ************** - (VM) New option to reduce or remove dependence on BITNET core infrastructure. - (VM) XA/ESA/XC exploitation for large workloads. - (non-VM) List exits and local commands now available for non-VM systems. - Significant performance improvements for large workloads and large lists, even on the regular (non High Performance) version. Large VM sites reported a performance improvement of a factor of 2-2.5, as compared to version 1.8a. - (VMS/NT) "SMTP workers" feature to support the forwarding of large delivery workloads to unix(R) delivery systems. ************************************************************************* **** IMPORTANT: LICENSE KEY NOW REQUIRED FOR LISTSERV-TCP/IP FOR VM ***** ************************************************************************* The LISTSERV-TCP/IP product for VM now requires a License Activation Key (LAK). If you are running LISTSERV-TCP/IP for VM, you should have received a LAK with installation instructions under separate cover. If you did not receive this license key, please contact SALES@LSOFT.COM at your earliest convenience. LISTSERV-NJE users are not affected. Because version 1.8a of LISTSERV-TCP/IP for VM does not require or support license keys, you will not be able to check the proper installation of your license key before upgrading. Version 1.8a will let you create the LICENSE MERGE file, but will ignore it completely. To facilitate the transition, the 1.8b update will work without a license key until July 1, 1995. Once version 1.8b is installed, use the SHOW LICENSE command to verify that the key has been properly loaded. If you see a license key with your organization name in the serial number, everything is in order. If the reply is "No license information is available for this server", the LAK was not properly installed. This change was necessary to introduce graduated and other limited capacity licenses for VM, and the new LISTSERV High Performance product (also known as "LISTSERV-HPO"). This also makes it possible for us to place evaluation copies for the VM product on our anonymous FTP server. The LISTSERV-NJE product is not affected because it has been withdrawn from marketing, that is, we no longer sell it to new customers. This makes it unnecessary to introduce these new licensing options and thus license keys. ************************** * External Compatibility * ************************** Release 1.8b is generally compatible with 1.8a, from the perspective of the end-user (including list managers and maintainers), and with the exception of the changes listed below. Release 1.8b introduces major changes to 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. A number of changes to list keyword and system configuration defaults were made in order to facilitate the migration from NJE to the Internet. Technically, some of these changes are incompatible, although in practice user impact should be minimal. Refer to the list owner's notes for more information. 2. The ADDREQ1 mail template ("User requested to join list") is no longer cc:-ed to the user, and only goes to the list owners. This change was introduced to prevent confusion and is described in the list owner's notes. 3. To reflect the fact that the so-called "RFC822" header styles (named after the old XMAILER version 1 exit by the same name) are now totally obsolete, the SHORTHDR/FULLHDR options were renamed to SHORT822/FULL822 while SHORTHDR/FULLHDR became a synonym for SHORTBSMTP/FULLBSMTP. All references to the xxxBSMTP header styles may be removed in a future version of the documentation, although this syntax will continue to be supported. Note that the "BSMTP" style headers are also RFC822 compliant; the naming is purely historical, and "BSMTP" style headers were already the default in version 1.8a. See the list owner's notes for more information. Release 1.8b is to be installed directly on top of the base 1.8a code, and includes all kwown fixes as of the build date. IMPORTANT: unix(R) customers should retrieve BOTH common.tar.Z and `uname`.tar.Z, and use the 'make update' stage to update their system. ************************** * 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. The contents of the SIGNUP2 FILE have been spread over a number of files called SIGNUP FILEnnn. Programs which read or update SIGNUP2 FILE directly (which has never been a supported operation) will need to be modified. 2. (VM) As indicated in the version 1.8a release notes, the version 1.7 mail template processor, LSVIMAIL, is no longer present in version 1.8b. If you are running the optional LMON monitor and did not refresh it when version 1.8a was released, you will need to do so before installing 1.8b. If in doubt, look for calls to LSVIMAIL in LSV$LMN* EXEC. If none is present, you do not need to update LMON. 3. The format of columns 81-100 of the LIST file had to be changed to permit the introduction of new options. The old format is still accepted as input and entries are not converted to the new format until they are modified, to minimize disruption in case you should be forced to fall back to 1.8a. See the list owner's notes for more information on this change. 4. (VM) By default, LISTSERV will no longer use the INTERBIT service and will minimize its reliance on the BITNET core infrastructure. See the description of the USE_NJE option for more information. (VM) The following REXX files have become obsolete with release 1.8b and are deleted during migration: LSVEXPIR LSVIMAIL LSVLDELT LSVLIST LSVLUPD LSVPW LSVREV LSVRMAIL LSVSTL LSVSUPD LSVXMAIL LSVPUTL (VM) The following files have become obsolete with release 1.8b: PEERS NAMESUM PEERS SERVSUM ************************** * Compatibility Warnings * ************************** This 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 REXX files to PREXX is assumed to take place with each new release and is not indicated here. - (1.8x) The data currently in AFDLIST and FUILIST FILE will be moved to the signup files. - (1.8x) The internal format of FILELIST/FILEID will change dramatically. Applications which alter them directly will no longer work. - (1.8x) The internal format of LIST and STATS files will change dramatically. Applications which alter them directly will no longer work. - (1.8x/VM) LSVFRD1 and LSVFWR1 will be removed eventually. You should avoid using these utilities. ************************************************************************ * (VM) Performance: USE_NJE option to remove dependence on BITNET core * ************************************************************************ Traditionally, the LISTSERV-NJE servers for VM have relied heavily on the BITNET core infrastructure for their everyday operation. BITNET is the environment in which LISTSERV was originally developed and, while there is now a TCP/IP version of LISTSERV for VM, many BITNET sites have decided to phase out their VM systems and are thus unwilling to invest in mainframe software. In many cases, the long term strategy is to migrate to the unix(R), VMS(TM) or Windows NT(TM) version of LISTSERV, and to keep the service on the VM system in the short term, until the overall mainframe migration plan (of which LISTSERV is but one item) is finalized and ready to be implemented. The USE_NJE option was developed partly to address the business needs of these "temporary" VM customers, and partly to provide some urgently needed short term relief to the BITNET core infrastructure. For a technical background on BITNET, INTERBIT, and the core overload problems, please refer to the LSTSRV-M and LSTOWN-L archives, and in particular to the messages posted in February 1995. Only a brief description will be provided here. The BITNET network is organized as a number of interconnected "regions", with each region having one or two "core nodes", running VM and (usually) LISTSERV. The core sites are universities, which donate resources on a local mainframe system for the operation of BITNET. The core nodes carry the bulk of the BITNET traffic, and most of them are currently overloaded. To illustrate the problem, here are some figures from the largest core INTERBIT node, UGA. In October 1994, UGA was processing an average of 585,945 deliveries a day (flat monthly average). In February 1995, UGA was up to 746,998/day, and it broke the 1M mark in whole-week average deliveries for the first time in the first week of May 1995 (Mon-Sun), with 1,090,145/day. This represents an 86% increase in just 6 months, which extrapolates to a factor of 3.5 per year. Looking only at the last 3 months, the increase was 46%, which extrapolates to a factor of 4.5 per year: clearly, the situation is not getting any better with time. The INTERBIT systems are overloaded because they are all mainframes, and mainframes simply do not get upgraded at these rates in the academic world. These machines need relief urgently. Concretely, this problem translates to longer delivery times for BITNET sites that depend on the core services. This is where the new USE_NJE option comes into play. This option lets LISTSERV-NJE sites control just how much they want to rely on the BITNET infrastructure, from "use BITNET all the time" to "don't use BITNET unless there is positively no other option". By default, version 1.8b will use BITNET only when it seems appropriate (see below for more details). This corresponds to the USE_NJE = 0 setting. To modify this default behaviour, simply edit LOCAL SYSVARS, add the appropriate definition, and reboot the server. Here are the three possible settings and their exact meaning: - USE_NJE = 1: This is the 1.8a compatibility mode. LISTSERV will use the NJE network whenever possible, may use the INTERBIT service depending on other configuration settings, and treats LISTSERV-NJE servers as full peers. Because RSCS deliveries are less resource intensive than SMTP deliveries, and because of the possible use of the INTERBIT service as a means to offload the bulk of the SMTP deliveries onto another system, this mode minimizes local resource consumption. However, it relies heavily on the overloaded BITNET infrastructure. This mode is provided for compatibility only and is not recommended, except for the core sites that simply may not have the extra capacity to switch to one of the other modes at this time. - USE_NJE = 0: This is the default value, which strikes a compromise between conserving local resources and decreasing reliance on the BITNET infrastructure. In this mode, LISTSERV will never use the INTERBIT service, and will use the Internet to deliver mail to BITNET users that are also reachable via the Internet (provided, of course, that the BITNET<->Internet mapping has been properly registered in BITEARN NODES - LISTSERV cannot "guess" the Internet hostname of BITNET sites that have not registered it). Generally speaking, with USE_NJE = 0 LISTSERV will shift traffic to the Internet where it makes the most sense, reducing but not altogether eliminating NJE traffic. - USE_NJE = -1: In this mode, LISTSERV assumes that the BITNET infrastructure has collapsed, and uses the Internet in all cases except where technically impossible. All LISTSERV-NJE servers are treated as "second class" DISTRIBUTE relays unless explicitly configured otherwise, and will only receive traffic destined to their own service area (and the corresponding jobs will still be sent via the Internet). The second class relays will not be requested to redistribute to downstream DISTRIBUTE servers. LISTSERV-TCP/IP servers will continue to be treated as full peers, as they should. When using USE_NJE = 0 or USE_NJE = -1, remember that LISTSERV is not a MTA and has no direct control over the routing of the messages it sends. All it can do is write to JOE@XYZ.EDU as opposed to JOE@XYZVM1.BITNET. If the MTA subsequently decides to route XYZ.EDU via BITNET, you will still be relying on BITNET. If your MTA is LMail, you can disable this kind of routing by doing the following: 1. Add "USE_DOMAIN_NAMES = 0" (without the quotes) to LOCAL SYSVARS on MAILER 191. 2. Edit DOMAIN OVERRIDE and make sure there is a DEFAULT: line pointing to your local SMTP server. Type FILE anyway to update the file's date and force a table rebuild. 3. Restart LMail. This change will cause all deliveries to Internet addresses to be made by your local SMTP server, without using BITNET. ************************************************ * Usability: Organization name in 'From:' line * ************************************************ While minor, this change is being documented in a "high visibility" section because it is expected that most sites will want to take advantage of it. Version 1.8a of LISTSERV-NJE generated "From:" fields of the form: From: BITNET list server at SEARN (1.8a) As part of the development of the TCP/IP version of LISTSERV, this heading was changed to: From: "L-Soft list server at SEARN (1.8b)" ^^^^^ The underlined part (NJE nodeid for LISTSERV-NJE, full hostname for LISTSERV-TCP/IP) can be altered by defining a MYHOST configuration variable. For instance, MYHOST = 'XYZ University' produces the following heading: From: "L-Soft list server at XYZ University (1.8b)" *********************************************************************** * Usability: Alternate $SITE$ MAILTPL for dual administrative notices * *********************************************************************** In some cases, it may be necessary for the LISTSERV maintainer to ensure that all subscribers receive certain information or warnings (typically legal notices required by government regulations) when they leave or join a list. The list owner should not be able to disable these warnings, accidentally or otherwise. The new $SITE$ MAILTPL file provides this functionality. If a $SITE$ MAILTPL file is present in LISTSERV's main directory (the one with DEFAULT MAILTPL), LISTSERV will look it up every time it needs to deliver an administrative message. If the message is not found in the site template, LISTSERV will process the request normally, looking up the list template file, then the language template file and finally the system template file. If the message is listed in the site template, LISTSERV will deliver BOTH the copy in the site template and the copy in the list/language/system template. ************************************** * (VMS/NT) Performance: SMTP workers * ************************************** Because Windows NT(TM) does not have any native support for SMTP, L-Soft had to develop a robust, efficient mechanism allowing Windows NT(TM) systems to forward large amounts of mail to a delivery machine not necessarily located on the same LAN. The standard outgoing LISTSERV mail interface was judged inadequate, because it would tie up the LISTSERV process in case of network failure, and because, having been designed to interface to the mail system on the LISTSERV host, it would not scale up well when connecting to a remote delivery machine over a possibly overloaded link. The result of this development was called "SMTP workers". The "workers" are processes which deliver mail asynchronously under LISTSERV's control. You can create any number of workers, as long as your hardware is able to support them, and they may be configured to talk to any number of host/port combinations. The workers can be used to increase throughput, to provide load sharing, or simply for redundancy. If one of the remote machines should become unreachable, the workers will still be able to send the mail through the other machines they are configured to talk to. The worker code was later ported to VMS(TM), as some VMS(TM) customers found it advantageous to forward all their outbound mail to a remote unix(R) system, and the port from Windows NT(TM) was very easy given the similarity between the two systems. At the time, the LSMTP(TM) development was a long way from completion, and we were not in a position to offer a better alternative, even as a prototype. Nevertheless, the SMTP workers constitute an improvement over the standard outgoing interface for VMS(TM), and are now bundled with version 1.8b (at no extra charge). Note that, by default, LISTSERV will continue to use the old outgoing interface until reconfigured. L-Soft recommends enabling the workers on VMS(TM) systems, especially on older systems with slow disks (MV3x00, etc). To enable the SMTP workers, simply follow the instructions in the Windows NT(TM) installation program or in the VMSINSTAL kit, respectively, and select "Asynchronous delivery mode" (or similar wording), then configure the host(s) that you want the workers to talk to. L-Soft recommends using a minimum of 2 workers if you are concerned about redundancy. ***************************************************** * (non-VM) Usability: List exits for non-VM systems * ***************************************************** ------------------------------------------------------------------------- Background for non-technical users: an "exit" is a program supplied by the customer to modify the behaviour of a product (such as LISTSERV) in ways that the supplier of the product could not anticipate, or could not afford to support via standard commands or options. The product checks for the presence of the "exit" program and calls it on a number of occasions, called "exit points". In some cases, the "exit" program supplies an answer ("return code") to the main program, which adjusts its behaviour accordingly. For instance, LISTSERV may ask an exit program "Is it ok to add JOE@XYZ.EDU to the ABC-L list?", and the program will answer yes or no, and possibly send a message to the user explaining why his subscription was accepted or rejected. In other cases, the "exit point" call is purely informative: the exit program gets a chance to do something, such as sending an informational message to a user, but does not return any answer. Because the exit is a computer program, it must be prepared by a technical person and installed by the LISTSERV maintainer. ------------------------------------------------------------------------- Starting with version 1.8a, list "exits" have been available to control the major events associated with list maintenance. These exits are now available for non-VM systems as well. This section supersedes the exit description in the version 1.8a release notes, with the exception of the (long) description of the various available exit points, which remain unchanged. While the implementation of list exits is necessarily system dependent, the list exit themselves (ie the tasks that they may carry out, as opposed to how such tasks would be carried out on a particular operating system) are system independent. To prepare a list exit, you must go through the following steps: 1. Create an appropriate exit program, as explained below. Let's assume that the program's name is XYZ. 2. Modify the LIST_EXITS configuration option (create one if none was present in your configuration). This variable lists the names of all the "known" exits. For security reasons, LISTSERV will not call an exit which is not listed there. To enable XYZ and ABC as valid list exits, you would set LIST_EXITS to "XYZ ABC" (with or without the quotes, depending on your operating system). You must reboot LISTSERV after making this change. 3. Modify the header of all the lists which should call the XYZ exit, and add "Exit= XYZ". This tells LISTSERV to call the XYZ exit at various exit points. IMPORTANT SECURITY NOTE: Once an exit has been listed in the LIST_EXITS option, ANY list owner may activate it for his own lists. In other words, step 2 merely tells LISTSERV that the program is a "bona fide" exit. There is no mechanism to restrict the use of an exit to a particular list, because it is very easy to implement this in the exit itself, by checking that the name of the list is what you expect or allow. LISTSERV exits receive one or more parameters as input, and may provide a numeric and (in a few cases) supplemental string result as output. Each operating system has its own set of numeric return codes for various kinds of failures, but LISTSERV always uses the same internal return code system for its exits - anything else would quickly become unmanageable. The value 0 always means "success" or "normal/default action". Positive values indicate various non-default actions, depending on the particular exit point. Negative values indicate system errors. Exit programs are responsible for doing their own error reporting, since LISTSERV has no way to know which errors they may or may not run into. The location, name, programming language and calling conventions of the exit program vary from one operating system to another. Let's examine the basics first: - On VM, the program must be called XYZ EXEC A1 (on LISTSERV's A-disk) and must be written in REXX. - On VMS(TM), the program must be called XYZ.COM on LISTSERV's [.MAIN] subdirectory (LISTSERV_LISTS_DIR) and must be written in DCL. - On unix(R), the program must be called XYZ and must be located in the 'home/' subdirectory (ie $A). To distinguish them from the standard L-Soft provided scripts and executables, exit programs must always be spelled in upper case. Thus, the program must be called XYZ and not xyz. It can be written in any supported language and LISTSERV must have execute permission. - On Windows NT(TM), the program must be called XYZ.CMD and must be located in the MAIN subdirectory. It must be written in the NT batch language. - On Windows 95(TM), the program must be called XYZ.BAT and must be located in the MAIN subdirectory. It must be written in the DOS batch language. Naturally, you are free to call a program in another language from your exit program. The programming language restriction only applies to the exit program itself. IMPORTANT: Even though the exit program is usually called from LISTSERV's root directory, it should not make any assumption about its current directory. For optimal portability, the program should always use absolute pathnames to access the various files it might need. For instance, list files should be accessed (if at all) as $A/ or A: or %A%\, and so forth. The exit may receive one or more string parameters as input. Most operating systems provide a mechanism to pass one parameter to a script or program, with some restrictions. However, LISTSERV may need to pass several parameters, and the restrictions may not be acceptable. Thus, a system independent parameter passing convention had to be designed. This convention is used by all systems except VM, where multiple parameters of arbitrary length and contents may be passed to a REXX program. On VM, the system independent convention is never used, because it is unnecessary and less efficient than the native method. VM exits use the standard PARSE ARG directive to retrieve their parameters. The system independent convention uses a disk file called 'exit.input' in the same directory as the exit program. This is a standard text file, where each record is one input string parameter. This file is always created if there are 2 or more string parameters for the exit, or if the EXIT_INPUT configuration parameter is set to the value 1. In addition, it is always created on Windows(TM) operating systems. Under VMS(TM) and unix(R), the file is not created when there is only one parameter and EXIT_INPUT defaults to 0. Since most exits only have a single parameter, this improves performance in most cases. Note that LISTSERV will take care of deleting the 'exit.input' when appropriate. Regardless of whether or not the 'exit.input' file is created, the first parameter is always passed to the exit using system-specific methods under VMS(TM) and unix(R). Under Windows(TM) systems, the first parameter is only passed through the 'exit.input' file. Again, this may simplify programming for simple exits. IMPORTANT SECURITY NOTE: LISTSERV will always quote/escape the first parameter to prevent the recognition of special characters by the underlying operating system. However, your program should be very careful in its use of the parameters in any subsequent system call. For instance, if the parameter to your unix(R) exit is the string "a|b", LISTSERV will quote the vertical bar so that it does not result in the execution of the program 'b', and so that the value "a|b" is present in your argument vector. However, you must still be careful in the use of the arguments within your program, especially if you plan to launch a compiled program from a shell and pass it the same arguments. In that case L-Soft recommends the use of EXIT_INPUT = 1, which allows the second program to read its parameters safely from the 'exit.input' file. For list exits, there is at least one input parameter, of the form (blank separated): epname listname more where 'epname' is the name of the entry point being called (SUB_FILTER, SUB_FAIL, etc), 'listname' is the name of the list, and 'more' depends on the particular exit point. Under VM, 'more' may contain '15'x characters delimiting additional parameters. Again, while 'epname' and 'listname' are unlikely to contain "tricky" characters, the same cannot be assumed about the remainder of the parameter string. In most cases, your program will only handle a limited set of exit points. When it does not recognize the 'epname', it should exit with the numeric result 0, which tells LISTSERV to take the default action. To exit with the result 0, you can take a normal operating system dependent exit. In particular, success status codes are translated to 0 under VMS(TM). To return any other numeric code, or to return a string code, you must use the system independent parameter return convention return below, except on VM where the operating system provides a suitable native convention for the return of one parameter of arbitrary length and contents. So, REXX programs return their results with a standard RETURN or EXIT statement. The first blank-delimited word is interpreted as the numeric result, and the rest, if any, is the string result. In other words, the return string is broken up into number and string in exactly the same manner as with a PARSE VAR RESULT NUMBER STRING instruction. On VM, the system independent return convention is not used, because it is unnecessary and less efficient than the native method. The system independent convention is based on a file called 'exit.output', in the same directory as the exit program. LISTSERV erases this file before calling your program, and reads it when it regains control. This file is a standard text file, which contains a number of directives. To set the numeric return code, you use the EXIT directive: EXIT 2 This would set the numeric return code to 2. To set the string result, use: EXIT-STRING This is the exit string Note that you must ALWAYS set the numeric code if you want the string result to have any effect. The default numeric code is 0, which means "default behaviour", and the default behaviour never uses the string you supply. By definition, the default behaviour is whatever LISTSERV would do if the exit were not present. In addition to EXIT and EXIT-STRING, a number of other directives are available. For instance, you can tell LISTSERV to send a message to the originating user, to explain why the exit rejected his subscription request, or whatever. These directives are processed sequentially until the end of the file. Note that the EXIT directives merely set the final exit codes. They do not interrupt the processing of the 'exit.output' file, which is always read to the end of the file. This means that, if you change your mind about the exit code, you can write a new EXIT instructions and LISTSERV will use the last value that you supplied. Each directive has 0 or more mandatory parameters, and may support a number of optional parameters, which are always listed after the mandatory ones. Some parameters may be simple blank-delimited keywords or options, while others may contain arbitrary data. The exit should not need to provide placeholders for optional parameters, and above all it should be possible to add new optional parameters without requiring all exits to be rewritten. To solve this problem, each directive was given two forms: a simple form, where the entire directive fits in a single line, and an explicit form, where you indicate the number of parameters that you intend to provide, and each parameter follows on a line by its own. In the simple form, the mandatory parameters are filled from the data supplied on the single directive line, and all the optional parameters are set to their default value. Each blank delimited word supplies one parameter, until the first N-1 parameters have been set. The remainder is used for the last parameter. Here is an example: TELL jack@XYZ.COM The FOO-L list is only open to FOO Inc. employees. Parameter 1 (mandatory): "jack@XYZ.COM" Parameter 2 (mandatory): "The FOO-L list is only open to FOO Inc. employees." Parameter 3 (optional): If, on the other hand, you want to send the message to more than one person, you need to use the explicit form: TELL2 jack@XYZ.COM cc: honcho@FOO.COM The FOO-L list is only open to FOO Inc. employees. It is always safer to use the explicit form if you are not sure how many words you will have in the various parameters. The simple form is provided mostly for directives such as EXIT or EXIT-STRING which only take one parameter, and for hardcoded parameters. Currently, the supported directives are as follows. The "VM API" indicates the corresponding REXX API for VM users (it is not possible to provide an API for non-VM systems because the exits run in a different virtual address space and may not call back into LISTSERV entry points). Name: EXIT, EXIT-CODE, RETURN P1: Numeric return code Action: Sets numeric return code; does NOT abort exit.output processing! VM API: EXIT/RETURN Name: EXIT-STRING P1: String result code Action: Sets exit string result VM API: EXIT/RETURN Name: TELL, LTELL P1: List of RFC822 addresses P2: Message text P3 (opt): Blank separated list of options (default = off) - ECHO: echoes message to log - RAGGED: flows but does not justify message Action: Sends long (paragraph) message to specified users VM API: LSVLTELL Name: TELLNF P1: List of RFC822 addresses P2: Message text P3 (opt): Blank separated list of options (default = off) - ECHO: echoes message to log Action: Sends unformatted message to specified users VM API: LSVTELL ********************************************************************** * (non-VM) Usability: Local commands now supported on non-VM systems * ********************************************************************** It is now possible to define "local" LISTSERV command on non-VM systems. A "local" command is a locally developed extension to the LISTSERV command set, which can be installed without making any modification to LISTSERV itself. To install a local commands, you must perform the following steps: 1. Create an exit program to implement the command, as described below. Let's assume the program is called ABC. Command and list exits share the same basic attributes and programming interface, and in particular they are located in the same directory and follow the same naming and calling conventions. 2. Choose a name for your local command. Names starting with a letter are reserved for L-Soft use; other names are reserved for customer use. You could call your command /ABC for instance. 3. Modify (or create) the file 'localcmd.file' in the main LISTSERV subdirectory (the same directory where the lists, exits and other LISTSERV files are located). You must register the command in this file to define its existence to LISTSERV and indicate which exit should be called to execute the command. The format is: /ABC 3 ABC DEF /ABC is the full name of the command, 3 is the minimum abbreviation (allowing /AB or /ABC), ABC is the name of the exit program to execute, and DEF is an optional parameter to be passed to the exit (this allows multiple similar commands to be served by the same exit). 4. Optionally, modify (or create) the file 'localcmd.helpfile' in the same directory to provide a brief (1-2 lines) description of your new command. This is a free form file whose contents and append to the standard HELP message. If the command is important, you may want to mention it there. You do not need to reboot LISTSERV for the changes to take effect. The ABC program is called as an exit with two parameters. The first one takes the following form: origin command arguments where 'origin' is the address of the command originator, 'command' is the name of the command ('/ABC' in the present example), and 'arguments' are the command arguments, if any, provided by the user. The second parameter is the optional DEF parameter from 'localcmd.file'. Typically, your program will parse the arguments, decide on a course of action, and issue a number of messages to the user. The exit code is immaterial; there is no particular course of action to select for command processing. ****************************************************** * Usability: New list exit point for the SET command * ****************************************************** A new list exit point is now available to filter or alter SET commands: Name: SET_REQ Parameters: Three; originator's address, list of options to be altered, target e-mail address Return code: 0=Accept, 1=Reject, 2=Alter Description: This exit point is called for all SET commands that do not originate from the list owner. The first parameter (originator's address) is the address you should use to send replies or informational messages to the command originator. The second parameter (list of options to be altered) is a blank-separated list of command options, in their canonical spelling. If topics have been specified, they are listed last, after the word 'TOPICS:', with the spelling provided by the user. Bear in mind that topic change requests are not necessarily a list of the new topics to be enabled, and may contain complex '+' or '-' directives. Finally, the third parameter (target e-mail address) is the address as it appears in the list, and is provided for the sake of completeness; in most cases you will not need to examine it. If you return the value 1, the command is rejected and no option is modified. A return value of 2 indicates that the list of options and/or topics should be altered before the changes are performed. The exit string must contain a replacement for the second input parameter, in the same format. LISTSERV will assume that any option or topic specified in this fashion are syntactically correct; while incorrect values will not cause any problem and will be properly rejected as invalid options, the error message(s) returned to the user may not be as helpful as they ordinarily would. *************************************************** * Usability: New FILTER_ALSO configuration option * *************************************************** In some cases, it may be desirable to filter a certain set of addresses for all lists, especially in the event of temporary problems with a gateway. This can now be done with the FILTER_ALSO configuration variable. It has the same format as the "Filter= Also,..." list header keyword, except that the wildcard specifications are separated by blanks, not commas. For instance, FILTER_ALSO = '*@*.XYZ.COM *@ABC.COM' will filter the addresses in question globally. ************************* * Miscellaneous changes * ************************* - (VMS) New NO_NJE_JOBS configuration option: when set to "1", this option directs a VMS(TM) server running in NJE mode to send all outgoing server-to-server requests via the Internet. It has no effect if the server is running in TCP/IP mode. L-Soft recommends setting this option to "1" if you have a high-performance SMTP server, such as L-Soft's LSMTP(TM). - (non-VM) New SMTP_RESET_EVERY configuration option: this option directs LISTSERV to drop its outbound SMTP connections at regular intervals. The value of the keyword is the number of minutes between each forced timeout. This option may be useful if you are using sendmail as a mail delivery agent. On an active system, there may be enough traffic to keep the connections active 24 hours a day. The size of the sendmail process driving the connection appears to grow with time, with observed values of 20M or more after a few days of activity, presumably due to storage fragmentation. Since this is the process from which all the delivery subprocesses are forked, all the sendmail processes get bigger with time, and some customers have reported swap space exhaustion and/or increased swap rates as a result. Resetting the connection regularly (say every 8h) prevents this phenomenon. - New DEFAULT_SPLIT configuration option: this new option may be used to provide a default value for the "SPLIT=" command line keyword. This may be useful for servers located behind a central/campus mail server with a known, "below average" message size limit. The DEFAULT_SPLIT option should be set to the maximum desired message size, in kilobytes. - New QUALIFY_DOMAIN configuration option: while Internet standards require all outbound mail headers to contain fully qualified domain addresses, in practice some systems still generate unqualified addresses. LISTSERV-NJE servers qualify them with the NJE domain name (normally .BITNET), whereas LISTSERV-TCP/IP uses the local Internet subdomain (ie if the server is running as LISTSERV.XYZ.COM, addresses are qualified with .XYZ.COM). The QUALIFY_DOMAIN option may be used to override this behaviour. For instance, QUALIFY_DOMAIN = '.CC.XYZ.COM' would append .CC.XYZ.COM to all unqualified addresses. - Reserved "X-" list header keyword prefix: starting with version 1.8b, list header keywords whose names start with the string "X-" are reserved for local customer procedures, EXCEPT for the existing "X-Tags=" keyword, which will remain an L-Soft keyword. In other words, with the noted exception, L-Soft provided code will not use keywords whose names start with "X-". The list header keyword parser will accept all "X-" tags as valid regardless of their contents, again with the exception of "X-Tags=", whose syntax will still be validated. Thus, customers will no longer need to modify LISTKWD FILE to register keywords for local LISTSERV extensions. - New SHOW LICENSE command: with the exception of LISTSERV-NJE for VM, all versions of LISTSERV now support the SHOW LICENSE command, which is particularly useful for troubleshooting purposes as it displays the server's "build date". This is the date at which the code was built by L-Soft, which provides finer tracking that the version number. ************* * APAR list * ************* Because it corresponds to over a year of development from the original 1.8a version for VM and because of the port to VMS(TM), unix(R) and Windows(TM), version 1.8b is the largest "delta" ever released for LISTSERV, with 224 APARs and 39 new modules, not counting operating system specific code. For the sake of brevity, we will only include one-line APAR abstracts in these release notes. Contact L-Soft support if you need more information about a particular APAR. 18A-0001 93/12/08 Handle spoolid limit exceeded (HCP439E) 18A-0002 94/01/11 LSWMAT2 fails to match multiple wildcards due to typo 18A-0003 94/01/20 Convert the LIST command to PASCAL 18A-0004 94/01/21 New fields - PRI_allsrvun, PRI_bbsrvun, PRI_17srvun 18A-0005 94/01/22 Convert the X-LUPD command to PASCAL 18A-0006 94/01/23 Support for parameter sublists 18A-0007 94/01/24 Fix checksum bug in X-LUPD jobs with blank at col 80 18A-0008 94/01/27 Convert the X-SUPD command to PASCAL 18A-0009 94/02/08 Use long list name in messages when "List-Address= List-ID" 18A-0010 94/02/08 Use LSWKEYWD rather than LOCLIST FILE for ID mapping 18A-0011 94/02/12 New SCAN command 18A-0012 94/02/16 Fix problem with :newnode tag 18A-0013 94/03/07 Change target userid to G2 argument to allow quoting 18A-0014 94/03/07 Remove "'/( from LSWCMPLA argument before processing 18A-0015 94/03/07 Put POSTMASTER@* back on minimal filter 18A-0016 94/03/09 Use CP MSG for local users - LTCP with :internet tag 18A-0017 94/03/10 Change "From:" field heading 18A-0018 94/03/10 Recognize local host in spite of :internet tag (LTCP) 18A-0019 94/03/10 Route recipients correctly in spite of :internet tag (LTCP) 18A-0020 94/03/10 Skip "unknown peer" message for host < 0 18A-0021 94/03/10 Don't ignore :internet for local node if :newnode present 18A-0022 94/03/12 New LIST GLOBAL format for long LTCP hostnames 18A-0023 94/03/12 Add &LISTADDR variable 18A-0024 94/03/14 Properly handle DEBUG=YES for LTCP jobs 18A-0025 94/03/18 Missing LFTERM calls 18A-0026 94/03/19 Fix problem with commands from warm start data (LTCP) 18A-0027 94/03/19 Fix erroneous hostname info (LTCP) 18A-0028 94/03/22 Default to MAIL FROM: 18A-0029 94/03/23 Always include local node in DISTSUM2 regardless of :backbone 18A-0030 94/03/23 Suppress "file sent to you" if recipient = myself 18A-0031 94/03/26 LSVXMAIL conversion, step 1 18A-0032 94/03/26 Use short nodeid in DISTcode (LTCP) 18A-0033 94/03/28 Remove REXX entry point from LSWSRVCB 18A-0034 94/03/28 Remove REXX entry point for LSWBNISM 18A-0035 94/03/28 Use TELL_NOBRKUPD for echo messages 18A-0036 94/03/29 Reset daily message counter when list is released 18A-0037 94/03/30 LSWPENDC does not handle Reply-To= properly 18A-0038 94/03/30 LSWTELRB does not handle Reply-To= properly 18A-0039 94/03/31 Missing LFTERM call 18A-0040 94/03/31 Support for CONWAIT option (for debugging) 18A-0041 94/03/31 Storage corruption with large amount of LTCP nodes 18A-0042 94/04/02 Performance improvement for '(listname)' 18A-0043 94/04/02 Remove obsolete LSVDS4 function codes 18A-0044 94/04/02 Avoid folding date fields after the comma 18A-0045 94/04/02 Minor change for DEC PASCAL compatibility 18A-0046 94/04/05 New function: .TO, &OWNERS 18A-0047 94/04/05 Make "Safe= Yes" unconditional default 18A-0048 94/04/05 Move LSWDACCF from LSWDACC PASCAL 18A-0049 94/04/05 New LSWDACC interface - LSWDACRS, LSWDACRL 18A-0050 94/04/05 Remove LSWKEYGA; use cptr@.S_kwd directly 18A-0051 94/04/06 Remove support for LISTEARN (type 1) CRCs 18A-0052 94/04/07 LSWNNI (RXLSVNNI interface) replaced with LSWNNIxx 18A-0053 94/04/10 Move main loop to LSWPRFGO for LVMS 18A-0054 94/04/10 Define LCD.myself rather than loading it from GLOBALV 18A-0055 94/04/10 Bypass GLOBALV commands for LVMS 18A-0056 94/04/10 LSWTELRU/LU interface for msgs to remote/local users (LVMS) 18A-0057 94/04/11 Fix LDUPPER on R/O storage 18A-0058 94/04/11 Replace LSVIUCV call with LSWPRFNX interface (LVMS) 18A-0059 94/04/11 Minor changes for LVMS 18A-0060 94/04/11 Fix LDE2L on R/O address (LVMS) 18A-0061 94/04/11 Qualify addresses with LCD.INTdom for LTCP 18A-0062 94/04/11 Changes to job statistics for LVMS 18A-0063 94/04/13 Use LXEXIT/LXSEXIT mechanism for LSV$DNT 18A-0064 94/04/13 New LPCRC2 interface to calculate CRC 18A-0065 94/04/13 Convert the SHOW entry point to PASCAL 18A-0066 94/04/14 New LSWBITGN interface 18A-0067 94/04/14 Externalize LSWPRIRB 18A-0068 94/04/14 Remove LSWCMDQS 18A-0069 94/04/14 Move NODESGEN command to PASCAL 18A-0070 94/04/16 Use PASCAL implementation of RXLSVBGN on non-VM systems 18A-0071 94/04/16 Eliminate LAP/LAPC/LAHC calls in LDFn sequences 18A-0072 94/04/16 Add LCD.OS_name1 and LCD.OS_name2 18A-0073 94/04/16 Handle lowercase '.bitnet' 18A-0074 94/04/17 Add support for option sublists 18A-0075 94/04/18 Add LSWLSTLO and LSWLSTST functions 18A-0076 94/04/18 Convert the REVIEW command to PASCAL 18A-0077 94/04/18 Properly report FIO$UPD modes 18A-0078 94/04/18 Under VMS, add VMS message text to tracebacks 18A-0079 94/04/18 Add support for LFOPENX_NATIVE 18A-0080 94/04/23 Set LCD.stopping in LSWSTPEX 18A-0081 94/04/24 Force Month_to_days constant to be static (LCUX) 18A-0082 94/04/24 LPC escape sequences for strings containing '00'xc 18A-0083 94/04/24 Fix unaligned pointer reference (LCUX) 18A-0084 94/04/24 Fix unaligned reference 18A-0085 94/04/24 Work around LPC restriction 18A-0086 94/04/25 Non-VM systems have no native NJE support (LTCP) 18A-0087 94/04/25 Missing LDL2E before local delivery (LVMS) 18A-0088 94/04/25 Send helpful message on SUBSCRIBE when NOMAIL set 18A-0089 94/04/25 Disable INDEX on non-VM systems 18A-0090 94/04/26 New LSWCMPGF function 18A-0091 94/04/27 NJE rules incorrect for VMS and unix 18A-0092 94/04/27 PUT/PUTC for non-VM systems 18A-0093 94/05/10 Notify only first userid in LMC list 18A-0094 94/05/12 Fix problem with FOR handling 18A-0095 94/05/12 Incorrect message when there is only one list 18A-0096 94/05/13 Add LSWTELLU_FLUSH call for non-VM systems 18A-0097 94/05/15 Add post-checking for PW= 18A-0098 94/05/16 Use correct options for "File has been sent" msg 18A-0099 94/05/16 Alphabet quirk for fast path (LVMS-NJE) 18A-0100 94/05/16 Properly report INTLINKS FILE errors 18A-0101 94/05/17 Bypass INDEX processing for non-VM systems 18A-0102 94/05/17 Kludge for sendmail "feature" 18A-0103 94/05/18 Accept broken sendmail system under unix 18A-0104 94/05/18 Convert UNLOCK to PASCAL 18A-0105 94/05/21 Fix LXEXIT support for VMS and unix 18A-0106 94/05/21 Work around LCUX restriction 18A-0107 94/05/22 Call LSWPENF1 before command confirmation 18A-0108 94/05/22 Changes to job statistics for L*UX 18A-0109 94/05/22 Convert LSVLDELT to PASCAL 18A-0110 94/05/22 Add LTRANDN function 18A-0111 94/05/29 Add LSWLDELT event 18A-0112 94/05/30 Changes for ASCII systems 18A-0113 94/05/30 Changes for OSF/1 18A-0114 94/06/02 Avoid class M for outgoing jobs (LVMS) 18A-0115 94/06/03 Honour "Reply-To=" keyword for digests 18A-0116 94/06/07 Fix bug with "Mail-via= Direct" lists 18A-0117 94/06/08 Skip lines starting with .* in LSVINFO FILE 18A-0118 94/06/08 Suppress "File DATABASE OUTPUT has been sent" when echo=no 18A-0119 94/06/09 Fence file on failed write open 18A-0120 94/06/10 More LPC string escape sequences 18A-0121 94/06/13 Change to 'stemindex' for 64-bit systems 18A-0122 94/06/16 Evaluation licenses support 18A-0123 94/06/29 Use correct hostname for .RE 18A-0124 94/06/29 Add support for $SITE$ MAILTPL 18A-0125 94/06/29 Adjust notebook indexing to Notebook-Header= FULL 18A-0126 94/07/21 Fix for LNJE talking to LTCP 18A-0127 94/07/22 Misc changes for LTCP/LVMS/LUX 18A-0128 94/07/23 Preliminary changes for gradated licenses 18A-0129 94/07/24 Changes for gradated licenses 18A-0130 94/07/25 Changes for LMCPW support 18A-0131 94/07/26 Add LSWERRBX function 18A-0132 94/07/27 Fix for LTCP running on VMS or unix 18A-0133 94/07/27 Add support for QUALIFY_DOMAIN 18A-0134 94/07/27 Adjust address of jobs from NJE servers 18A-0135 94/07/28 Add LIXOR and LISHL functions 18A-0136 94/08/06 Translate user%node.NJEDOM@hostname into user@node 18A-0137 94/08/08 Fix problem with some lowercase addresses 18A-0138 94/08/15 Accept listname@nodeid.NJEdom syntax 18A-0139 94/08/23 New evaluation message 18A-0140 94/08/31 Correctly handle long addresses under LVMS/LUX 18A-0141 94/09/07 Add support for unix codes and LCD.LSWERR_info 18A-0142 94/09/10 Validate MAIL FROM: syntax 18A-0143 94/09/11 Correctly handle Prime="MON-FRI: ..." syntax 18A-0144 94/09/20 Changes for Windows versions 18A-0145 94/10/04 Add wildcard support 18A-0146 94/10/05 Changes for XA exploitation 18A-0147 94/10/08 Improve handling of internal timer events 18A-0148 94/10/09 Properly handle SIZE(...) under file system free environments 18A-0149 94/10/10 Define "&" variable with value "&" 18A-0150 94/10/12 Forward "Files-To=" specification 18A-0151 94/10/16 Performance improvements for very large lists 18A-0152 94/10/24 Improved messages for password handling 18A-0153 94/10/24 Convert the PW/PWC command to PASCAL 18A-0154 94/10/24 Default &MYSELF to Internet form 18A-0155 94/10/25 Add LSWTELRB call after command echo 18A-0156 94/10/27 Fix storage leak in digest processing 18A-0157 94/10/27 Support local commands under non-VM environments 18A-0158 94/11/04 Add support for Windows codes 18A-0159 94/11/05 Generate/clean up TZONE 18A-0160 94/11/07 LNJE failed to use LTCP servers as BITNET pseudo-relays 18A-0161 94/11/30 Add LSWPENDS = LSWPEND(P_Null, P_Null) 18A-0162 94/11/30 Add FILTER_ALSO configuration variable 18A-0163 94/11/30 Include user name in forwarded SUBSCRIBE request 18A-0164 94/11/30 Add support for DEFAULT_SPLIT configuration variable 18A-0165 94/12/01 New keyword defaults for better Internet interoperability 18A-0166 94/12/02 Preliminary changes to move AFD/FUI data to SIGNUP database 18A-0167 94/12/21 Less stringent folding for NDMAIL=1 environments 18A-0168 94/12/23 Add support for POSTACK1 form 18A-0169 94/12/23 Add support for &TIMEZONE 18A-0170 94/12/24 Use extended FSCB 18A-0171 94/12/25 Add LSWBNGH function 18A-0172 94/12/25 Display Internet addresses on LIST GLOBAL 18A-0173 95/01/06 Correct handling of PUNCH/LPUN/UUE/XXE on ASCII systems 18A-0174 95/01/06 Support output to a DD 18A-0175 95/01/06 Add support for top/bottom list message banners 18A-0176 95/01/07 Add support for multiple moderators 18A-0177 95/01/08 Add LSWTMANL and LSWTMAOL functions 18A-0178 95/01/08 Change to subscriber messages 18A-0179 95/01/10 Add SET_REQ exit point 18A-0180 95/01/11 Add support for "New-List=" keyword 18A-0181 95/01/11 Add LSWSRVMB function 18A-0182 95/01/15 New auto-delete monitoring feature 18A-0183 95/01/16 Better detection of multiple QUIET: keywords 18A-0184 95/01/18 Correctly handle mail from listserv@XXXX 18A-0185 95/01/18 Add X-SPAM command 18A-0186 95/01/20 Allow installation specific "X-" keywords without checking 18A-0187 95/01/22 Enhanced exit facility 18A-0188 95/01/24 Add support for NJE-free operation 18A-0189 95/02/05 Allow GET/PUT of list with "New-List=" 18A-0190 95/02/07 Fix problem with X.400 addresses 18A-0191 95/02/08 Back to MAIL FROM: for MS Mail 18A-0192 95/02/08 Avoid orphaned tracebacks at Send_Messages time 18A-0193 95/02/25 Minor fluke with LTCP routing 18A-0194 95/03/01 Handle X.400 addresses properly 18A-0195 95/03/02 Add support for per-user licenses 18A-0196 95/03/08 Add X-CONFIRM command 18A-0197 95/03/11 More performance improvements for large lists 18A-0198 95/03/11 Add IMPORT option to ADD command 18A-0199 95/03/11 Performance improvement for ADD IMPORT 18A-0200 95/03/12 Add LFREPTX function 18A-0201 95/03/13 Add build date support for VM 18A-0202 95/03/13 LISTSERV High Performance Option 18A-0203 95/03/15 Add support for -request acknowledgement 18A-0204 95/03/16 Add support for special cookies with file attachments 18A-0205 95/03/16 Add APPROVE command 18A-0206 95/03/18 Add syntax checking for "Renewal=" keyword 18A-0207 95/03/18 Add LTSPLITJ function 18A-0208 95/03/18 Add LSWEXPIR event 18A-0209 95/03/21 Add support for custom INFO banner 18A-0210 95/03/24 File access conflict at Read_DISTSUM2 18A-0211 95/04/01 Reduce line length from 79 to 73 18A-0212 95/04/08 Minor bugs detected by MSVC 18A-0213 95/04/10 Add NO_NJE_JOBS option 18A-0214 95/04/10 Streamline defaults 18A-0215 95/04/10 Fix LRIICPT pointer type 18A-0216 95/04/16 Use LSWLSTST rather than LSWSTATE 18A-0217 95/04/16 New LSTSub format 18A-0218 95/04/17 Replace LSWB64IT with L$64MIME 18A-0219 95/04/24 Allow $BRKHTRU to local users with long userid 18A-0220 95/05/05 Traceback needed if list not found 18A-0221 95/05/08 Add &RELEASE, &OSTYPE, &OSNAME, &HARDWARE 18A-0222 95/05/16 Circumvention for JNET feature 18A-0223 95/05/17 Fix for ND decks with long file names 18A-0224 95/05/18 Improve digest error recovery ------------------------------------------------------------------------- LMAIL, L-SOFT, LISTSERV and LSMTP are trademarks of L-Soft international. JNET is a registered trademark of Wingra Technologies, Inc. Unix is a registered trademark of UNIX Systems Laboratories, Inc. DEC and VMS are trademarks of Digital Equipment Corporation. OSF/1 is a registered trademark of Open Software Foundation, Inc. Windows and Windows NT are trademarks of Microsoft corporation. Sun is a registered trademark of Sun Microsystems, Inc. All other trademarks, both marked and not marked, are the property of their respective owners. -------------------------------------------------------------------------