Operations Sentinel establishes and manages each ANSI X3.64 connection using a separate process on the Operations Sentinel server. Each process adopts a number of interface characteristics based on the type of connection it is to control, either a direct serial connection or a LAN-based TCP/IP connection. The defaults used for each of these connection types work for most connections. However, you may find it desirable or necessary to modify these connections to address a specific application. Operations Sentinel provides a means for you to manually configure many of these properties.

Configuration Files

Operations Sentinel creates a Universal Control Interface (UCI) process for each connection you configure.Each UCI process attempts to read two configuration files that define the behavior of that process.

A sample of this configuration file, named c_ _, that includes the defaults each UCI utilizes is located in installation-folder\misc\amux on the Operations Sentinel server.

Each UCI process tries to read the first configuration file immediately after it begins. The file c_ _ supplies general configuration information that applies to all connections and is located in the data-folder\amux folder on the Operations Sentinel server. By default, this file does not exist. If you need to change the general configuration information, create this file by copying the sample c_ _ file from the installation-folder\misc\amux folder to data-folder\amux. The configuration parameters in this file are a subset of the entire available set. These parameters represent debugging control that you might be asked to modify by Unisys support representative to gather information related to a problem. The values in this file correspond to the defaults for the UCI process. Do not create this file or modify these values unless directed by Unisys.

The second configuration file that a UCI process may read has the same format and structure as the first configuration file c_ _, but is named so the UCI process can identify it as being relevant to its specific connection. The name of this connection-specific configuration file is based on the connection network and service names you configure for the connection using Operations Sentinel Console. If you need this file, you must create it by copying and renaming the sample c_ _ file from the following location: installation-folder\misc\amux on the Operations Sentinel server to data-folder\amux.

For example, if you define a connection to a system that uses the TELNET management capabilities of Operations Sentinel Console with the connection network name systemA (as defined in the file SystemFolder\drivers\etc\hosts, DNS server, or WINS server), and the installed connection service name of spo_telnet, the connection-specific configuration file name is

c_systemA_spo_telnet

For a managed system that is directly connected to the Operations Sentinel server “unknown” is used as the connection network name. For example, a directly connected system with the connection service name rumba (in the file SystemFolder\drivers\etc\services) has the configuration name

C_unknown_rumba

In both cases, the files must reside in the amux subfolder in your Operations Sentinel data folder, data-folder\amux. Any parameters defined in a connection-specific configuration file override parameters that are also defined in the global file c_ _.

The existence of a connection-specific configuration file is optional. If not present, the connection uses the parameter specifications in the global c_ _ file or the defaults, if they are not specified in the c_ _ file, or if this file does not exist.

Update the parameters in these files as described in the following text.

Parameter Syntax

The syntax for the parameter specifications is

parameter-name details        

The following are syntax considerations:

Parameter Groups

You can customize the following groups of parameters:

The descriptions of these parameters are generally grouped according to function. In some cases, the text does not contain detailed descriptions because you should not modify the parameters unless so directed by Unisys support representative. The descriptions contain general information so you are aware of their function and the consequences of modifying their values.

Trace/Logging Parameters

In the global configuration file (installation-folder\misc\amux\c_ _) supplied with Operations Sentinel, you find the specification of several parameters that end with the suffix TRACE.Each controls a debugging parameter in UCI that Unisys support representative uses to resolve problems with Operations Sentinel.

By default, the MESSAGETRACE parameter is enabled. All other trace options are disabled. The UCI process of Operations Sentinel logs the information generated by this trace (and others) in the connection-specific folder created by the UCI process handling that connection.

Each UCI process creates a connection-specific subfolder in the common output folder (output/amux), that records information about the connection.The subfolder names take the following form:

U_network-name_service-name

For example, in the cases described earlier for the configuration file, the folders created are U_systemA_spo_telnet and U_unknown_rumba.

Operations Sentinel creates four files in each log folder:

The information logged in these files is available for your examination, but is generally of limited use to you. Unisys support representative uses this information to analyze problems with your system.

