Single Point Operations

Transcription

1 Single Point Operations Interface for ClearPath MCP Installation and Configuration Guide MCP 12.0 April 2008

2 .

3 unisys imagine it. done. Single Point Operations Interface for ClearPath MCP Installation and Configuration Guide MCP 12.0 April

4 NO WARRANTIES OF ANY NATURE ARE EXTENDED BY THIS DOCUMENT. Any product or related information described herein is only furnished pursuant and subject to the terms and conditions of a duly executed agreement to purchase or lease equipment or to license software. The only warranties made by Unisys, if any, with respect to the products described in this document are set forth in such agreement. Unisys cannot accept any financial or other responsibility that may be the result of your use of the information in this document or software material, including direct, special, or consequential damages. You should be very careful to ensure that the use of this information and/or software material complies with the laws, rules, and regulations of the jurisdictions with respect to which it is used. The information contained herein is subject to change without notice. Revisions may be issued to advise of such changes and/or additions. Notice to U.S. Government End Users: This is commercial computer software or hardware documentation developed at private expense. Use, reproduction, or disclosure by the Government is subject to the terms of Unisys standard commercial license for the products, and where applicable, the restricted/limited rights provisions of the contract data rights clauses. Unisys and ClearPath are registered trademarks of Unisys Corporation in the United States and other countries. All other brands and products referenced in this document are acknowledged to be the trademarks or registered trademarks of their respective holders.

5 Single Point Operations Interface for ClearPath MCP Installation and Configuration Guide MCP 12.0 Single Point Operations Interface for ClearPath MCP Installation and Configuration Guide MCP Bend here, peel upwards and apply to spine.

6 .

7 Contents Section 1. Introduction 1.1. Overview of Single Point Operations Overview of the Interface Software Data Flow in the Interface Software Message Services Software and Hardware Requirements Software Hardware Operator Interface Using SP-AMS to Monitor MCP Using Single Point Operations Status to Monitor MCP Systems Application Program Interface (API) Library Configuration File and Filter File Interface Start-Up and Recovery Connection Timeout Alarm Responding to Alarms Raised by Single Point Operations Single Point Operations Access to System Control Processor (SCP) Applications Configuring Resilient Single Point Operations Servers Connecting to More Than Two Single Point Operations Servers Using Four Single Point Operations Servers Setting Up a Second Instance of Interface Software Connecting Two Instances of the Interface on the Same Single Point Operations Server Section 2. Preinstallation Tasks 2.1. Overview LAN Software Configuration Hosts File Services Files Default MCP Service Setting Up the Services File Assigning Usercodes Usercodes Assigning Usercodes to Initiate Auto-Logon of Terminal Emulation Sessions iii

8 Contents Assigning Usercodes to Initiate the Interface Connection Initialization and Automation Start-Up To Begin Monitoring Sample Database Monitoring MCP and UNIX Systems Activating an SP-AMS Database Section 3. Installing and Initializing the Interface Software 3.1. Installation Configuration File Filter File Initiating and Terminating Initiating Initiation After Halt/Load Terminating Contents of the Files on the Release Media *D/SINGLEPOINT/CONFIG File Listing *D/SINGLEPOINT/FILTER File Listing *D/SINGLEPOINTTEST/CONFIG File Listing *COMS/SINGLEPOINT/LOAD File Listing Section 4. Monitoring Available Disk Space 4.1. Capabilities Monitoring Threshold Violations Option Multiple Thresholds Sector Size Options for Reporting Disk Utilization Section 5. Commands 5.1. How to Change Operating Parameters Commands and Responses CLEAR PRIMARY Command CLEAR SECONDARY Command FILTER ADD Command FILTER DELETE Command QUIT Command QUIT NOW Command RELOAD Command RENEW DISK ALARMS Command RENEW DISK ALARMS Change Command SAMPLE Command SAMPLE Change Command SAMPLE DISKS Command SAMPLE DISKS Change Command STATUS Command STATUS BRIEF Command STATUS SERVERS Command iv

