  IP Server Application Design? 
 The Question is:
 
In our process automation control systems , several servers are communicating .
A cluster of two new ES40 servers are also communicating with other servers.
Process automation  tasks are distributed on two ES40's and are using C socket
interface when communicatihg with ather tasks on different servers. The cluster
of two ES40's has a cluster IP address . Every ES40 has its own IP address. Our
 goal is:
a) To run the process tasks distrubuted to two ES40's .
b) To make possible the other servers to communicate with its partner process
 using cluster IP,
    independently of ES40 server on which it is running.
c) To move the processes to one of the machines in some cases ( such as
 maintenance, failure etc.)
    without effecting  the other servers communicating with these ES40 servers .
 
In the present situation , when we start the task on one of the nodes , the
 client task can connect,
but if we move a process to the other ES40 server, its client task can not be
 connected using
cluster Ip giving "connection refused message .
Before making "listen system call" we pass the "Inaddr_any" parameter to the
 bind system call.
Requesting a way to overcome that problem.
Best Regards.
 
 
 The Answer is:
 
  This task appears to fit what DNS and similar directory services
  packages are designed for.  Failing the applicability of a standard
  directory services package such as DNS, you will want to create your
  own application-specific directory services package.
 
  Within an OpenVMS Cluster, the metric server and the cluster alias
  will be of interest.  Also of interest will be the inetd daemon,
  and its ability to automatically start the necessary server(s).
  Also portmapper, obviously.
 
  There is insufficient information to determine the specific cause
  of the IP socket error(s) reported.  If you wish to pursue the
  resolution of the error(s), you will want to contact the Compaq
  Customer Support Center, and you should expect to be asked for the
  IP stack and version (TCP/IP Services V5.0A with ECO or later is
  preferable), the specifics of the source code and the error, and
  (if possible) a reproducer.
 