Serial Communications Parameters

When connecting to a managed system through a direct serial connection, the communication parameters Operations Sentinel establishes for its serial port to that system must match that of the port on the managed system. Operations Sentinel assumes the following default values for these parameters:

If your settings do not match the default values, either change the parameters for the console on the managed system to match those used by Operations Sentinel, or ensure the Operations Sentinel changes its values for that connection. Operations Sentinel also uses software flow control to stop data flow temporarily while processing the information it has received.

Operations Sentinel uses flow control only when data flow is unusually heavy, not during typical data exchange, and the standard start and stop control characters, Ctrl-q (0x11) and Ctrl-s (0x13), to implement flow control. According to conventional ANSI X3.64 implementations, the terminal handler intercepts these characters on the console of the managed system and recognizes the characters as data flow control if the IXON option is enabled. If you encounter a problem with the flow control algorithm, disable it using the FLOWCONTROL parameter described later.

Serial Communications Parameter—BAUDRATE

To specify a baud rate (bits per second) that is different from the default 9600, specify the following parameter in the configuration file:

BAUDRATE baud-rate

where baud rate is one of the following:

Example

The following parameter specifies that the connection uses a baud rate of 19,200 bps:

BAUDRATE 19200

Serial Communications Parameter—PARITY

To specify parity handling that is different from the default of no parity, specify the following parameter in the configuration file:

PARITY parity-handling

where parity-handling is one of the following:

Example

The following parameter specifies that the connection uses odd parity:

PARITY ODD

Serial Communications Parameter—CHARSIZE

To specify a character size that is different from the default of 8 bits, specify the following parameter in the configuration file:

CHARSIZE character-size

where character-size is either of the following:

Example

The following parameter specifies that the connection uses 7-bit characters:

CHARSIZE 7BIT

Serial Communications Parameter—STOPBITS

To specify stop bit handling that is different from the default of 1 stop bit, specify the following parameter in the configuration file:

STOPBITS stop-bits

where stop-bits is either of the following:

Example

The following parameter specifies that the connection uses 2 stop bits per character:

STOPBITS 2STOP

Serial Communications Parameter—FLOWCONTROL

To control the use of flow control by Operations Sentinel for direct serial connections, specify the following parameter in the configuration file.

Do this only if the managed system does not support software flow control or you encounter a problem with flow control.You can recognize this problem if you encounter a hung connection.

FLOWCONTROL state

where state is either of the following:

Example

The following parameter specifies that the connection should not use software flow control:

FLOWCONTROL OFF

Serial Communications Parameter—Summary

The following table summarizes the serial communication specifications, identifying the appropriate “sty” parameters to which they correspond. Here bps is bits per second.

Connection Initialization Parameters

When you connect a managed system to Operations Sentinel, the system perceives Operations Sentinel as a user. Through the capabilities of SP-AMS, Operations Sentinel performs most or all of the tasks the typical administrator needs to accomplish. To initiate this level of control, the data must flow from the managed system to the Operations Sentinel server. Normally, when Operations Sentinel connects to the system console (through a terminal/communications server LAN connection), that system is not aware of this new user, nor does it know that this new user needs a prompt to determine the next course of action. Operations Sentinel must initiate this dialog.

Ideally, this exchange begins without causing any interruption in the activity currently underway on the managed system console. Operations Sentinel must receive information from the system console before management operations can begin. Soon after you establish a connection to the managed system, Operations Sentinel sends an ANSI X3.64 newline character (0x0a) to prompt the system for information. In most cases, this results in a new logon prompt or a redisplay of a shell prompt and has no effect on the state of the managed system.

If this default causes a problem for a managed system, configure Operations Sentinel to take any action you specify. This specification may include taking no action.

Connection Initialization Parameter—INITWITH

To modify the action Operations Sentinel takes when establishing a connection to a managed system, specify the INITWITH parameter in either of the following forms:

INITWITH keyword
INITWITH "string"

where keyword is one of the following:

