Figure 7-1: Communications Processes and Service Listeners Table
This chapter describes communications process and service listener objects and what you can do with them.
A communications process is the component of an enterprise server that handles communications between clients and the enterprise server. It contains a number of service listeners. An enterprise server is created with one communications process, but you can add more. For advice about how many communications processes you need see the section Number of Communications Processes in the chapter Configuration.
A service listener is an object that contains a network address that accepts incoming client requests on behalf of services. A service can have multiple listeners, and a listener can accept client requests on behalf of multiple services.
Your responsibilities as administrator include:
You can see the information held in the repository for communications processes and listeners by clicking Details on the Home page in the Communications Process column for the enterprise server that you are interested in. The communications process and listener table is shown in Figure 7-1.
Figure 7-1: Communications Processes and Service Listeners Table
The information for a communications process is as follows:
Communications processes don't have names; instead they have sequence numbers. The communications process that is automatically created when you add a new enterprise server is Communications Process 1, and any further communications processes that you create are numbered in ascending order of creation. When you delete a communications process, existing communications processes are not renumbered, however, the next communications process you create will use the same number as the process that was deleted - the lowest available number.
The information for a listener is as follows:
TN3270 and MTO ISC types are only available for use with Mainframe Transaction Option.
Listener display flters control how much listener information you can see. These appear just above the infomation for the first communications process. There are three listener display filters:
Each has a number of options that vary depending on the field; for example the Process filter allows you to select to see no listener details, all listener details, or listener details for a particular communications process, while the Status filter allows you to see all listener details regardless of status or just listener details for listeners with a specifc status:
For example, to see listener details for communications process 2, choose 2 in Listener Display Filters Process; to see only Web Services and J2EE listeners, choose Web Services and J2EE in Listener Display Filters Conversation Type; to see all listener details choose All in all three filters. Use all the filters in combination to achieve the maximum control over the level of detail you see.
When you first see the Communications Process and Listeners table, the Process filter is set to None and the other filters are set to All.
You can use the Configuration Information field on the Edit Communications Process page, and the Add Listener and Edit Listener pages for configuration data specific to a communications process or a listener.
There are a number of additional configuration options, for logging and setting an SSL passphrase, that can be set in the file mf-server.dat. (On UNIX environments, this file is located in $COBDIR/etc. On Windows environments it is located in the base/bin directory of your product installation.) These are mostly options that require setting before the Micro Focus Communication Server (MFCS) contacts the MF Directory Server. In the case of logging, this can be useful where there are problems with the connection between MFCS and MFDS. For instructions on the use of mf-server.dat to configure logging for MFCS, please see the section Communications Process Log Files in the Troubleshooting chapter.
Note: If you have the optional Security Pack, it contains instructions on using mf-server.dat to configure the SSL passphrase.
The Configuration Information field on the Edit Communications Process page can contain the following sections and settings:
[CCI] timeout-grain=timeout-grain-number-of-seconds [ISC] listener-wait=listener-wait-number-of-seconds [listeners] logging=logging-level [MFCC] trace=trace-setting [threading] limit=number-of-threads
The parameters are explained below.
Specifies the CCI timeout in seconds. Any MFCS timeout will be rounded up to a multiple of this value.
timeout-grain=timeout-grain-number-of-seconds| Default: | 5 seconds |
The communications process (MFCS) lets each conversation and listener set its own timeout value for receiving data, but because MFCS runs as part of CCI, and CCI only maintains one global timeout value for the whole process, the granularity of MFCS timeout values is limited by the CCI timeout setting. Setting a larger value than the default will make MFCS timeouts less precise, but will reduce CPU consumption, interrupts, and other factors, improving performance.
Specifies how many seconds to wait for a local ISC listener to become available when starting an ISC outbound connection to connect to another MTO instance or other ISC-compatible system.
listener-wait=listener-wait-number-of-seconds| Default: | 10 seconds |
MFCS needs to have an ISC listener available to support outbound ISC communications. This is most useful if you have outbound ISC connections configured at startup.
Enables additional logging when starting listeners.
logging=logging-level| logging-level | Can be one of:
|
| Default: | 0 |
Controls common client (MFCC) tracing, in conjunction with the mf-client.dat file.
trace=trace-setting| trace-setting | Can be one of:
|
| Default: | 0 |
MFCC tracing is off by default but can be enabled in the mf-client.dat file. MFCS uses MFCC during startup to verify that its control channel is working. If MFCC tracing is enabled in mf-client.dat, you can set this option to “0” to disable MFCC tracing in MFCS. Alternatively, you can set it to a non-zero value to enable MFCC tracing during MFCS startup, to diagnose a failure there.
Specifies the thread limit.
limit=number-of-threads| Default: | 2000 on Windows and 200 on UNIX |
MFCS limits the number of threads it will try to start, in order to avoid exceeding system limits. Currently, MFCS uses one thread for each active conversation, so this limit directly affects the number of simultaneous conversations. Note that the operating system might not allow MFCS to actually create as many threads as the number you set.
The available configuration settings for listener objects depend on the listener’s conversation type. Settings are grouped below by conversation type.
There are no settings for this conversation type.
These options are checked for each request.
The [virtual paths] section is used to translate between the top-level path elements specified in URLs and the actual file-system directories they correspond to. For example, for the URL “http://host/path/to/file”, the [virtual paths] section will be consulted for an entry for “path”. Entries in this section are case-sensitive. For a more detailed explanation of the way these settings work, see the section Deployment Services and Listeners in the chapter Configuration.
The [allow] section is used to restrict what files the Web connector will serve out of a given directory.
[options] logging=logging-level [virtual paths] <default>=default-directory element=file-system-path [allow] element=list-of-filenames
Controls what information is logged.
logging=logging-level | logging-level | Can be one of:
|
| Default: | No logging |
Specifies the directory to which unrecognized URL top-level path elements will be mapped.
default=default-directory| Default: | /dev/null |
The default directory must not exist, so that when the communications process translates the URL into a full path, the request will fail.
Specifies the file-system path to which element will be mapped.
element=file-system-path
| element | The file-system path that element will be mapped to. element must be the top-level (first) element in the URL’s path. Some special tokens can be specified at the beginning of the value:
|
Lists one or more filenames or wildcard pattern specifications, separated by spaces, which the connector is allowed to serve for files on this virtual path.
element=list-of-filenames
| element | The file-system path that element will be mapped to. |
| list-of-filenames | Zero or more filenames or filename patterns, separated by spaces. Only files which match one of these filenames will be served. You can use the wildcards "?" (matches any one character) and "*" (matches zero or more characters). |
| Default: | Permit serving all files |
The Fileshare connector checks these settings at the beginning of each conversation. Changes to them will take effect for subsequent conversations.
[Operation] timeout=number-of-seconds [Trace] control=control-flow-trace data=data-trace file=pathname
Sets the timeout, in seconds, for receiving data from the client.
timeout=number-of-seconds| Default: | Timeout for the communications process, which is 7200 seconds (two hours) |
Enables the tracing of control flow in the connector.
control=control-flow-trace| control-flow-trace | Set to "yes" to trace various connector activities, such as passing a request to an enterprise server |
| Default: | Control flow tracing is disabled |
Enables the tracing of sent and received data.
data=data-trace| data-trace | Set to "yes" to include data in the trace |
| Default: | Data tracing is disabled. |
Specifies the full path of the file to receive trace messages.
file=pathname| Default: | Trace messages are written to the MFCS log (as HTML) |
The TN3270 connector checks the settings below periodically; changes affect current and new conversations.
[logging] client-close=client-close-logging [Operation] default-terminal-type=terminal-type-name Timeout=number-of-seconds TN3270E=negotiation-type [Trace] trace=control-flow-trace data=data-trace length=trace-length sem=send-semaphore-trace file=trace-filename
Controls the logging of client disconnection.
| client-close-logging | If this is set to “yes”, log normal client disconnection |
| Default: | Log only abnormal client disconnection |
Overrides an invalid terminal type sent by the client.
| terminal-type-name | A valid terminal-type name, for example, “ibm-3278-2” |
| Default: | None |
TN3270 conversation negotiation includes the client telling the server what terminal type it is emulating. TN3270E specifies a set of allowed terminal types, but classic TN3270 has less strict requirements, and even some TN3270E clients do not conform to the specification. When the connector receives an illegal terminal type, it normally asks the client to specify a different one, but some clients (for example NetManage ViewNow) do not respond correctly. In this case you are advised to provide this setting.
Specifies the receive timeout, in seconds.
Timeout=number-of-seconds| Default: | 84600 seconds (one day) |
Disables TN3270E (Enhanced TN3270) negotiation.
TN3270E=negotiation-type| negotiation-type | Set to “no” to disable TN3270E negotiation |
| Default: | Enhanced TN3270 negotiation is enabled |
Currently required for some NetManage terminal emulator products, such as ViewNow 1.0 Host Access Quick Connect 3270.
Enables the tracing of control flow in the connector.
trace=control-flow-trace| control-flow-trace | Set to “yes” to enable control flow tracing |
| Default: | Tracing is disabled |
Enables data tracing.
data=data-trace| data-trace | Can be one of:
|
| Default: | Tracing is disabled |
Specifies the maximum number of data bytes to include in the data trace.
length=trace-length| Default: | 40 bytes |
Enables the tracing of operations on the send semaphore.
sem=send-semaphore-trace| send-semaphore-trace | Set to “yes” to trace operations on the send semaphore |
| Default: | Tracing is disabled |
This setting might be useful useful when problems with the send semaphore are suspected, for example, because conversations seem to hang but ESMAC does not show them as busy.
Specifies the full path of the file to receive trace messages. The file is written as HTML (unlike the Fileshare and ISC traces).
file=trace-filename| Default: | Trace messages are written to the MFCS log (as HTML) |
The ISC connector checks the [Operation] section settings at the beginning of each conversation. Changes to them will take effect for subsequent conversations.
The ISC connector checks the [Trace] section settings below periodically during each conversation, so changes to them will take effect for both new and existing conversations.
[Operation] timeout=number-of-seconds [Trace] trace=control-flow-trace data-trace=data-trace-setting allmax=dump-size file=pathname
Sets the timeout, in seconds, for receiving data from the client.
timeout=number-of-seconds| Default: | Timeout for the communications process, which is 7200 seconds (two hours) |
Enables the tracing of control flow in the connector.
trace=control-flow-trace| control-flow-trace | Set to “yes” to trace various connector activities, such as passing a request to an enterprise server |
| Default: | Tracing is disabled |
Enables the tracing of sent and received data.
data-trace=data-trace-setting| data-trace-setting | Can be one of:
|
| Default: | Tracing is disabled |
If data-trace is set to “all”, sets the maximum number of bytes to include in the user data dump.
allmax=dump-size| dump-size | Set to 0 (unlimited) if you want to include all the data |
| Default: | Unlimited, that is, include all the data. |
Specifies the full path of the file to receive trace messages. The file is plain text.
file=pathname| Default: | Trace messages are written to the MFCS log (as HTML). |
If you have Modify permission level or higher you can:
If you have Add/Delete permission level or higher you can also:
A newly created communications process starts immediately if you checked Auto-start on the Copy page; otherwise you can start it by clicking the process's Start button on the Communications Process and Listeners page. Communications processes with Auto-start enabled also start automatically when the enterprise server starts.
When you first add a service listener, you can set its status to "Blocked", "Disabled" or "Stopped". Use the Edit Listener page to set its status to "Started". Listener statuses are described in detail in the context help.
Copyright © 2008 Micro Focus (IP) Ltd. All rights reserved.
How to...