9 Contents STOP Command STOP NOW Command SWITCH PRIMARY Command Section 6. Messages 6.1. Interface Control Messages Version Message SP-AMS Port Usercode Failure Messages Reporting Single Point Operations Server Status Changes Connection Message Containing Elapsed Time Since Last Halt/Load Utilization Messages System Event Messages Job Formatter Format Classic Format Disk Monitoring Messages Disk Available Space Attributes Displayed by Status Disk Available Space Messages: Old Format Disk Available Space Messages: New Format Disk Family Online Messages Disk Pack Online Messages Messages for Single Point Operations Status Initialization Message Sequence Component Initialization Messages Application Program Interface (API) Messages SP-AMS and Cross-System Automation Commands and Responses Commands Sent to the Host System by SP-AMS Responses to SP-AMS and Cross-System Automation Commands Section 7. Application Program Interface (API) 7.1. API Library Capabilities API Library Protocol Preparing an Application Program to Use the API Library Linking an Application Program to the API Library Sending a Status Message Sending a Message to the Single Point Operations Server Unlinking an Application Program from the API Library Heartbeat Timer v

10 Contents Appendix A. Troubleshooting A.1. Single Point Operations Server Information... A 1 A.2. Reporting Problems... A 1 A.2.1. Using Support Online (Electronic Support Services)... A 1 A.2.2. Contacting the Unisys Support Center... A 1 A.2.3. Obtaining Direct Telephone Support... A 2 A.2.4. Software Support Services... A 2 Appendix B. Single Point Operations Configuration Requirements and Connection Sequences B.1. Configuration Requirements... B 2 B.2. Start-Up Sequence... B 3 B.3. Connection Management and Interface Sequences... B 3 B.3.1. Initial Connection Sequence... B 3 B.3.2. Interface Termination and Recovery Sequence... B 7 B.3.3. Connection Attempts with Ports Full... B 8 Appendix C. Related Product Information Index... 1 vi

11 Figures 1 1. Communication Paths Four Single Point Operations Server Connections Two Instances of the Interface Two Instances of the Interface on the Same Single Point Operations Server Edit MCP Systems Renew Disk Alarms vii

12 Figures viii

13 Tables 6 1. Utilization Data Message Attribute Names and Associated Values B 1. B 2. B 3. B 3. B 3. B 4. Configuration Requirements...B 2 Start-Up Sequence...B 3 Initial Connection Sequence (Part 1)...B 4 Initial Connection Sequence (Part 2)...B 5 Initial Connection Sequence (Part 3)...B 6 Interface Termination and Recovery Sequence...B ix

14 Tables x

15 Section 1 Introduction Use of the New Product Name in This Document Single Point Operations is now called Operations Sentinel. Throughout this document, however, the former product name, Single Point Operations, has been retained to reflect the very limited name changes applied within the product at this time. Documentation Updates This document contains all the information that was available at the time of publication. Changes identified after release of this document are included in problem list entry (PLE) To obtain a copy of the PLE, contact your Unisys representative or access the current PLE from the Unisys Product Support Web site: Note: If you are not logged into the Product Support site, you will be asked to do so. Overview This section summarizes key functional aspects of using Single Point Operations to monitor and control MCP host systems. Read this section before managing MCP host systems with Single Point Operations. This section contains the following subjects: Overview of Single Point Operations (see 1.1) Overview of Single Point Operations Interface for MCP (see 1.2) Software and hardware requirements (see 1.3) Operator interface (see 1.4) Using SP-AMS to monitor MCP systems (see 1.5) Using Single Point Operations Status to monitor MCP systems (see 1.6) Application Program Interface (API) library (see 1.7) Configuration File and Filter File (see 1.8) Interface start-up and recovery (see 1.9) Connection timeout alarm (see 1.10) Responding to alarms raised by Single Point Operations (see 1.11)

16 Introduction Single Point Operations access to System Control Processor (SCP) applications (see 1.12) Configuring resilient Single Point Operations servers (see 1.13) The primary audience for this guide is the staff who installs and configures the software for managing MCP host systems. Notation Conventions This guide uses the following conventions: Variable names for which you must supply values appear in italics. For example: internet address. Italicized words can also be variables in a string. These variables are defined by the user or sometimes by the operating system. Brackets ( [ ] ) enclose parts of statements (phrases) that are optional. Braces ( { } ) group similar information in which one of the values is required. The separator symbol ( ) indicates that the item following the symbol is an alternative to the item preceding it Overview of Single Point Operations Each MCP host system and each MCP operating system partition that you manage are represented by a single icon in a cluster window of Single Point Operations Console. Hereafter, the term MCP host system refers to both MCP host systems and MCP partitions. The icons in the cluster windows show alarm conditions and connection status and provide a way for starting terminal emulation sessions, launching external applications, and displaying properties for individual host systems. Managing and controlling MCP host systems are some of the many capabilities of Single Point Operations. The Single Point Operations software is installed on a Windows server or UnixWare server called the Single Point Operations server. A software component, the Single Point Operations Interface for ClearPath MCP (hereafter referred to as the interface software), is installed on each MCP host system that is to be managed. An SP-AMS database consists of a set of automation rules. Although you may need to adapt some rules for each MCP host, Unisys supplies automation rules that encompass everything else you need. The full range of Single Point Operations capabilities is available to manage and control each MCP host system. These capabilities include the following: Logging message traffic