If one of the keyword parameters in the table does not satisfy your requirements, use the second form of the INITWITH parameter. string is a string of one or more characters (see the following table) enclosed in quotation marks. The format of this string follows the general convention in which any printable character can be specified, plus the following provisions for nonprintable characters.

There is no limit on the length of this string.The string is submitted as a single output operation, with no pauses and no analysis (at the connection level) of the data that may return from the managed system. Therefore, the string should not be too long nor too complex, nor be used to perform actions that are more appropriately handled by the SP-AMS.

Examples

The following example specifies that the connection is to be initialized with a break:

INITWITH	BREAK

The following example specifies that the connection is to be initialized with two newline characters:

INITWITH	"\n\n"

Connection Initialization Parameter—RECOVERWITH

If Operations Sentinel loses a connection to a managed system and attempts to recover that connection, the same problem arises as initially getting data from the managed system. You can configure action similar to the INITWITH parameter using the RECOVERWITH parameter. Normally, the action needed for recovery is the same as that required for initialization; so if you require special action on initialization, specify the same action for recovery.

The formats of this parameter are as follows:

RECOVERWITH 	keyword
RECOVERWITH 	"string"

The parameter options, definitions, and cautions are the same as that specified earlier for the INITWITH parameter.

Your specifications for the TCP/IP connection managing parameters control the recovery action of UCI for LAN-based connections.As a result, special handling defined for the RECOVERWITH parameter may or may not be used.

Examples

The following example specifies that upon recovery, the system initializes the connection with a carriage return followed by a newline:

RECOVERWITH 	CRNL

The following example specifies that the system initializes the connection with two newline characters (specified using both octal notation and hexadecimal notation, respectively):

RECOVERWITH 	"\012\0x0a"

Input Handling Parameters

SP-AMS allows you to automatically send commands or keyins to a managed system for processing. The managed system perceives Operations Sentinel as a user and those commands must appear to the managed system as though they are coming from a user typing on a keyboard.

This has the following implications for the UCI process controlling that connection:

Input Handling Parameter—ENDLINEWITH

By default, the UCI process appends a newline (0x0a) character to every input or command submitted by SP-AMS to the managed system.Many systems recognize this character as the end-of-input character. If this is not so for your application, adjust UCI to use a different character (or not to append anything) using one of the following formats:

ENDLINEWITH 	keyword
ENDLINEWITH 	"string"

where keyword is one of the following:

If one of these keyword parameters does not satisfy your requirements, use the second form of the ENDLINEWITH parameter. string is a string of one or more characters enclosed in quotation marks. The format of this string follows the general convention where any printable character can be specified, plus the provisions for non-printable characters shown in the table for the INITWITH parameter.

There is no limit on the length of this string. However, when you use this capability, the system appends the specification to the SP-AMS generated input.Therefore, do not make the string too long or too complex and do not use the string to perform actions that are more appropriately handled by SP-AMS.

This parameter does not affect input you submit through a console screen. Your actions define that information. UCI ignores the information.

Examples

The following example specifies that each input from SP-AMS should be terminated by a carriage return:

ENDLINEWITH CR

The following example specifies that each input from SP-AMS should be terminated by a newline followed by a carriage return:

ENDLINEWITH "\n\r"

Input Handling Parameter—ECHOTIMEOUT

To avoid overrunning the TTY console handler of the managed system, UCI submits lengthy inputs to the system one character at a time. The UCI waits as long as one half- second before sending the next character.

If the system sends output before the one half-second has expired, UCI treats the output as an echo of the last character submitted and submits the next character.

If the system does not send output within the one half-second timeout period, then UCI assumes the input character echo is disabled and proceeds with the next character.

If this timeout period is unacceptable, you believe it is causing unnecessary delays, or you observe that input characters are lost, modify the default one half-second to suit your needs using the following parameter specification:

ECHOTIMEOUT wait-period

where wait-period is a decimal value as follows:

Use these guidelines for changing the ECHOTIMEOUT parameter value:

Example

