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 [log in to unmask] 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 [log in to unmask] as opposed to [log in to unmask] 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) <[log in to unmask]>
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)" <[log in to unmask]>
^^^^^
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)" <[log in to unmask]>
***********************************************************************
* 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 [log in to unmask] 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 [log in to unmask] The FOO-L list is only open to FOO Inc. employees.
Parameter 1 (mandatory): "[log in to unmask]"
Parameter 2 (mandatory): "The FOO-L list is only open to FOO Inc. employees."
Parameter 3 (optional): <default>
If, on the other hand, you want to send the message to more than one
person, you need to use the explicit form:
TELL2
[log in to unmask] cc: [log in to unmask]
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:<owner-LISTSERV@myhost>
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 [log in to unmask] 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 [log in to unmask] 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:<LISTSERV@myhost> 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.
-------------------------------------------------------------------------
|