17 Introduction Viewing logged messages Managing system and disk utilization parameters, and displaying tables and bar charts of these parameters Displaying alarms Performing external actions when an alarm is raised, acknowledged, or cleared, including automatically dialing pagers Viewing message traffic on a terminal emulation session running as a remote operator display terminal (ODT) Entering commands from a terminal emulation session running as a remote ODT Automating system operation using Single Point Autoaction Message System (SP-AMS) Monitoring hardware and software components and application programs using Single Point Operations Launching site-supplied external applications on behalf of a host system An SP-AMS database must be active on the Single Point Operations server to enable communications between the interface software and the Single Point Operations server to work together. Before a host system can send data to the Single Point Operations server, the SP-AMS database must send a valid usercode and password to the interface software. You may need to edit and compile your SP-AMS database to insert the appropriate usercodes and passwords for your systems Overview of the Interface Software The interface software performs the following activities: Sends real-time system event message data from the MCP host system to one or more Single Point Operations servers. This data contains a variety of information including file usage, communication activity, error information, and job and task activity. This same type of information is stored in the host system log. You can control the types of system event messages processed by Single Point Operations by filtering the information based on Major,Minor message types. A filter file defines the types of messages. See Section 3. Sends system usage and performance information to Single Point Operations at regular intervals. A default interval value is defined with the product, but you can dynamically change it. Responds to commands sent from the Single Point Operations server as a result of automation actions determined by SP-AMS. These commands are processed on the host system just as if they were entered by host system operations personnel. Commands sent from OS 2200 CP-AMS, SMART AMS, or other event sources to the MCP system using Single Point Operations cross-system automation capabilities are also processed this way. Monitors utilization for disk families and individual disk packs, based on the monitoring threshold levels you set for them. Also raises and clears alarms in Single

18 Introduction Point Operations Console when utilization crosses site-defined thresholds. See Section 4. Sends information to the Single Point Operations server that Single Point Operations Status uses to initialize application and device objects. Supports an API library for MCP application programs so that they can send messages to Single Point Operations. See Section Data Flow in the Interface Software Figure 1-1 shows the communications paths between Single Point Operations and a managed MCP host system. The interface software provides the message/automation path between the MCP host system and Single Point Operations. A separate communications path is used to support the INFOConnect terminal windows that can be opened from Single Point Operations Console. Single Point Operations Status Single Point Operations Console INFOConnect Terminal Emulator Single Point Operations Workstation Event Services SP-AMS Logging Single Point Operations Server M CP Host System MCP TCP/ IP Application Services Host System Operator User Commands Single Point Operations Interface Enable Remote O DT COMS MARC CANDE ODT Configuration File Filter File Application Program Interface (API) Figure 1 1. Communication Paths Message Services The interface software provides message services to Single Point Operations. This enables Single Point Operations to automate management and control of MCP host

19 Introduction systems. There are several categories of messages from various sources sent across this interface to Single Point Operations. These messages are matched against sitedefined patterns in the SP-AMS database to determine the automated actions. When a message matches a pattern, SP-AMS performs one or more of the following actions: Raises, acknowledges, or clears an alarm. Sends an attribute-change or delete-component event report to Single Point Operations Status. Creates an event entry in a Single Point Operations log file. Sends a command (message) from Single Point Operations to interface software, which in turn sends the message to the monitored host system. Sends a command to another host system, subject to security settings in Single Point Operations. Messages that are sent from the interface software to Single Point Operations come in the following categories: Interface control messages These messages are sent to the Single Point Operations server when a connection to the Single Point Operations server is first established. Utilization messages Utilization data messages are periodically sent to Single Point Operations based on the interval defined in the UTILIZATION_INTERVAL record in the MCP configuration file. This data populates bar charts and tables in Single Point Operations Console. System event messages The host system generates a variety of system event messages. The interface software captures these messages and sends them to Single Point Operations at the same time they are being sent to the system log for display. The filter file determines which Major,Minor types of messages are sent. Disk monitoring messages When the interface software is configured to monitor disk utilization thresholds, these messages provide information about available disk space. Single Point Operations Status messages Messages are generated when Single Point Operations Status requests information describing the hardware and software components that are to be monitored by Status. Application program interface (API) user messages MCP application programs linked to the API library send status messages and information messages to Single Point Operations