The following parameter specification directs Operations Sentinel not to wait for an echo from the managed system before sending the next character. The input should be delivered to the managed system as quickly as possible.

ECHOTIMEOUT 0

The following parameter specification directs Operations Sentinel to wait at most 1000 milliseconds (1 second) for an echo from the managed system before sending the next character.

ECHOTIMEOUT 1000

TCP/IP Connection Management Parameters

When managing a system using LAN based services (for example, spo_ats or spo_telnet), Operations Sentinel is not necessarily notified when the other end of the connection fails. As a result, Operations Sentinel uses the expected periodic flow of data from the managed system to ensure the connection is functioning. You can control the expected periodic flow by specifying a timeout period for the connection when you configure your system.

The default period is 150 seconds (2.5 minutes). If Operations Sentinel does not receive data from a connection within that time, the UCI process controlling that connection treats the connection as dead and forces an automatic recovery.

If the 150-second timeout period is unacceptable, change the value using Administration mode of Operations Sentinel Console, which gives you the option of disabling the timeout function entirely by specifying a timeout period of 0.

If the default connection management feature does not meet your needs, you can modify it in a few different ways, including disabling it through a connection configuration file parameter rather than modifying the timeout value.

You can also specify that the connection can be managed by using the TCP/IP KeepAlive protocol or a combination of this and the default data traffic method.

In addition to the capability to control the means by which UCI checks a connection, you can also define the steps to be taken to recover the connection. By default, if a connection has failed, Operations Sentinel automatically recovers it with just a momentary loss of connection noticeable in the connection status displays.

Other alternatives allow you to recover the connection without any status changes or to not recover the connection, leaving that task for the operator.

TCP/IP Connection Management Parameter—TIMEOUTDETECTION

By default, UCI uses the configured timeout period (default 150 seconds) to wait for information from the managed system. If no data is received in that time period, UCI treats the connection as failed and takes recovery action. If this procedure does not suit your needs, modify that algorithm by specifying the following parameter:

TIMEOUTDETECTION keyword

where keyword is one of the following:

Example

The following example specifies that the UCI process for this connection should not manage the status of the connection:

TIMEOUTDETECTION NONE

TCP/IP Connection Management Parameter—TIMEOUTRECOVERY

When timeout detection is enabled, UCI automatically recovers the connection.You may see a quick change of the connection status in the various status displays. If you are not interested in seeing this momentary status change or notifying SP-AMS that the connection has failed, set UCI to recover the connection without changing the displays.You can configure these actions by specifying the following parameter:

TIMEOUTRECOVERY keyword

Where Keyword is one of the following:

Example

The following example specifies that if the connection times out, UCI recovers the connection silently without notifying the display services:

TIMEOUTRECOVERY SILENTRECOVERY

Display Type—SCREENMODE

By default, for the most accurate management and automation, the UCI service prefers line-at-a-time display sessions.Line-at-a-time means that the display is a simple scrolling session where new information is displayed at the bottom of the screen and old information is scrolled up to eventually roll off the screen at the top. Each new line as it is delivered to the display device, (in the case of Operations Sentinel, UCI) captured, packaged, and sent to all interested Operations Sentinel components for analysis and recording.

Some management interfaces, however, use a full-screen type of display mode. In full-screen display mode, updates are made to the displayed screen not necessarily at the bottom, but anywhere on the screen, with or without an associated scrolling action. To accommodate this type of display, Operations Sentinel provides the configuration parameter SCREENMODE.

When SCREENMODE is set to FULL, the corresponding instance of UCI utilizes a special screen scraping algorithm to capture lines of data from the screen image. The captured lines are only those lines that have been updated. Regardless of the number of characters updated, the entire line is captured and passed to various Operations Sentinel components for analysis or recording.

Because of the additional processing involved in screen analysis for full-screen mode, performance is affected slightly; avoid using this mode unless it is required.

The format of this specification is as follows:

SCREENMODE keyword

where keyword is one of the following:

Configuration Parameter Summary

The following table contains a summary of the configuration parameters.