Different servers
  ~~~~~~~~~~~~~~~~~

  You  can  have  multiple  UMS  servers  (message-bases)  on  one
machine. Each server is identified by its SERVERNAME. The function
UMSRlogin()  and  most  UMS tools allow to specify the name of the
server  to  use  as  a parameter in their command-line or in their
GUI.  If  you  don't  explicitly  specify  the server, the default
server  of  you machine is used. The name of the default server if
given  in  the shell- or environment-variable "UMSSERVER". If this
variable  doesn't  exist,  the  default  server  is  simply  named
"default".

  An environment-variable "umsmb.<servername>" must exist for each
server you want to run on your machine. It indicates the full path
to  the  specific  message-base (which has its own "ums.config, of
course). Similarly an environment-variable "umsfiles.<servername>"
is  required  for  each  message-base,  if you want to use the new
feature of attached files.

  A SERVERNAME should only consist of simple characters (e.g. only
letters and digits), since special characters might be troublesome
for  names  of  shell-variables.  Some  are  even used for special
purposes, as explained in the next chapter.


  Networking
  ~~~~~~~~~~

  Different means of inter-process-communication (IPC) can be used
for  contacting a UMS server from a UMS client. They are addressed
by  the  SERVERNAME, which currently can have one of the following
formats:

1) Local, using Exec-messages:  <servername>
2) Remote, using Envoy:         <servername>@<hostname>
3) Remote, using AmiTCP:        <hostname>:<servicename>
4)                   or:        <hostname>:<portnumber>

  <servername> is the SERVERNAME as discussed above.

  <hostname>  is the name of the machine the UMS server is running
on, given in the syntax of the used network.

  <servicename>  is  the  name  of  an  IP-service,  as defined in
"AmiTCP:db/services"..

  <portnumber>  is  an  explicit, decimal socket-portnumber. To be
used  e.g.  if  the  "services"  file  is  not  properly set up or
different on the client- and server-machine.


  "Fake" Logins
  ~~~~~~~~~~~~~

  In order to use the new (V11) function UMSDupAccount() even with
programs  that  don't  know  about  it,  a  "fake"  login has been
implemented into ums.library:

  if  a login is attempted with an empty username and the password
is  a  decimally  written, valid UMS account, UMSDupAccount() will
silently  be used instead of UMSRLogin(). I.e. the client will use
the  old  login,  although  it's  another process. This will _not_
create  a  new  login  concerning  the UMS server! _No_ new set of
logins-flags will be created.

  Example: name="" password="815"


  In  order to create a new login with new login-flags etc for the
same  user,  another  "fake login" silently retrieves username and
password  from  an  already existing account. For this purpose you
must  again  use an empty username and a decimally written account
as  password,  but  the  account number must be preceded by an "@"
character.

  Example: name="" password="@815"