20 Introduction Host command response messages As the result of a match between a pattern in the active SP-AMS database and a message sent by an MCP host system, SP-AMS may send a command back to the host system. Another application using Single Point Operations cross-system automation capabilities may also send a command to the host system through the interface software. When the host system receives the command, it may respond by sending another message back to Single Point Operations

21 Introduction 1.3. Software and Hardware Requirements Software To monitor an MCP system, an LX server, or an MCP node of a ClearPath NX or ClearPath Plus server, you must install the following software: Server version of Single Point Operations on the Single Point Operations server Workstation version of Single Point Operations on each Single Point Operations workstation Interface software on each system and node that is to be managed This release of the interface software is compatible with all currently supported levels of Single Point Operations and all MCP levels that are compatible with programs compiled on MCP level Hardware MCP, NX, EA, and FS Servers You must provide an Ethernet TCP/IP connection between each host system and the Single Point Operations server. Use any of the following to provide interfaces to the LAN: An Ethernet Channel Adapter board, such as CA622 BAS, or CA626 BAS An integrated communications processor (ICP) running TCP/IP. A ClearPath Network Appliance or ClearPath Windows node running ClearPath Enterprise Server Network Services. LX Servers The system software and network interface card included with the LX server provide the required Ethernet TCP/IP connection between the host system and the Single Point Operations server Operator Interface The Single Point Operations operator s interface to the host system is through a terminal emulation session. Single Point Operations levels 7.x and later support Telnet and INFOConnect terminal emulation. Single Point Operations level 9.x supports Web Enabler. This gives the operator access to all of the operations interfaces controlled by the Transaction Server for ClearPath MCP (formerly Communications Management System (COMS)). These include Command and Edit (CANDE), Menu-Assisted Resource Control (MARC), and the remote operator display terminal (ODT). The ODT is the primary operator interface to the system. You can configure terminal emulation sessions using the Single Point Operations Configuration application. While using Single Point Operations Console, you can open a

22 Introduction terminal emulation session to a host system by clicking on the icon representing that host system in a cluster window. In Single Point Operations levels 7.x and later, you can write a Common Accessory Script Language (CASL) macro to be used as a session startup macro by INFOConnect, which will supply your usercode and password when you open a terminal emulation session. Windows Telnet does not support userid and password parameters on its call line, so if you use Telnet for your terminal session, you must log in manually. When a Single Point Operations server connects with or disconnects from the agent, the interface software sends massages that are similar to the server identification messages sent by the %SPOSERVERS command. See Section Using SP-AMS to Monitor MCP The Single Point Operations Autoaction Message System (SP-AMS) runs on the Single Point Operations 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 Single Point Operations 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 Single Point Operations 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 Single Point Operations Status. 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 Single Point Operations server. Single Point Operations 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 Single Point Operations server. A sample SP-AMS database is supplied with Single Point Operations. 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 Single Point Operations server. Output from these commands is returned to both connected Single Point Operations 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 Single Point Operations

23 Introduction server. The agent ignores these if they come from the secondary Single Point Operations 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 Single Point Operations server: %SPOSERVERS The output of this command is sent to the connected Single Point Operations servers and identifies which server is primary and any other server that is connected. See 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: PRIMARY_SPO SERVER SPO1 PORT 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 Single Point Operations 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

24 Introduction This command could also be submitted using a CO event report, if command security on the Single Point Operations server for the monitored host allows it Using Single Point Operations Status to Monitor MCP Systems Single Point Operations Status enables you to monitor the status of hardware and software components. Status receives the information that it needs from the MCP host system through the interface software. The Single Point Operations Status User Guide provides a description of Single Point Operations Status and how it supports MCP monitoring. MCP Tape Monitor The SP-AMS database MCPMon transforms messages from the interface software into event reports that drive the Single Point Status displays of MCP tape activity. See the Single Point Operations Status User Guide for more information about MCP tape monitoring Application Program Interface (API) Library The interface software for MCP includes an API library that enables MCP application programs to send messages to Single Point Operations through a general interface mechanism. The API library is a direct interface between MCP application programs and Single Point Operations. See Section Configuration File and Filter File A configuration file and a filter file reside on each MCP host system and contain information that helps control operation of the interface between the Single Point Operations server and the MCP host system. Default copies of these files are included with the interface software. See Section 3. You can use the default values or you can change these files to meet your specific needs. The configuration file contains the following parameters that control operation of the interface software: Port number on the MCP host system Time interval between utilization messages sent to the Single Point Operations server Name of the filter file Usercode used for remote ODT terminal emulation Security options ADM display sequence for ODT windows on Single Point Operations

