1.1 Manual Overview

1.2 NMS OAM Overview

1.3 OAM Components

1.3.1 OAM Supervisor

1.3.2 Board Plug-Ins

1.3.3 Extended Management Components (EMCs)

1.4 Managed Objects

1.4.1 The Configuration Database

1.4.2 Board Identification Methods

1.5 Accessing OAM Service Functions

1.5.1 oamsys

1.5.2 oamcfg

1.5.3 oammon

1.5.4 oaminfo

1.5.5 OAM Service API

1.6 Installing OAM

1.7 System Configuration Overview

1.1 Manual Overview

This manual describes how to set up a chassis containing NMS boards, and use NMS Operations, Administration, and Maintenance (OAM) software to configure, start (boot) and monitor the boards.

OAM functionality can be accessed in either of the following ways:

• Using the oamsys, oamcfg, oammon, and oaminfo utilities included with the OAM software. This manual describes how to access OAM this way.

• Using the OAM service API. The OAM service is a standard CT Access service, with an API similar to the APIs of other CT Access services. For more information on these utilities, refer to the OAM System User's Manual.

This document is targeted to developers and system administrators.

1.2 NMS OAM Overview

Natural MicroSystems Operations, Administration, and Maintenance (OAM) is an extension to CT Access which performs operations on, administration of, and maintenance of NMS resources in a system. OAM can manage hardware components, such as NMS boards, or software components, such as the NMS Hot Swap and H.100/H.110 clock management processes. Since these components are being managed by OAM, they are called managed components.

Using NMS OAM, you can:

• Create, delete, and query the configuration of a managed component

• Start (boot), stop (shut down), and test a managed component

• Receive notifications from managed components

1.3 OAM Components

OAM software is made up of the following components (see Figure 1):

• OAM Supervisor

• Board plug-ins

• Extended management components (EMCs)
  
  
  Figure 1. NMS Components

The following sections describe each component.

1.3.1 OAM Supervisor

This component provides the main OAM logic. It does the following:

• Loads all board plug-ins and EMCs when it starts up

• Coordinates the activities of managed components

• Manages a database containing configuration information for managed components (described in Section 1.4.1)

The OAM Supervisor is an integral part of the CT Access server process (ctdaemon). To use the OAM software, CT Access must be installed on your system, and ctdaemon must be running. To learn how to start ctdaemon, refer to Chapter 4.

1.3.2 Board Plug-Ins

OAM communicates with boards through software extensions called board plug-ins, one for each board family. The board plug-ins included with OAM support the following NMS PCI and CompactPCI board models: AG, CG, CX, and QX. TX boards are not supported.

When the Supervisor starts up, it loads all plug-ins that it finds. The Supervisor looks for these modules in the nms\bin directory (/opt/nms/lib under Unix). Plug-in files have the extension .bpi.

1.3.3 Extended Management Components (EMCs)

Extended management components (EMCs) are software modules which add functionality to OAM. The following EMCs are currently included with OAM:

• The Hot Swap EMC allows you to insert and extract Hot Swap-compatible CompactPCI boards without powering down the system. Hot Swap improves system availability by reducing down-time due to routine configuration changes and board replacements.

• The Clock Management EMC manages H.100 and H.110 bus clock configuration.

When the Supervisor starts up, it loads all EMCs that it finds. The Supervisor looks for these modules in the nms\bin directory (/opt/nms/lib under Unix). EMC files have the extension .emc.

1.4 Managed Objects

All components (board plug-ins and EMCs) logically exist as managed objects within OAM. (See Figure 2.) A managed object is the logical representation of a managed component to OAM.

Boards are also logically represented as managed objects. A board must exist as a managed object in order for OAM to configure or start it.

You can use OAM utilities or the OAM service API to access, query, and configure any managed object (see Section 1.5). You can also create and delete board managed objects.

Figure 2. Managed Objects and Managed Components

OAM can have managed objects that do not correspond to active or present managed components in the system. For example, you can have a managed object for an NMS board that is not in the chassis, although an error will result if an attempt is made to start that component. Conversely, not all NMS resources in the system may exist as managed objects within OAM.

The OAM Supervisor has a managed object. You can access the Supervisor managed object to query and configure various system-level parameters. For more information, refer to the OAM Service Developer's Reference Manual.

1.4.1 The Configuration Database

OAM maintains a configuration database to facilitate the management of the components under its control. Each hardware and software managed object has its own record in the database containing configuration parameters and parameter values. (See Figure 3.)

Figure 3. OAM Configuration Database

In the database, each parameter and value is expressed as a keyword name/value pair (for example, AutoStart = YES). You can query the OAM service for keyword values for any managed object. Keywords and values can be added, modified, or deleted.

1.4.2 Board Identification Methods

In the OAM system, each board is referenced using the following identifiers:

• A unique name.

• A board number. This is the typical way to identify a board in most NMS software products. Each board in a chassis has a unique board number.

