Multiple communications processes
If you are configuring multiple communications processes for an enterprise server instance, you need to consider the following:
- You can configure different communications processes for different types of communications, for example, one communications
process for TN3270 traffic and another for Web Services and ESMAC. With this sort of configuration, a failure in one communications
process does not disrupt others, so other types of communications are not affected.
- You can also run multiple communications processes for the same kinds of clients, configuring some clients to connect to
one port and other clients to connect to a different port.
- Communications processes cannot share ports. If you use fixed ports for your communications listeners, each listener must
have a different port assigned to it if they will be running at the same time.
- There is no support in Enterprise Server for failing conversations over from one communications process to another.
Other considerations
- Some clients, such as
Rumba+ Desktop, can be configured to try a series of ports when establishing a connection. Other clients may have to be configured manually
to try a different communications process if the main one is not responding.
- COBOL Web Services clients can be configured to search for an available enterprise server listener, rather than a specified
port number.