25 Introduction The filter file contains a list of the Major,Minor types of entries (messages) that are to be sent to Single Point Operations at the same time they are sent to the host system log. This enables you to display system event data and perform automation control in real time. See Section 3 for information on the configuration file, and for information on the filter file Interface Start-Up and Recovery The interface software is started from the Transaction Server for ClearPath MCP. After it is started, it prepares to receive a connection request from a valid Single Point Operations server. When a user starts Single Point Operations Console on a Single Point Operations workstation, it causes the Single Point Operations services (daemons) to use an established connection or to attempt a new connection with each MCP host defined in the configuration selected by the user. After a connection is made, SP-AMS sends a usercode and password that establish the Single Point Operations server as an authorized client to the interface software. When the interface software confirms that the connection is good, it starts sending message data from the MCP host system to the Single Point Operations server. The message data is processed by SP-AMS according to the active database, and a response is initiated. Configurable Login Delay to Discourage Hackers The interface software can temporarily stop listening to the subports used for connection to Single Point Operations, if the nature of a failed connection attempt suggests that a hacker may be attempting an intrusion. Although it stops listening for new connections, it still processes all information from established connections. The administrator can configure this delay from 0 to 3600 seconds. The default is 300. See Section Connection Timeout Alarm The Single Point Operations server checks that each MCP host system that it is monitoring sends a periodic utilization data (heartbeat) message. You can use Single Point Operations Configuration to specify a timeout value to enable Single Point Operations to determine when contact with the MCP host system has been lost. If the interval between heartbeat messages from a specific MCP host system exceeds the timeout value for that host, a timeout alarm is generated. The Single Point Operations server clears this alarm when it receives the next message (heartbeat or otherwise) from the system. If you set the timeout value to 0, no alarms are generated. It is recommended that you use the default timeout value if you use the default interval for the periodic utilization data. However, you may need to increase the timeout value if you increase the utilization data interval. See the Single Point Operations Administration and Configuration Guide for a description of how to specify the timeout value

26 Introduction Responding to Alarms Raised by Single Point Operations Single Point Operations can alert an operator to many possible events. While responding to an alarm, an operator will normally take some action that changes or controls the operation of the host system that originated the event. The operator s primary interface to the host system is through a Single Point Operations terminal emulation session opened in remote ODT mode. You can also set up your SP-AMS database to match messages and raise and clear alarms automatically Single Point Operations Access to System Control Processor (SCP) Applications You can configure MCP host systems that are supported by a graphical user interface system control processor (GUI SCP) with open platform graphic consoles so that application windows on the SCP can be viewed on any X terminal or PC running X client software such as XVision. This allows you to perform system partitioning, cold system start-up, halt/load, and system maintenance procedures from the Single Point Operations workstation. However, these SCP windows are not integrated with the Single Point Operations software. Refer to the MCP system console guide for your system for specific information about these SCP capabilities Configuring Resilient Single Point Operations Servers For greater resiliency, each instance of the interface software can communicate with two Single Point Operations servers at the same time. The first Single Point Operations server to connect with the interface software is the primary server; the second Single Point Operations server to connect is the secondary server. The interface software employs dynamic port assignment using MCP port subfiles, whereby two parallel message streams may be sent to two separate Single Point Operations servers. These two port subfiles are established in LISTEN mode. In a resilient primary and secondary Single Point Operations environment, the first Single Point Operations server to make a connection to the configured port number receives a working service port (subfile) and is designated as the primary Single Point Operations server. The interface software recognizes a subsequent connection attempt and the second subfile is allocated to the secondary Single Point Operations server