• A unique PCI bus and slot in which the board is located.

The following secondary ID information is also available:

• A driver name/driver board ID combination. The driver name is unique among all driver names in the system. The driver board ID is unique among all boards accessed by a given driver. However, two boards accessed by different drivers may have the same driver board ID. The driver name/driver board ID together make up an ID for the board which is unique within the system.

• A serial number (if supported). This number is factory-configured, and may not be present for all boards.
  
  Figure 4. Board Identification Options

1.5 Accessing OAM Service Functions

You can access OAM functionality by using the:

• oamsys utility to perform system-wide configuration

• oamcfg utility to access individual OAM configuration functions

• oammon utility to perform OAM monitoring and alert notification functions

• oaminfo utility to retrieve and set keywords and values for a managed object

• OAM Service API to access all functionality programmatically

Figure 5 illustrates the relationships between these utilities and OAM:

Figure 5. OAM Utilities and OAM Service API

The following sections describe the utilities and API.

Note: To use any OAM utility, ctdaemon must be running, and must have the CT Access server started within it (see Chapter 4).

1.5.1 oamsys

To perform system-wide configuration and startup of managed components, use the oamsys utility. This utility creates managed objects and initializes the OAM database based on system configuration files you supply. It then attempts to start (boot) all boards which exist as managed objects.

Configuration parameter values for each managed object are listed in the system configuration file. If the managed object is a board, this information includes the board's ID information.

oamsys completely renews the database each time it runs, and restarts all boards. Any parameters not listed in the configuration file are reset to their default settings. Thus oamsys makes it easy to track the configuration of an entire system.

Note: oamsys is a rough functional equivalent of the agmon utility. For details, see Appendix B.

To perform its tasks, the oamsys utility makes multiple calls to the oamcfg utility, described in Section 1.5.2.

1.5.2 oamcfg

oamcfg provides access to individual OAM configuration functions. Using this utility, you can cause OAM to:

• Create or delete managed objects for boards

• Specify settings for managed object parameters, either individually, or many at once using keyword files

• Start (boot) or stop (shut down) one or more boards

• Test boards (if supported)

• Display basic ID information for board managed objects

You can direct oamcfg to perform one or more operations for a single managed object. Alternatively, the utility can perform operations on all board managed objects in the database with one call.

oamcfg should be used for individual managed object updates. oamcfg can be cumbersome if used to update many managed objects in a complex system. Use oamsys for this purpose.

1.5.3 oammon

The oammon utility allows access to OAM monitoring functions. Using oammon, you can:

• Monitor for board errors and other messages

• Capture these messages in a flat file

• Send a test alert notification message to all OAM client applications

1.5.4 oaminfo

The oaminfo utility allows you to access keywords from the command line. oaminfo can display all keywords for a managed object, or specific keywords and values. It can also search for text in keywords, and set keyword values. For more information about oaminfo, refer to the OAM Service Developer's Reference Manual.

1.5.5 OAM Service API

You can access OAM functionality programmatically using the OAM service API. OAM is implemented as a service under the CT Access development environment. CT Access provides standard programming interfaces for hardware-independent functions. Under CT Access, logically related functions (OAM operations, for example) are divided into groups, called services, which have similar APIs.

OAM utilities make calls to the OAM service API to perform their operations.

For detailed information about programming using the OAM service API, refer to the OAM Service Developer's Reference Manual.

1.6 Installing OAM

OAM is available as part of the Natural Access software package. This package is available on CD or on the NMS web site (www.nmss.com). To learn how to install the software, refer to the Natural Access installation booklet.

When OAM is installed, the following environment variables are set or modified automatically, unless you specify otherwise:

Environment Variable	Setting/Modification
AGLOAD	\nms\oam\cfg is appended to this variable (/opt/nms/oam/cfg in UNIX)
(UNIX only) LD_LIBRARY_PATH	/opt/nms/lib:/opt/nms/hotswap/lib (required by Hot Swap Manager)

Under Windows NT, the following service is registered:

• NMS Clock Fallback Manager

• NMS HotSwap Manager
  Note: Make sure to check the readme files included with the software for late-breaking information on all hardware and software products.

1.7 System Configuration Overview

Once you have installed the software, follow these steps to set up an OAM system:

Step	Description	Documented In...
1.	Make sure that your chassis is set up properly for Hot-Swapping boards. (Required only if you are using Hot Swap.)	Chapter 2
2.	Create a system configuration file describing your system. In this file, give each board a unique name and board number.	Chapter 3
3.	If your system contains two or more boards connected through the H.100 or H.110 bus, configure clocking on the bus.	Appendix A
4.	Start ctdaemon, if it is not already running. Also start the Hot Swap driver and manager.	Chapter 4
5.	Use oamsys to create managed objects and initialize the OAM database based upon the system configuration file, and to start all installed boards. Each configured board is now managed by OAM. To reference the board in the OAM service API or utilities, you can use either its name or its number.	Chapter 5