The Operations Sentinel Autoaction Message System (SP-AMS) runs on the Operations Sentinel server and provides pattern matching capabilities for messages from MCP, UNIX, and other non-OS 2200 host systems. SP-AMS performs the following tasks for MCP hosts:
Participates in the initialization of all connections between Operations Sentinel and an MCP host system by issuing an appropriate usercode and password to the interface software running on an MCP host.
Provides a message parsing capability for the utilization data that is displayed in Operations Sentinel Console tables and bar charts.
Generates alarms based on site-defined message patterns.
Generates event reports based on site-defined message patterns that affect attributes of components being monitored by Operations Sentinel.
Sends automated commands to the managed hosts in response to system messages.
You must activate an SP-AMS database in order to enable the interface between each MCP host system and the Operations Sentinel server. Operations Sentinel attempts to establish a connection to each of the MCP host systems. To do this, SP-AMS must send a valid usercode and password to the interface software before the host system can send data to the Operations Sentinel server.
A sample SP-AMS database is supplied with Operations Sentinel.
Input to the interface software falls into two categories:
Lines beginning with “%” are commands to the agent and are accepted from both the primary and the secondary Operations Sentinel server. Output from these commands is returned to both connected Operations Sentinel servers. These commands are described below.
Other lines are input to the MCP host. The agent accepts these and submits them to the MCP using a DC keyin if they come from the primary Operations Sentinel server. The agent ignores these if they come from the secondary Operations Sentinel server.
Agent Commands
The MCP agent recognizes the following commands:
Status initialization commands:
%INIT class COMPONENTS [,INIT class COMPONENTS] . . .;
Command that reports identities of primary and the secondary Operations Sentinel server:
%SPOSERVERS
The output of this command is sent to the connected Operations Sentinel servers and identifies which server is primary and any other server that is connected. See [xref text to replace]. It enables SP-AMS automation to send an inquiry and take conditional action based on which server is primary and which is secondary. The response to the command is one of the following two pairs of lines.
If ALLOW_AUTOMATED_KEYINS is YES, the following lines are the reply:
hhmmss PRIMARY_SPO SERVER {name|IP-address|NONE} PORT {port-id|NONE} hhmmss SECONDARY_SPO SERVER {name|IP-address|NONE} PORT {port-id|NONE}
If ALLOW_AUTOMATED_KEYINS is NO, the following lines are the reply:
hhmmss PRIMARY_TEST_SPO SERVER {name|IP-address|NONE} PORT {port-id|NONE} hhmmss SECONDARY_TEST_SPO SERVER {name|IP-address|NONE} PORT {port-id|NONE}
The name is reported if possible. If not, the IP-address is reported.
The timestamp, to the nearest second, is the time on the host MCP system.
Note that the number of tokens in the message is the same in all cases. For example:
102330 PRIMARY_SPO SERVER SPO1 PORT 10301 143504 SECONDARY_TEST_SPO SERVER NONE PORT NONE
Connection is determined by the last token. If the last token is NONE, there is no server connection; any other value implies that there is a connection. Using a pattern in the MCPMon database, SP-AMS sets the value of the variable group member to _NEGTOKEN3 (the name or the IP address of the Operations Sentinel server).
The %SPOSERVERS command is analogous to the command mix# AX STATUS SERVERS, but it does not require the SP-AMS database to identify the mix# of the SINGLEPOINT program, and its output format is designed for easier automatic parsing, rather than human readability.
This command could also be submitted using a CO event report, if command security on the Operations Sentinel server for the monitored host allows it.