27 Introduction If the Interface software detects that the primary Single Point Operations server has disconnected for any reason, it will close the primary connection, promote the secondary server to primary, open a new subport, and wait for a new connection from a server. The following scenarios can apply in an environment with primary and secondary Single Point Operations Servers: By using the same SP-AMS database and Single Point Operations configuration, a secondary Single Point Operations server will run the same displays and produce the same logs as the primary Single Point Operations server. In addition, the SP-AMS automation environment, including dynamic variables, are always current (except during the short delay of switchover). The interface software only submits commands to the MCP from the primary Single Point Operations server. If both servers SP-AMS databases react to a host output message by sending a command to the host, only the command from the primary server is accepted. Note: External alarms and cross-system automation require particular attention when both primary and secondary Single Point Operations servers are connected to the interface software. You must ensure that external alarms are not duplicated and that cross-system automation commands are submitted only from the primary Single Point Operations server. The interface software processes Single Point Operations Status initialization commands from both the primary and secondary Single Point Operations servers so that Status initialization is provided whenever either server connects with the interface. By running different configurations on each Single Point Operations server, you can distribute control of the managed MCP systems between both Single Point Operations servers. You control the desired primary/secondary association of Single Point Operations servers to systems through selective enabling of monitoring and logging. If the primary Single Point Operations server goes down, the secondary Single Point Operations server assumes primary control of all systems defined in its configuration. Both the primary and secondary Single Point Operations servers have unrestricted ODT terminal access to systems in their respective configurations, regardless of whether they are designated as primary or secondary. You can use the SWITCH PRIMARY and CLEAR PRIMARY commands to control which Single Point Operations server is treated as the primary server. For more information on resilient Single Point Operations environments, see the Single Point Operations Administration and Configuration Guide Connecting to More Than Two Single Point Operations Servers An MCP host can be monitored by more than two Single Point Operations servers. To do this, you must run two or more instances of the interface software, configure different

28 Introduction ports for each copy, and include the following command in the configuration file for the second and subsequent instances. ALLOW_AUTOMATED_KEYINS NO This command tells the interface software to ignore MCP commands (implemented using DCKEYIN) from both of the Single Point Operations servers that connected to it. This ensures that only the Single Point Operations server connected to the first instance of the interface software is allowed to send commands to the host. By running a second instance of the interface software, you can have one or two Single Point Operations servers connected to the host for testing purposes. If the ALLOW_AUTOMATED_KEYINS NO command is in the configuration file, the Single Point Operations servers that connect to the instance of the interface software using this configuration file are regarded as test servers. All MCP commands issued by a test server are ignored Using the COMS LOAD file and CONFIG files supplied with the release, you can connect with up to four Single Point Operations servers. You must define a second port in the services file on the Single Point Operations server unless you are using Single Point Operations level 7.3 or later and use the second port that is defined during the installation of Single Point Operations. For more information on resilient Single Point Operations environments, see the Operations Sentinel Administration and Configuration Guide Using Four Single Point Operations Servers In a production environment, the primary and secondary Single Point Operations servers communicate with the instance of the Single Point Operations MCP Interface running with the program name SINGLEPOINT through the two subports of port This provides a resilient environment for systems and operations management. Sometimes, such as when testing new automation rules, it is useful to have one or two additional Single Point Operations servers connected to a production host. This allows a thorough test of SP-AMS patterns and automated alarm actions with real production data before putting those patterns and actions into production. A second instance of the interface software, running with the program name SINGLEPOINTTEST, can provide this environment. Note that SP-AMS actions may include sending commands to the MCP host. Because of the configuration setting ALLOW_AUTOMATED_KEYINS, only those commands coming from the primary Single Point Operations server connected to program SINGLEPOINT will be delivered to the MCP. Any others will be discarded. These connections are shown in Figure 1 2, in which arrows indicate logical connections rather than physical topology

29 Introduction MCP Host SINGLEPOINT Port SINGLEPOINTTEST Port Subports Subports Primary Production Single Point Operations Server Secondary Production Single Point Operations Server Primary Test Single Point Operations Server Secondary Test Single Point Operations Server /26/03 Figure 1 2. Four Single Point Operations Server Connections Setting Up a Second Instance of Interface Software The Transaction Server for ClearPath MCP load file *COMS/SINGLEPOINT/LOAD defines both SINGLEPOINT and SINGLEPOINTTEST. The key differences between them occur in their configuration files and are shown in Figure 1 3: Figure 1 3. Two Instances of the Interface SINGLEPOINT defaults to allowing keyins from the primary Single Point Operations server; SINGLEPOINTTEST does not. SINGLEPOINT defaults to port 10301; SINGLEPOINTTEST defaults to port SINGLEPOINT can use the Single Point Operations API library; SINGLEPOINTTEST cannot. When you use Transaction Server for ClearPath MCP to load your edited *COMS/SINGLEPOINT/LOAD file, you avoid having to manually define the parameters for the two running instances of the agent. *COMS/SINGLEPOINT/LOAD sets MIN_COPIES to 1 for SINGLEPOINT and to 0 for SINGLEPOINTTEST. To be able to run SINGLEPOINTTEST, set its MIN_COPIES to 1, either by editing the file or updating it on a screen in UTILITY

30 Introduction A Multi-Program ID (MPID) attribute in the COMS load file appends a unique identifier after the task name in mix displays, to facilitate distinguishing production (SINGLEPOINT) from testing (SINGLEPOINTTEST) when two copies of SINGLEPOINT/INTERFACE are running Connecting Two Instances of the Interface on the Same Single Point Operations Server In some circumstances, it may be useful to have both SINGLEPOINT and SINGLEPOINTTEST connected to the same Single Point Operations server. This would permit a certain amount of automation and alarm testing to be done without having an additional Single Point Operations server. This is illustrated in Figure 1 4. MCP Host SINGLEPOINT Port Subports Primary Single Point Operations Server Host Name ROSE1 in Configuration PRODUCTION SINGLEPOINTTEST Port Subports Host Name ROSE1TEST in Configuration PRODTEST Figure 1 4. Two Instances of the Interface on the Same Single Point Operations Server For this testing setup, the MCP host is configured as two different hosts in the Single Point Operations configurations. For example, the connection through SINGLEPOINT might be called ROSE1 and the connection through SINGLEPOINTTEST might be called ROSE1TEST. Both ROSE1 and ROSE1TEST could appear in the same Single Point Operations configuration, or they might only appear in separate configurations. Each would have its own log files, and the automation rules in the SP-AMS database would distinguish between them by their configured host names. A Single Point Operations configuration that includes both connections should define the MCP host service name to be spo_mcp for the connection to SINGLEPOINT and spo_mcp2 for the connection to SINGLEPOINTTEST, as shown in Figure 1 5. Figure 1 5. Edit MCP Systems

31 Section 2 Preinstallation Tasks This section presents information about tasks you must complete and concepts that you should consider before installing the interface software Overview Before installing the software and initializing the interface, ensure that the following activities have been performed: 1. Configure the TCP/IP software to include a route to the Single Point Operations server (see 2.2). 2. Assign a TCP port number to the MCP host system interface software. You use this port number when setting up the services file on the Single Point Operations server. 3. Set up the hosts file on the Single Point Operations server (see 2.3). 4. Set up the services file on the Single Point Operations server (see 2.4). 5. Assign usercodes to be used by the interface software (see 2.5). 6. Update the SP-AMS sample database supplied with Single Point Operations to respond to site-specific messages (see 2.5.3). 7. Define a Single Point Operations configuration that contains the MCP host systems to be monitored. See the Operations Sentinel Administration and Configuration Guide for a description of how to use the Configuration application LAN Software Configuration You must provide an Ethernet TCP/IP connection between the MCP host system and the Single Point Operations server. You can use an integrated communications processor (ICP) to provide the interfaces to the Ethernet LAN, or you can use a ClearPath Network Appliance or Windows server running ClearPath Enterprise Server Network Services. In the client/server model, the Single Point Operations software is the client and the interface software is the server. The addressable TCP/IP address and network name of the MCP host is specified in the hosts file on the Single Point Operations server. This file defines a list of network host names and as an option, aliases. The network host names are paired with their respective Internet network address numbers. You specify a network host name during Single Point Operations configuration when you add an MCP host system or when you

32 Preinstallation Tasks edit the attributes of an MCP host system. See the Operations Sentinel Administration and Configuration Guide Hosts File Note: The term hosts file refers to the %SystemRoot%\System32\drivers\etc\hosts file on a Windows Single Point Operations sever, where %SystemRoot% is typically C:\WINNT. You use the hosts file on the Single Point Operations server to Specify the network name and network address of each MCP host system you want to mange from the server. Define a list of network names and their network addresses. Note: Use the same network name that you specify in the hosts file when you add an MCP host system to a Single Point Operations configuration or when you edit an MCP host system in a configuration. Format of the Hosts File The format of each line in the hosts file is network-address network-name [# comment] where: network-address is the Internet Protocol (IP) address number of the MCP host system. network-name is the name of the MCP host system. comment is any optional descriptive information about this entry. A # must precede the comment. Update the hosts file on the Single Point Operations server whenever you Add an MCP host system that is to be managed to the Single Point Operations network. Change the network IP address of an MCP host system in the Single Point Operations network. Change the network name of an MCP host system in the Single Point Operations network. You must update the hosts file before the interface to the system that you wish to monitor can be initialized

33 Preinstallation Tasks Note: Before attempting to use Single Point Operations, you should execute the Verify Configuration facility of the Single Point Operations Configuration application to ensure that the contents of the hosts and services files on the Single Point Operations server are consistent with the network data you specified in the configuration. You should also ensure that you can access the MCP system on the network Services Files Note: The term hosts file refers to the %SystemRoot%\System32\drivers\etc\services file on a Windows Single Point Operations sever, where %SystemRoot% is typically C:\WINNT Default MCP Service During installation of Single Point Operations, the services file on the Single Point Operations server is updated by adding the following lines: spo_mcp 10301/spo_msg spo_mcp /spo_msg These lines define the default MCP services named spo_mcp and spo_mcp2 with the default port numbers and Unless you must change the default port numbers or require different port numbers for different MCP hosts, you can disregard the information in Setting Up the Services File When setting up the services file on the Single Point Operations server, you must include in this file the following information for each unique MCP host port number used at your site: its service name its TCP port number that is assigned for the host system interface software service its service protocol name, which is a fixed name: spo_msg Format of the Services File The format for each line in the services file is service name port number/service protocol [# comment] where: service name can be any arbitrary name. The name you specify must be the same as the service name for the MCP host you specify in the Single Point Operations configuration. The default name is spo_mcp. However, you must specify a different service name for each port number that is assigned on the host side

34 Preinstallation Tasks port number is defined for each site and MCP host system. It must match the port number you specify for the DEFAULT_SOCKET parameter in the interface software configuration file. See Section 3 for additional information about the configuration file. service protocol is a fixed name (spo_msg). comment is any optional descriptive information about this entity. A # must precede the comment. For example, if an MCP host system with a service name of Mpls_003 has designated 5114 as its port number for the spo_msg service, the entry in the services file on the Single Point Operations server is Mpls_ /spo_msg After you have installed the interface software on MCP host system Mpls_003, you must enter the same port number for the DEFAULT_SOCKET parameter in the configuration file on this host system as follows: DEFAULT_SOCKET 5114 Port numbers you assign for spo_msg services must be unique only within a single MCP host system. On multiple MCP host systems, you can use the same number for one port on each host system. You would specify this number only once in the services file on the Single Point Operations server and specify it for the DEFAULT_SOCKET parameter for each managed MCP host system. For example, the default MCP services added when Single Point Operations level 7.3 or later is installed are spo_mcp 10301/spo_msg spo_mcp /spo_msg The default port number is specified as the value for DEFAULT_SOCKET in the configuration file supplied as part of the interface software. If you specify a different port number in the services file, you must change the value for DEFAULT_SOCKET in the configuration file on each managed MCP host system. Alternatively, you may assign different spo_msg port numbers for each MCP host system. Now you must make a separate entry in the services file on the Single Point Operations server for each MCP host system. For example Mpls_ /spo_msg Mpls_ /spo_msg Mpls_ /spo_msg StP_ /spo_msg

35 Preinstallation Tasks In this case, you must enter the corresponding port number as the value for DEFAULT_SOCKET in the interface software configuration file on each MCP host system connected to the Single Point Operations server. You must update the services file before the interface to the system that is to be managed can be initialized Assigning Usercodes Usercodes Add privileged usercodes to the USERDATAFILE file on each MCP host system to enable the following activities: Usercode-1: Used for automatic log-on (auto-logon) of Single Point Operations Console terminal emulation sessions in remote ODT mode. See Section 3 for a description of the AUTO_LOGON_USERCODE parameter in the configuration file. Usercode-1 is the same usercode you use to set up ODT terminal emulation sessions during Single Point Operations configuration. You must not use usercodes assigned for this purpose for any other purpose, because the log-on event causes the user terminal to go into remote ODT mode with the automatic display mode (ADM) active. SPOADM is the default usercode-1. If you use a different value, update AUTO_LOGON_USERCODE in the configuration file as described in Section 3. Usercode-2: Used for running the interface software program. This usercode should have privileged status and system user status. Usercode-2 must be the usercode that you specify during the installation of the interface software. See Section 3 for a description of how to install the software. Usercode-3: User for security validation of the port connection with the Single Point Operations server. This usercode should have privileged status and system user status. Usercode-3 is specified in the SP-AMS database on the Single Point Operations server and is sent to the interface software after the initial connection. It is necessary to validate that the device connected to the interface port is an authorized Single Point Operations server. The default value for usercode-3 is SPO. If you use a different value, update your SP-AMS databases accordingly. Notes: Usercode-1 must be different from usercode-2 and usercode-3. Usercode-2 and usercode-3 can be the same. It is recommended that usercode-3 have privileged status and system user status so that the port connection is qualified to run with the same privileges as the interface software program. The default configuration file supplied with the interface software requires that usercode-3 have privileged status and system user status. If, however, your site does not allow the utilization of privileged usercodes outside the MCP complex, a configuration option is available whereby