bmc impact solutions: general administration · bmc, bmc software, and the bmc software logo are...

www.bmc.com

BMC Impact Solutions:General Administration

Supporting

BMC Impact Manager version 7.1 BMC Impact Explorer version 7.1 BMC Impact Portal version 7.1

October 2007

Contacting BMC Software

You can access the BMC Software website at http://www.bmc.com. From this website, you can obtain information about the company, its products, corporate offices, special events, and career opportunities.

United States and Canada

Address BMC SOFTWARE INC2101 CITYWEST BLVDHOUSTON TX 77042-2827 USA

Telephone 713 918 8800 or800 841 2031

Fax 713 918 8000

Outside United States and Canada

Telephone (01) 713 918 8800 Fax (01) 713 918 8000

© Copyright 2006–2007 BMC Software, Inc.

BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S. Patent and Trademark Office, and may be registered or pending registration in other countries. All other BMC trademarks, service marks, and logos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are the property of their respective owners.

IBM is a registered trademark of International Business Machines Corporation.

ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office.

Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.

Oracle is a registered trademark of Oracle Corporation.

Sun, Java, and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc., in the U.S. and several other countries.

UNIX is a registered trademark of The Open Group.

BMC Software considers information included in this documentation to be proprietary and confidential. Your use of this information is subject to the terms and conditions of the applicable End User License Agreement for the product and the proprietary and restricted rights notices included in this documentation.

Restricted rights legendU.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE COPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the U.S. Government is subject to restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS 252.227-7014, DFARS 252.227-7015, and DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer is BMC SOFTWARE INC, 2101 CITYWEST BLVD, HOUSTON TX 77042-2827, USA. Any contract notices should be sent to this address.

http://www.bmc.com

3

Customer support

You can obtain technical support by using the BMC Software Customer Support website or by contacting Customer Support by telephone or e-mail. To expedite your inquiry, see “Before contacting BMC.”

Support website

You can obtain technical support from BMC 24 hours a day, 7 days a week at http://www.bmc.com/support_home. From this website, you can

■ read overviews about support services and programs that BMC offers■ find the most current information about BMC products■ search a database for issues similar to yours and possible solutions■ order or download product documentation■ download products and maintenance■ report an issue or ask a question■ subscribe to receive proactive e-mail alerts when new product notices are released■ find worldwide BMC support center locations and contact information, including e-mail addresses, fax numbers, and

telephone numbers

Support by telephone or e-mail

In the United States and Canada, if you need technical support and do not have access to the web, call 800 537 1813 or send an e-mail message to [email protected]. (In the subject line, enter SupID:<yourSupportContractID>, such as SupID:12345). Outside the United States and Canada, contact your local support center for assistance.

Before contacting BMC

Have the following information available so that Customer Support can begin working on your issue immediately:

■ product information

— product name— product version (release number)— license number and password (trial or permanent)

■ operating system and environment information

— machine type— operating system type, version, and service pack or other maintenance level such as PUT or PTF— system hardware configuration— serial numbers— related software (database, application, and communication) including type, version, and service pack or

maintenance level

■ sequence of events leading to the issue

■ commands and options that you used

■ messages received (and the time and date that you received them)

— product error messages— messages from the operating system, such as file system full— messages from related software

http://www.bmc.com/support_home

mailto:[email protected]

4 BMC Impact Solutions: General Administration

Contents

Part 1 General configuration and administration 29

Chapter 1 General configuration information 31

General configuration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Enabling integration between BMC Impact Solutions components and other BMC

components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Chapter 2 Managing BMC Impact Manager cells 35

BMC Impact Manager overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36BMC Impact Manager cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36BMC Impact Manager Knowledge Base (KB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39BMC Impact Manager event repository and State Builder . . . . . . . . . . . . . . . . . . . 40BMC Impact Manager command line interface (CLI) . . . . . . . . . . . . . . . . . . . . . . . 40

Starting or stopping the cell - mcell and mkill. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Stopping or starting a cell on UNIX computers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Starting or stopping a cell on Windows computers . . . . . . . . . . . . . . . . . . . . . . . . . 41

Cell configuration tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Configuring mcell.conf parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Creating cell-specific configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Configuring cells to communicate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Configuring high availability cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Configuring event slot propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Configuring passive connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Configuring slots for time stamping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Configuring encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Reloading cell configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Monitoring event performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Monitoring client to cell interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Configuring cell tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Configuring mcell.trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Configuring a destination for cell trace output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Sending trace output to another cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Event processing errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Automatic notification of trace configuration changes . . . . . . . . . . . . . . . . . . . . . . 78

Interpreting cell execution failure codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Using the BMC IX Administration view to manage cells . . . . . . . . . . . . . . . . . . . . . . . 80

Connecting or disconnecting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Viewing cell information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Contents 5

Controlling cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Reloading cell configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Forcing event propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Registering for SIM notification events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Collecting metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Chapter 3 Managing the BMC Impact Administration server 89

Overview to BMC Impact Administration server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Master or Standard BMC Impact Administration server . . . . . . . . . . . . . . . . . . . . 90Starting and stopping the BMC Impact Administration server . . . . . . . . . . . . . . . 91Configuration files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Command line interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Impact Administration cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

How to configure BMC Impact Administration server files . . . . . . . . . . . . . . . . . . . . . 94Guidelines for manual edits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94How groups, roles, and permissions are related . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Defining group roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Defining permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Receiving synchronized data from the BMC Portal . . . . . . . . . . . . . . . . . . . . . . . . 102File-based authentication: updating user information. . . . . . . . . . . . . . . . . . . . . . 103Synchronizing cell information with BMC Atrium CMDB. . . . . . . . . . . . . . . . . . 105Updating cell information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Editing logging properties for IAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Defining client logging for the iadmin script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Customizing colors for severities, statuses, and priorities . . . . . . . . . . . . . . . . . . 109Defining standalone, primary, and secondary BMC Impact Administration

servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Defining an HA configuration for the Impact Administration cell . . . . . . . . . . . 112Transaction and trace logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Advanced tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Configuring the BMC Impact Administration server to support remote

actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Configuring Lightweight Directory Access Protocol for BMC Impact

Administration server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Chapter 4 Managing the BMC Impact Portal 125

Accessing the BMC Impact Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Starting and stopping the BMC Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Starting and stopping the BMC Portal on Windows . . . . . . . . . . . . . . . . . . . . . . . 127Starting and stopping the BMC Portal on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Configuration tasks for BMC Impact Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Registering production and test cells in the BMC Impact Portal . . . . . . . . . . . . . 128Customizing BMC Impact Portal configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Configuring Dashboard Table View columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Configuring Events Table columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Changing the Console Navigation Tree icons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Configuring Status Table columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Configuring object link synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Contents 6

Configuring reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Configuring the number of events displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Changing the maximum number of recent items displayed . . . . . . . . . . . . . . . . 134Configuring the general properties displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Setting up Image Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Modifying connection settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Configuration file and parameter definitions for BMC Impact Portal. . . . . . . . . . . . 137smsIwc/application.properties file and parameters . . . . . . . . . . . . . . . . . . . . . . . 137smsConsoleServer/application.properties file and parameters. . . . . . . . . . . . . . 138ixs.properties file and parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Chapter 5 Managing the BMC Impact Explorer (BMC IX) console 143

Connecting BMC IX to a BMC Impact Portal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Specific configuration tasks in BMC IX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Defining a user’s home directory on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Defining property files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Defining console-wide policy files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Configuring display and connection settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Defining global event severity and priority color values . . . . . . . . . . . . . . . . . . . 151Event group configuration files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152XML files that define user interface elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Chapter 6 Working with Infrastructure Management 155

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Default Infrastructure Management service model . . . . . . . . . . . . . . . . . . . . . . . . 156Roles and permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Walkthrough. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Displaying the out-of-the-box real-time service model . . . . . . . . . . . . . . . . . . . . . 158Sampling context-sensitive information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160Managing files on remote systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161Packaging support files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162Launching remote actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Common Infrastructure Management tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Navigating the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Displaying and understanding the Details and Administer tab data . . . . . . . . . 169Editing infrastructure relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173Creating logical components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Deleting components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Executing remote actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Executing other actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179Configuring the audit log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179Creating the support package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Background to Infrastructure Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185Impact Administration cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185Impact Administration server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186Unidirectional event flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186Remote actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Contents 7

Chapter 7 Configuring BMC Impact Event Adapters 191

Configuration overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Adapter definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Configuration tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

About the mcxa.conf file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196Configuration file structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196Configuration file definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198msend command configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Parameter types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Global parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200Common parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202Specific parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Applying configuration changes during run-time . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211BMC Impact Event Log Adapter for Windows configuration. . . . . . . . . . . . . . . . . . . 211

Chapter 8 Defining presentation names 213

Presentation names overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214Presentation name resource file locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214Default presentation name definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Creating a new presentation name resource file . . . . . . . . . . . . . . . . . . . . . . . . . . . 216Presentation name resource files search order . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Defining presentation names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218Creating or modifying presentation name keys . . . . . . . . . . . . . . . . . . . . . . . . . . . 218Digitally signing a .jar file with a digital test certificate. . . . . . . . . . . . . . . . . . . . . 220

Enabling or disabling presentation names inBMC Impact Explorer tool tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Chapter 9 Configuring StateBuilder and gateways 223

Understanding the StateBuilder and gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224StateBuilder configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225statbld return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225Gateway configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

Exporting events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231Modifying a statbld.conf file to export events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231Modifying a gateway.export file to export events . . . . . . . . . . . . . . . . . . . . . . . . . 232

Configuring tracing for StateBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

Part 2 Event management administration 235

Chapter 10 Event management overview 237

Event management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237Event collection sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238Event management in BMC Impact Explorer console . . . . . . . . . . . . . . . . . . . . . . 239Event flow for service impact management and event management . . . . . . . . . 241

BMC Impact Explorer Administration View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242Event management policy definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243


Dynamic data definition using the Dynamic Data Editor. . . . . . . . . . . . . . . . . . . 243BMC Impact Manager cell management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Chapter 11 Working with the Dynamic Data Editor 245

About data classes and dynamic data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246Dynamic data definition using the Dynamic Data Editor. . . . . . . . . . . . . . . . . . . 246

Navigating the Dynamic Data Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246Navigation pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247Toolbar functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

Filtering and sorting the Data List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248Filtering slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248Sorting data fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

Working with data instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252Extended Details tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253Internals tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253Data instance context menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253Adding a new data instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253Editing slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255Exporting data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

Chapter 12 Implementing event management policies 259

What is an event management policy? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260How an event management policy differs from a rule . . . . . . . . . . . . . . . . . . . . . 261When to use an event management policy rather than a rule . . . . . . . . . . . . . . . 261Event management policy types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261How standard event management policies differ from dynamic data enrichment

policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263Out-of-the-box event management policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264How event management policies work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

Event management policy workflow overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 265Event selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266Event selector groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266Event selection criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267Timeframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268Evaluation order of event policy types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269Compiling event policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

How dynamic data enrichment event management policies work . . . . . . . . . . . . . . 270How to create a new local timeframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274How to add a notification service (notification policies only). . . . . . . . . . . . . . . . . . . 276How to create and edit a dynamic data enrichment source file . . . . . . . . . . . . . . . . . 277

Using the sample PATROL messaging text translation dynamic data enrichment source file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

How to create an event selector and specify event selection criteria . . . . . . . . . . . . . 281Creating new standard event management policies. . . . . . . . . . . . . . . . . . . . . . . . . . . 285

Creating a new standard blackout policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285Creating a new closure policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288Creating a new correlation policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291Creating a new enrichment policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

Contents 9

Creating a new escalation policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297Creating a new notification policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302Creating a new propagation policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306Creating a new recurrence policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308Creating a new suppression policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311Creating a new threshold policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313Creating a new timeout policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

Enabling and disabling out-of-the-box standard event management policies . . . . . 320Creating a new dynamic data enrichment event management policy . . . . . . . . . . . . 321Enabling out-of-the-box dynamic data enrichment event management policies . . . 332

Enabling a dynamic data enrichment blackout policy . . . . . . . . . . . . . . . . . . . . . . 333Enabling a dynamic data enrichment location policy . . . . . . . . . . . . . . . . . . . . . . 336Enabling a dynamic data enrichment service contact policy . . . . . . . . . . . . . . . . 340Enabling a dynamic enrichment PATROL message text translation policy . . . . 343

Importing dynamic data enrichment source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347Verifying that the policy is running. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348Editing event selection criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348Deleting an event selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

Chapter 13 Creating and implementing user-defined policies 351

Understanding user-defined event policy types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352Understanding event processing rules (MRL) for policy types. . . . . . . . . . . . . . . . . . 352

Format of event processing rules for policy types . . . . . . . . . . . . . . . . . . . . . . . . . 352How a rule for a policy type is processed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353Sources of information about rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

User-defined event policy type creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354Creating user-defined policy types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354Defining the policy data class for a new policy type . . . . . . . . . . . . . . . . . . . . . . . 354Defining presentation names for a new policy type . . . . . . . . . . . . . . . . . . . . . . . . 356Creating the event processing rule(s) for a new policy type . . . . . . . . . . . . . . . . . 357

Chapter 14 Building event groups and image views 359

Understanding event groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360Types of event groupings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360Event group configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361Event tree hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362Event tree objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

Understanding image views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363Planning event groups and image views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364Working with event groups and image views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365

Creating an event group (event tree top-level) node . . . . . . . . . . . . . . . . . . . . . . . 365Creating an event group subnode (event tree node) . . . . . . . . . . . . . . . . . . . . . . . 366Deleting an event group subnode (event tree top-level node) . . . . . . . . . . . . . . . 367Hiding a collector in an event group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367Showing a hidden collector in an event group . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368Putting an event group into production or development . . . . . . . . . . . . . . . . . . . 368Adding a custom image view to an event group . . . . . . . . . . . . . . . . . . . . . . . . . . 369

Granting user access to event groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371


Part 3 Appendixes 373

Appendix A Trouble-shooting 375

Trouble-shooting BMC Impact Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375Problem: The cell will not start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375Problem: The primary and secondary servers for my high availability cell are in

active mode simultaneously or are unsynchronized. . . . . . . . . . . . . . . . . . . . . 376Problem: There are two notification objects from the Impact Portal in the cell. 377

Trouble-shooting event management policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377Problem: The policy is not running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377Problem: The notification policy is configured to generate a notification email,

but no email is being sent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378Problem: I receive an invalid data error when running a dynamic data

enrichment policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378Problem: I receive an error message when running a dynamic data enrichment

blackout policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379Trouble-shooting tools for dynamic data enrichment policies . . . . . . . . . . . . . . . 380

Appendix B BMC SIM and EM CLI Reference 381

BMC Impact Manager CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382BMC Impact Manager CLI common command options . . . . . . . . . . . . . . . . . . . . 383BMC Impact Manager CLI common return codes . . . . . . . . . . . . . . . . . . . . . . . . . 384mccomp—Compiling rules in the Knowledge Base. . . . . . . . . . . . . . . . . . . . . . . . 385mcell—Starting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386mcfgtrace—Configuring tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389mclassinfo—Requesting class information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390mcollinfo—Getting information about a specific collector . . . . . . . . . . . . . . . . . . 396mcontrol—Performing cell control operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398mcrtcell—Creating a new cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401mcstat—Returning cell status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405mdelcell—Deleting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406mgetinfo—Retrieving information about a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . 408mgetrec—Obtaining a global record value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412mkb—Updating the Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414mkill—Stopping a cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417mlogchk—Performing consistency checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418mpkill—Stopping mposter and msend server processes . . . . . . . . . . . . . . . . . . . 420mposter and msend—Managing data, global records, and events . . . . . . . . . . . 422mquery—Retrieving objects from a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427mrecover—Recovering from a catastrophic data loss . . . . . . . . . . . . . . . . . . . . . . 432mrextract—Extracting cell state files to create new state files . . . . . . . . . . . . . . . 434mrmerge—Merging event objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436msetmsg—Modifying an event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437msetrec—Setting the value of a global record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439BMC Impact Manager CLI configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440Configuring tracing for BMC Impact Manager CLI commands . . . . . . . . . . . . . 442BMC Impact Manager CLI trace configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 442

Contents 11

Appendix C mcell.conf file parameters 443

Action result event parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444Cell configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444Cell failover configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446Client communication parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447Encryption parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449Event repository cleanup parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450Heartbeat parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452Internal cell monitor parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455KB parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455Propagation parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456Reporting client connection parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459Service model parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460StateBuilder parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460Trace parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461

Appendix D Environment variables 465

Microsoft Windows environment variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466Recreating environment variables on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466UNIX environment variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467Recreating environment variables on UNIX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467

Appendix E BMC Microsoft Windows services and UNIX processes 469

BMC Microsoft Windows services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470BMC UNIX processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470

Appendix F BMC Impact Event Adapters MAP files 473

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473Default MAP files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474Custom maps and map-related files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474

Custom MAP files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474Customized Perl MAP-functions file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475

MAP file structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475Directives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486

Appendix G IP Adapters 489

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489IP Adapter architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490IP Adapters configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490IP Adapter types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491

TCP Client Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491TCP Server Adapter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494Telnet Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496UDP client Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500UDP server Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503


Appendix H BMC Impact Event Adapters parsers 505

What a parser does. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505LogFile, Perl EventLog for Windows, and SNMP Adapter parsers. . . . . . . . . . . . . . 505IP Adapter parsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507

Specifying a CSV parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507Specifying a Fixed-width (column) parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509Specifying Record and Field separated parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514

Appendix I Backend processes for publishing and unpublishing MIB files 517

The publish MIB files back-end process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517The unpublish MIB files back-end process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518

Glossary 521

Index 555

Contents 13

FiguresAttribute Precedence information for enabling integration . . . . . . . . . . . . . . . . . . . . . 33ConnectionPortRange syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Format of an entry in the mcell.dir file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Example of the mcell.dir file and its entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Distributed event management using event propagation . . . . . . . . . . . . . . . . . . . . . . 61Passive connection format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Data object specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63mcell.modify file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Masking syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Format of configuration line in mcell.trace file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Excerpt from ldap_configuration.xml file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117default.econ.config file contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Operator.econ.config file contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Default policy file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Default Infrastructure Management service model . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Infrastructure Management navigation pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Default service model BMC Impact Solutions (with active services) . . . . . . . . . . . . 160Edit Relationships dialog with Edit This Relationship subdialog . . . . . . . . . . . . . . . 174Actions right-click menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177High availability (HA) view: two cell servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178mcxa.conf file structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197Parameter and value examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Listing of the contents of a keystore file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221Parameters used to print event in BAROC format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230Example of printed events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230Command to configure the export file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231gateway.export file format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232gateway.explore file output for new events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232gateway.explore file output for modified events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233Service impact and event management process flow . . . . . . . . . . . . . . . . . . . . . . . . . 242Dynamic Data Editor Navigation Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247Dynamic Data Editor toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248Slot Quick Filter dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249Unfiltered data list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250Type field list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254Message bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254New data instance created with the New Copy option . . . . . . . . . . . . . . . . . . . . . . . 255Type field List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255Export Data dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256Export Data dialog box—Selecting the data format . . . . . . . . . . . . . . . . . . . . . . . . . . 256

Figures 15

Contents of mcdata.csv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257Export file containing four data instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257Event management policy definition workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265Event selector group name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267Flow of data required to implement a dynamic data enrichment policy . . . . . . . . . 270Default PMEP event classes and slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273Timeframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274Timeframe Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275Example edited location.csv file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278Sample rows in the TextTranslation.csv file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280Variable syntax example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281Selector Details tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282Class Chooser dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283Selection Definition section of the Add Event Criteria editor . . . . . . . . . . . . . . . . . . . 284Example event selection criteria expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284Completed event selection criteria in Selector Details tab . . . . . . . . . . . . . . . . . . . . . . 284Blackout Policy Details tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287Closure Policy Details tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289Correlation Policy Details tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292Enrichment Policy Details tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295Escalation Policy Details tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299Time Escalation Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301Rate of Event Arrival Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302Notification Policy Details tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304Propagation Policy Details tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307Propagation cell list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308Recurrence Policy Details tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310Suppression Policy Details tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312Threshold Policy Details tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315Hold Events options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316Pass Events Through options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317Timeout Policy Details tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318List of event management policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320Dynamic Enrichment Policy Details tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323Import confirmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326Dynamic Blackout Policy Details tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328Import confirmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331Dynamic Blackout Policy Details tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334Import Data Confirmation dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336List of out-of-the-box dynamic data enrichment policies . . . . . . . . . . . . . . . . . . . . . . 337Dynamic Enrichment Policy Details tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338Import confirmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340List of out-of-the-box dynamic data enrichment policies . . . . . . . . . . . . . . . . . . . . . . 340Dynamic Enrichment Policy Details tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341Import confirmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343List of out-of-the-box dynamic data enrichment policies . . . . . . . . . . . . . . . . . . . . . . 344Dynamic Enrichment Policy Details tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345Import confirmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346Import tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347


History tab showing executed dynamic data enrichment policy . . . . . . . . . . . . . . . 348Event tree hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362Image view widgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363Custom image view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364Event Group editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365Event tree node addition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366Image View editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370Invalid data error: dynamic enrichment policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379Invalid timeframe error: dynamic blackout policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 379mccomp syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385mccomp example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386Example output for mccomp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386mcell syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386Starting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387Starting a cell as a service on windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388Starting the BMC Impact Manager service on Microsoft Windows . . . . . . . . . . . . . 388mcfgtrace syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389mcfgtrace example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390mclassinfo syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391Raw output format for mclassinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391Class tree for mclassinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392Example of mclassinfo command for a list of classes . . . . . . . . . . . . . . . . . . . . . . . . . 393Example output of mclassinfo command for a list of classes . . . . . . . . . . . . . . . . . . . 393Example of mclassinfo command for list of classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 394Example of mclassinfo command output for list of classes . . . . . . . . . . . . . . . . . . . . 394Example of mclassinfo command for adding slot names . . . . . . . . . . . . . . . . . . . . . . 394Example of mclassinfo command output for adding slot names . . . . . . . . . . . . . . . 395Example of mclassinfo command for adding slot flags . . . . . . . . . . . . . . . . . . . . . . . 395Example of mclassinfo command output for adding slot flags . . . . . . . . . . . . . . . . . 395mcollinfo syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396Raw output format for mcollinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397mcollinfo example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397mcollinfo command for verbose mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398mcollinfo command for number of events for severity/status . . . . . . . . . . . . . . . . . 398mcontrol syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398Retrying Pending propagations with mcontrol command . . . . . . . . . . . . . . . . . . . . . 400Example of mcontrol command output for retrying pending propagations . . . . . . 400Terminating a cell using the mcontrol command . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400Example of mcontrol command output for terminating a cell . . . . . . . . . . . . . . . . . . 401Reconfiguring a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401Example of mcontrol command output for reconfiguring a cell . . . . . . . . . . . . . . . . 401mcrtcell syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403Example of mcrtcell command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404Example of output of mcrtcell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404Example of mcrtcell command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404Example output of mcrtcell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404mcstat syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405mcstat example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406Message for cell not running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406

Figures 17

Message for cell running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406mdelcell syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407Deleting a cell using mdelcell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407Output for mdelcell if cell is not running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407Output for mdelcell if cell is running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407mgetinfo syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408Example of mgetinfo config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410mgetinfo config command output on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410mgetinfo config command output on Microsoft Windows . . . . . . . . . . . . . . . . . . . . . 411Example of mgetinfo param . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411mgetinfo param command output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411Example of mgetinfo services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411mgetinfo param command output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412Example of mgetinfo services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412Output of mgetinfo connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412mgetrec syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413Example of mgetrec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413Output of mgetrec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413mkb syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414mkb command on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416mkb output on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416mkb command on Microsoft Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417mkb command output on Microsoft Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417mkill syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417Example of mkill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418Output of mkill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418mlogchk syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419Example of mlogchk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419Output of mlogchk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419mlogchk message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420mpkill syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420Example of mpkill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421Output of mpkill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421mposter syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422msend syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423Example of mposter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424mposter BAROC-style input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424mposter BAROC-style output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424mposter BAROC-style input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424mposter BAROC-style output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425Definition changes using mposter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425Enabling persistent buffering using mposter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425Supplying a list of cells for mposter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426Error message if buffers files are not writable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426mquery syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427Example of raw output specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429Verbose mode options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429End of form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429Special BAROC format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429


Example of mquery—Select events with severity status . . . . . . . . . . . . . . . . . . . . . . 431Example of mquery—Select events from collector . . . . . . . . . . . . . . . . . . . . . . . . . . . 432Deleting events using mquery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432mrecover syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433Fixing a broken cell using mrecover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434mrextract syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435Example of mrextract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435mrmerge syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436Example of mrmerge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436msetmsg syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437Using msetmsg to close an event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438msetrec syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439Example of msetrec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439command to send tracing output to text file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442Example of Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453Comments code example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477Slot assignment formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478INIT structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483DEFAULT structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483CLASS leaf structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484Nested class mapping Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484Class name example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485mcsyslogd.map file excerpt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486Map call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487Sample TCP Client Adapter configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493Sample TCP server adapter Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495Sample Telnet Adapter configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499Sample UDP client Adapter configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502Sample UDP Server Adapter configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504Sample CSV parser specification example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509Fixed-width parser specification example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512Record and Field Separated Parser Specification Example . . . . . . . . . . . . . . . . . . . . 516

Figures 19

Figures 21

TablesBMC Impact Solutions configuration process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Cell configuration tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Substitution parameters for %X in path value parameters . . . . . . . . . . . . . . . . . . . . . . 45Default mcell.propagate options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60IP Address parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Files for cell reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69MC_CELL_METRIC slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Default values for client parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72MC_CELL_CLIENT slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72MC_CELL_MODIFIED_EVENT slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Trace configuration file parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74MC_CELL_PROCESS_ERROR slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78BMC Impact Manager exit codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79SIM_NOTIFICATION_REGISTRY dialog box fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 86iadmin options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Groups and roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95BMC Impact Explorer user group mapping to functionality . . . . . . . . . . . . . . . . . . . 98Cell entry format in cell_info.list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Server logging properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108IAS synchronization properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110mcell.dir entries for HA pair of Impact Administration cells . . . . . . . . . . . . . . . . . . 112IAS log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113LDAP configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Event operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Event Table column default values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Status table column default values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Report parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133application.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137application.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139aggregator.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140ixs.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141default.console_policy.prop parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Property descriptions from ix.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Event severity levels and colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151Event priority levels and colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152Event group configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153xml files that define user interface elements in BMC IX . . . . . . . . . . . . . . . . . . . . . . . 153Supported application groups in version 7.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Icon listing for infrastructure management model . . . . . . . . . . . . . . . . . . . . . . . . . . . 167Slot values: Details: General subtab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Tables 23

Slot values: Details: Other subtab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170Edit Relationship dialog: field descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Edit This Relationship subdialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Audit log parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179Audit log IAS properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Slots for specifying support files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183run_state values for components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187Component state and menu options: normal or primary cell in an HA configuration

188Component state and menu options: secondary cell in an HA configuration . . . . . 188Components and actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189Adapter configuration tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193Parameter types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200Global parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200Common parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203Perl EventLog Adapter for Windows parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205LogFile Adapter parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206SNMP Adapter parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210Windows Event Log Adapter parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212Presentation names for BMC Impact Solution interfaces . . . . . . . . . . . . . . . . . . . . . . 214Presentation name key formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218StateBuilder file name conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224statbld.conf Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225statbld return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225Gateway configuration parameter predefined variables . . . . . . . . . . . . . . . . . . . . . . . 227Gateway Configuration Parameter Text Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227gateway.export file parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228BMC Impact Explorer Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239Administration tab navigation pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247Standard event management policy types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262Out-of-the-box policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264Out-of-the-box event selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266Timeframe types and descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268Evaluation order of event policy types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269Dynamic data enrichment source files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272Enrichment configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272Timeframe Edit dialog options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275Standard event management policy types and procedures . . . . . . . . . . . . . . . . . . . . 285Cause Event tab controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293Out-of-the-box dynamic data enrichment event policy types and procedures . . . . 332Import tab uneditable fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347Policy Type Creation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354Event group configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361Event tree objects and definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363BMC Impact Manager CLI command descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . 382Common options for CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383Common return codes for CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384mccomp options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385mcell options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387


mcell return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388mcfgtrace option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389mcfgtrace parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390mclassinfo options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391Type of slot value for mclassinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392Reported facets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392Class flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393Information amount limitation options for mclassinfo . . . . . . . . . . . . . . . . . . . . . . . . 393mclassinfo return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395mcollinfo options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396Information amount limitation options for mcollinfo . . . . . . . . . . . . . . . . . . . . . . . . . 397mcollinfo return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398mcontrol option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399mcontrol controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399Files for UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403mcrtcell options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403mcrtcell return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405mcstat option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405mdelcell options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407mdelcell return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408mgetinfo option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408mgetinfo information options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409Information from connect request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409mgetinfo return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412mgetrec option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413mkb options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414mkb new file options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415mkill option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418mlogchk return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420mpkill option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421mposter and msend options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423mposter and msend return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427mquery options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428mquery query options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430mquery return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432mrecover option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433mrecover return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434mrextract options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435mrextract return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435mrmerge options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436mrmerge return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437msetmsg options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437msetmsg return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438msetrec options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439msetrec return codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440BMC Impact Manager CLI configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . 440Action result event parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444Cell configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444Cell failover configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446

Tables 25

Client communication parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447Date and time format parameters for Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448Encryption parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449Event Repository cleanup parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450Heartbeat parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452Heartbeat slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454Internal cell monitors parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455KB parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455Propagation parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456Deprecated MessageBuffer propagation parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 458Reporting client connection parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 Service model parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460StateBuilder parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460Cell tracing parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461Microsoft Windows environment variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466UNIX environment variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467BMC Microsoft Windows services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470BMC UNIX processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470Default MAP files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474Default map functions Perl files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475Slot Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481TCP Client Adapter configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491TCP server Adapter configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494Telnet adapter configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497UDP client Adapter configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500UDP Server Adapter configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503CSV parser parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508Fixed-Width parser parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510Record and field separated parser parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515


Tables 27

1Part

Part 1General configuration and administration

This part presents the following topics:

Chapter 1General configuration information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Chapter 2Managing BMC Impact Manager cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Chapter 3Managing the BMC Impact Administration server . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Chapter 4Managing the BMC Impact Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Chapter 5Managing the BMC Impact Explorer (BMC IX) console . . . . . . . . . . . . . . . . . . . . . 143

Chapter 6Working with Infrastructure Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Chapter 7Configuring BMC Impact Event Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Chapter 8Defining presentation names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

Chapter 9Configuring StateBuilder and gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

Part 1 General configuration and administration 29

C h a p t e r 1
1 General configuration information
This chapter contains general information about configuring the BMC Impact Solutions and contains the following topics:

General configuration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Enabling integration between BMC Impact Solutions components and other BMC

components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

General configuration overviewTo configure the BMC Impact Solutions environment, you configure the following components after installation:

■ BMC Impact Manager cell■ BMC Impact Explorer■ BMC Impact Portal

Table 1 outlines the tasks that configure these components.

Table 1 BMC Impact Solutions configuration process (part 1 of 2)

Task Description Component For more information, see

1 Configure the BMC Impact Portal. BMC Impact Portal BMC Portal Getting Started

2 Configure BMC Impact Manager cells. BMC Impact Manager Chapter 2, “Managing BMC Impact Manager cells”

3 Define user groups for access to the console functions and objects.

BMC Portal BMC Portal Getting Started


General configuration overview

After you configure BMC Impact Manager, BMC Impact Portal, and BMC Impact Explorer, you are ready to implement event management and service impact management. For information, consult the following resources:

■ Event management

— For information about setting up adapters to collect events, see the BMC Impact Solutions: Event Monitoring Operator’s Guide.

— For information about setting up dynamic data, policies, event groups, and image views, see Part 2, “Event management administration”on page 235.

— For information about defining event data, writing event management rules, defining collectors, or creating actions, see BMC Impact Solutions: Knowledge Base Development Reference Guide.

■ Service impact management

— For information about monitoring service impact management, see BMC Impact Solutions: Service Monitoring User Guide.

— For information about defining service models, see the BMC Impact Solutions: Service Model Administrator’s Guide.

4 Distribute the BMC Portal URL address so users can get an account and install consoles.

BMC Impact Explorer can be deployed as a Java Web Start application from BMC Impact Portal or installed standalone.

■ BMC Impact Portal■ BMC Impact Explorer■ BMC Impact Service

Model Editor

BMC Portal Getting Started

BMC Impact Solutions: Installation

5 (optional) Customize BMC Impact Portal. BMC Impact Portal Chapter 4, “Managing the BMC Impact Portal”

6 (optional) Customize BMC Impact Explorer. BMC Impact Explorer Chapter 5, “Managing the BMC Impact Explorer (BMC IX) console”

7 (optional) Configure the StateBuilder, which manages the persistent storage of events.

BMC Impact Manager Chapter 9, “Configuring StateBuilder and gateways”

8 (optional) Customize the labels used in the console interfaces.

■ BMC Impact Portal■ BMC Impact Manager■ BMC Impact Service

Model Editor

Chapter 5, “Managing the BMC Impact Explorer (BMC IX) console”

Table 1 BMC Impact Solutions configuration process (part 2 of 2)

Task Description Component For more information, see


Enabling integration between BMC Impact Solutions components and other BMC components


If you want to merge and reconcile data between BMC Impact Solutions applications and the BMC Asset Management, BMC Topology Discovery, or BMC Configuration Discovery products, you must add the ComponentAliases attribute to the existing precedence groups for these products.

To add the ComponentAliases attribute, follow the procedure for creating a precedence group in the BMC Atrium CMDB Installation and Configuration Guide for each product that you want to use with BMC Impact Solutions applications. The precedence groups for the BMC Asset Management, BMC Topology Discovery and BMC Configuration Discovery products are

■ BMC Asset Management – Sandbox Precedence■ BMC Topology Import - Precedence Group■ Configuration Discovery Precedence

Complete the Attribute Precedence dialog box for each precedence group as shown in Figure 1:

Figure 1 Attribute Precedence information for enabling integration


C h a p t e r 2
2 Managing BMC Impact Manager cells
This chapter describes how to manage and configure BMC Impact Manager cells.

BMC Impact Manager overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36BMC Impact Manager cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36BMC Impact Manager Knowledge Base (KB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39BMC Impact Manager event repository and State Builder . . . . . . . . . . . . . . . . . . . 40BMC Impact Manager command line interface (CLI) . . . . . . . . . . . . . . . . . . . . . . . 40

Starting or stopping the cell - mcell and mkill. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Stopping or starting a cell on UNIX computers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Starting or stopping a cell on Windows computers . . . . . . . . . . . . . . . . . . . . . . . . . 41

Cell configuration tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Creating cell-specific configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Configuring mcell.conf parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Configuring cells to communicate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Configuring high availability cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Configuring event slot propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Configuring passive connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Configuring slots for time stamping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Configuring encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Reloading cell configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Monitoring event performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Monitoring client to cell interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Configuring cell tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Configuring mcell.trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Configuring a destination for cell trace output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Sending trace output to another cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Event processing errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Automatic notification of trace configuration changes . . . . . . . . . . . . . . . . . . . . . . 78

Interpreting cell execution failure codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Using the BMC IX Administration view to manage cells . . . . . . . . . . . . . . . . . . . . . . . 80

Connecting or disconnecting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Viewing cell information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Controlling cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81


BMC Impact Manager overview

Reloading cell configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Forcing event propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Registering for SIM notification events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Collecting metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

BMC Impact Manager overviewBMC Impact Manager provides the core functionality for event management and service impact management. Its functional elements are the

■ event processor and service model manager (also known as a cell)■ Knowledge Base (KB) and compiler■ event repository and State Builder■ Command Line Interface (CLI)

BMC Impact Manager cells

A cell is the event-processing engine that collects, processes, and stores events within a single BMC Impact Manager installation instance. If service impact management (SIM) is implemented, the cell associates the events with the service model components and calculates a component’s status.

An individual cell can provide local event management or function as part of a larger distributed network of cells using event propagation. Networks of cells can be organized to serve any business hierarchy (such as geographical, functional, or organizational) or configured to meet technical issues (such as network or system limitations).

Event management cell functions

A basic event management (EM) cell performs the following functions:

■ receives source event data from an adapter, integration, another cell, API, or the BMC Impact Manager CLI

■ analyzes and processes events according to the event management rules and policies defined in its Knowledge Base

■ responds to events by executing actions, as defined in scripts or programs in its Knowledge Base



■ propagates selected events to specified destinations (typically, other cells) and maintains the currency of propagated events when those events are updated or changed at the event source or event destination

■ records the event operations performed on an event

Service impact management cell functions

A service impact management (SIM) cell performs the following functions in addition to the event management functions:

■ relates an event to the appropriate service model component

■ computes the status of service model components and propagates their status to the related components using the designated status computation models

Production cells and test cells

A production cell is an EM or SIM cell that service operators and service managers use to monitor the events and services associated with your IT resources in real time.

A test EM or SIM cell provides senior service managers and service administrators with a test environment in the following ways:

■ SIM cell

Enables publishing of service models from a development sandbox to a test environment before promoting them to a production environment. Each BMC Impact Service Model Editor user has one dedicated test environment, which consists of a pair of test CMDB data sets and an alias to a test cell. Promoted service model components include those in a user’s sandbox and in production. For details about test environments and promotion, see Part 3, “Service model administration”.

■ EM cell

For event management, a test cell provides KB developers with a test environment for defining event classes, event management rules, policies, actions, and collectors and testing their behavior with test event data.

BMC Impact Portal does not collect events from test cells for reporting.



Production and test cell naming and creation

The only way to distinguish a test cell from a production cell is by the cell name. Adopt a naming convention for test and production cells that clearly identifies its purpose.

You name a cell when it is created. One cell is created with each BMC Impact Manager instance that you install. You use the mcrtcell command to create additional production or test cells. The mcrtcell command can only be run on the local computer where the cell is being created. For more information about syntax and options available with mcrtcell, see “mcrtcell—Creating a new cell” on page 401.

Production and test cell configuration

You register test and production cells in BMC Impact Portal. For instructions, see “Registering production and test cells in the BMC Impact Portal” on page 128.

In BMC Impact Service Model Editor, each user associates a test cell to a test environment. For further information, see Part 3, “Service model administration”.

In BMC Impact Explorer, assign the production and test cells to a group. The default groups are MyTest and MyProduction. For further information, see “Connecting BMC IX to a BMC Impact Portal” on page 144.

Viewing test cell data

You view test data in BMC Impact Explorer.

■ To view test event data, collectors, and actions, select a test cell in the Events view.

■ To view and create test event management policies, select a test cell in the Administration view.

■ To view test service model components, use the Find tool in the Services view and select a test cell.

NOTE The navigation tree in the Services view, which is published from BMC Impact Service Model Editor, can contain production service model components only.


BMC Impact Manager Knowledge Base (KB)

BMC Impact Manager Knowledge Base (KB)

A Knowledge Base is a collection of information that enables a cell to perform event management and service impact management. An event management KB includes the following:

■ Event class definitions define the types of events to accept and classify source event data for processing

■ Data class definitions define the classes and slots of dynamic data instances and service model component instances

■ Dynamic data function as contextual variables that can provide data values to rules and policies during event processing

■ global records are persistent structured global variables that maintain data values across all phases of event processing

■ event management rules are event processing statements that use the BAROC data associated with an event, data instances or records to determine if, when, and how to respond to new events or event modifications

■ event collectors are filters that query the event repository and display the results in a BMC Impact Manager event list in an organized manner

■ actions are executable programs or scripts that perform an automated task on a particular event

In addition, a service impact management (SIM) KB also includes

■ a reference copy of a cell’s service model published by a BMC Impact Publishing Server

■ a reference copy of the BMC Atrium CMDB Common Data Model (CDM) class definitions, which are used in a cell’s service model

The KB files are loaded by a cell at start time. Although many KBs can exist within a distributed BMC Impact Manager environment, each cell can be associated with only one KB at a time.

For complete information about the BMC Impact Manager Knowledge Base, see the BMC Impact Solutions: Knowledge Base Development Reference Guide.


BMC Impact Manager event repository and State Builder

BMC Impact Manager event repository and State Builder

After a cell receives and processes an event, it stores the event in the event repository as an instance of a particular event class. All events are held in memory and can be viewed in BMC Impact Explorer. The event repository provides persistent storage on disk for events and data instances, including service model components and relationships. The State Builder manages the persistent storage of events.

BMC Impact Manager command line interface (CLI)

The BMC Impact Manager Command Line Interface (CLI) enables users to execute BMC Impact Manager functions immediately from the OS command line or execute product functions from a script. For more information, see Appendix B, “BMC SIM and EM CLI Reference.”

Starting or stopping the cell - mcell and mkillThe installation process automatically starts a cell’s service. However, as changes are made to a cell’s configuration files or KB, you must stop and start the cell to accept the changes.

Stopping or starting a cell on UNIX computers

By default, a cell runs as a UNIX daemon. You override this behavior with a command line option, not a configuration file parameter.

Before you begin

A cell can be installed as owned by any user. Only users with execute permission on the mcell binary can start the cell. All users with execute permission on the mkill or mcontrol CLIs can stop the cell. However, if a user without root permissions attempts to start the process, the following issues must be considered.

■ External actions run as the user ID that started the process. Those actions are defined in %MCELL_HOME%\etc\CellName\kb\bin on Windows platforms and in $MCELL_HOME/etc/CellName/kb/bin on UNIX platforms.

Actions are defined in .mrl files located in the kb/bin directory and listed in .load in that directory. The action programs or scripts can be located in the kb/bin/A or kb/bin/Arch directory. They can also be located anywhere else on the system.


Starting or stopping a cell on Windows computers

■ The user who starts the cell must be able to write to log and trace files in the directories specified through configuration parameters SystemLogDirName and SystemTmpDirName. Default values for these are the log and tmp subdirectories of MCELL_HOME.

To stop a cell on UNIX computers

To stop a cell, use the mkill command located in the MCELL_HOME/bin directory with the name of the cell you want to stop. If no cell name is provided, mkill attempts to stop a local cell whose name is the same as the local host name. For more information about the mkill command, see “mkill—Stopping a cell” on page 417.

To start a cell on UNIX computers

To start a cell, use the following command:

mcell -n cellName

It is possible to start a cell without specifying a cell name. If you start a cell without any options, the command attempts to start a cell with the same name as the host. You must set the MCELL_HOME environment variable to point to the directory in which the cell is installed. The home directory also can be indicated using the option -l followed by the path to the home, instead of defining it in the environment. To learn more about using the mcell command, see “mcell—Starting a cell” on page 386.


On Windows computers, you can stop a cell by using one of the following options:

■ Windows Services■ the net stop command■ the mkill command

On Windows computers, you can start a cell by using one of the following options:

■ Windows Services■ the net start command from a command prompt window

NOTE You can change all configurable cell parameters by making changes in the configuration file, mcell.conf. When you start the cell, the cell looks for the configuration file in the default location, MCELL_HOME\etc\cellName\mcell.conf. Use the -c option with the mcell command to have the cell look for the configuration file in a specified location.



To stop a cell on Windows platforms by using services

1 Open the Services window by choosing Start => Settings => Control Panel => Administrative Tools => Services.

2 Select mcell_cellName.

3 Click Stop Service.

To stop a cell on Windows platforms by using the net stop command

1 Select Start => Programs => Command Prompt.

2 Enter net stop mcell_cellName.

To stop a cell on Windows platforms by using the mkill command


2 Enter mkill -n cellName.

To start a cell on Windows platforms by using services

1 Open the Services window by choosing Start => Settings => Control Panel => Administrative Tools => Services.

2 Select mcell_cellName.

3 Click Start Services.

To start a cell on Windows platforms by using the net start command


2 Enter the following command:

net start mcell_cellName.

NOTE If you do not use the -n option when stopping a cell, the default cell, named hostName, is stopped.


Cell configuration tasks

Cell configuration tasksThe more you customize your cell to fit your needs, the more efficiently the cell works for you. All configuration tasks are optional. Table 2 describes the cell configuration tasks.

NOTE When started from the command prompt without the -d option, mcell contacts the Service Control Manager to start itself as a service. It uses mcell_%N as a service name, where %N is the cell name as specified with the -n option. Without the -n option, the hostname is used as the cell name.

Table 2 Cell configuration tasks

Task Description For more information, see

1 (optional) Create additional cells.

When you install BMC Impact Manager on a system, one cell is installed. You can create additional cells by running the mcrtcell command.

“mcrtcell—Creating a new cell” on page 401

2 (optional) If you created multiple cells for an environment, you can create separate configuration files for each cell.

“Creating cell-specific configuration files” on page 46

3 (optional) If you created multiple cells for an environment, configure the cells so that they can communicate with other cells in the network.

“Configuring cells to communicate” on page 47

4 (optional) If you created multiple cells for an environment, configure a high availability cell or cells.

“Configuring high availability cells” on page 50

5 (optional) Events can be processed locally or selectively propagated to other cells. To configure the event slots that must be propagated when they are changed, and in which direction (forward/backward), configure the propagation configuration file.

“Configuring event slot propagation” on page 59

6 (optional) If inbound connections to the cell are disallowed in a protected environment, the connection has to be established within the protected zone to allow a connection between an external client and a cell in the protected zone.

“Configuring passive connections” on page 62

7 (optional) To add a time stamp to a slot so that the date and time is recorded when the slot is changed, configure the mcell.modify file.

“Configuring slots for time stamping” on page 63

8 (optional) If desired, you can encrypt communication among the various BMC Impact Solutions components.

“Configuring encryption” on page 64

9 (optional) Set the default client parameters executing CLI commands.

“BMC Impact Manager CLI configuration” on page 440


Configuring mcell.conf parameters


The cell is installed with a configuration file, mcell.conf, that allows it to run without any additional configuration. By using a text editor, you can change the configuration parameters in the mcell.conf file to customize the cell for your particular IT infrastructure and environment. You can override some parameters using command line arguments when you start the cell. For more information, see “mcell—Starting a cell” on page 386.

To configure the mcell.conf file using a text editor

1 Open the mcell.conf file in a text editor.

The default location is MCELL_HOME\etc.

2 Create line entries using the format Parameter=Value based on the syntax rules described in “Rules for cell configuration parameter syntax”.

3 Save the changes.

4 Either reload the cell configuration or restart the cell for the changes to go into effect. For more information, see “Reloading cell configuration” on page 68.

Rules for cell configuration parameter syntax

The following rules apply:

■ One parameter per line, in the form: Parameter=Valuewhere the Value extends to the end of the line

■ Typically, the value for a parameter is a Boolean value, a string, or a path. The supported Boolean values are Yes/No and On/Off.

■ The Boolean values are not case sensitive, so, for example, On, ON, on, and even oN are equally valid.

■ Do not enclose the value in quotation marks unless you want the quotation marks to be part of the value.

■ Times are stated in seconds unless otherwise specified.

■ By default, all parameter settings are disabled, that is, commented out with a # sign at the beginning of the line of code. Enable a parameter setting by removing the # sign that precedes it.



For more information on cell configuration parameters, see Appendix C, “mcell.conf file parameters.”

Specification of path values

Parameters that have path values contain the string fileName or dirName, for example TraceConfigFileName or SystemLogDirName.

Path values can be stated as:

■ absolute path—starts with slash (/) or backslash (\), or on Windows, with a drive designator (for example, D:)

■ runtime relative path—starts with ./ or ../. The path is relative from the cell’s working directory. The working directory is the root directory (/) when it runs as a daemon or a service. When running in foreground, it is the directory where mcell is started.

■ configuration relative path—all other path values are relative from the cell’s configuration directory, or, for program paths, from the kb\bin directory.

Path values can contain the substitution parameters $VAR or %X. Any $VAR parameter is substituted by the value of the environment variable VAR. Table 3 lists the possible %X substitution parameters.

Modifying SystemLogDirName, SystemTmpDirName, and KBDirName

With the cell configuration parameters SystemLogDirName and SystemTmpDirName, users can specify alternative path locations for the system defined log and tmp directories. Their default values are %H/log and %H/tmp. To enable file name specifications that refer to these alternative locations, use the substitution parameters %L for the log and %T for the tmp directory. They are substituted by the specified path to the log and tmp directory, respectively.

Table 3 Substitution parameters for %X in path value parameters

Parameter Description

%H cell home directory

%C cell configuration directory

%B Knowledge Base binary directory, kb\bin

%L log file directory

%T temporary file directory

%P program name

%N cell name


Creating cell-specific configuration files

If you change the default value for the SystemLogDirName parameter or the KBDirName parameter in the mcell.conf file, you must also change the value in the statbld.conf file. If you fail to do this, the cell loses persistency and the mcdb file is not created, because the StateBuilder is configured from statbld.conf file and has no input from the mcell.conf file. As a result, StateBuilder does not know where to find the log files or the KB directory it requires.

ConnectionPortRange syntax

Figure 2 shows the syntax of ConnectionPortRange.

A range is a number of sequences, each of which is a consecutive range of ports. The cell attempts to access all ports in the specified order. The default is to use any of the ephemeral ports.

For example,

■ 1828—1840 specifies a range of ports 1828 through 1840■ 1828, 1829, 1840 specifies the sequence of ports 1828, 1829, and 1840

Creating cell-specific configuration files

By default, one set of configuration files is installed during installation of the BMC Impact Manager. These files are located in the MCELL_HOME\etc directory and multiple cells on a host can use them. You can also create unique configuration files for individual instances (cells) as needed.

To create cell-specific configuration files

1 Copy the configuration file that you want to be unique to the MCELL_HOME\etc\cellName directory. cellName represents the name of the cell.

2 Using a text editor, edit the configuration file and customize it for that cell and save it.

You can copy and edit any configuration file located in the MCELL_HOME\etc directory.

3 Either reload the cell configuration or stop and start the cell so that the changes take affect.

Figure 2 ConnectionPortRange syntax

PortRange = PortSequence{, PortSequence}PortSequence = Port[-Port]


Configuring cells to communicate

When a cell starts, it searches for configuration files in the MCELL_HOME\etc\cellName directory. If no configuration file is found, the cell uses the configuration file in the MCELL_HOME\etc directory. For example, if you copy the mcell.conf file into the MCELL_HOME\etc\cellName directory and modify it, the cell reads that mcell.conf file and all other files in the MCELL_HOME\etc directory.


Each cell can function as either a complete event management system or as part of a larger distributed network of cells. After you install a cell, it can run with no additional configuration; however, it cannot communicate with other cells, the BMC Impact Portal, or gateways in a distributed BMC Impact Solutions network. To enable communication between cells and some clients, you must modify the mcell.dir file, which is also known as the cell directory file.

About mcell.dir, the cell directory file

The mcell.dir file is created during product installation. It acts as the cell directory file, contains the list of cells, the BMC Impact Portal, and gateways known on a specific computer. Upon startup, the cell reads the mcell.dir file and associates itself with the appropriate name, encryption key (if encryption is enabled), address information, and port number. In addition, it reads this information for the other cells to which it connects and for the BMC Impact Portal.

The mcell.dir file for a cell has an entry for each cell and the BMC Impact Portal to which the cell connect. Figure 3 shows the format of an entry.

Figure 3 Format of an entry in the mcell.dir file

### One line per component :# <Type> <Name> <EncryptionKey> <IpAddress:Port># <Type> = cell | gateway.type## cell ComponentName EncryptionKey Host:1828# gateway.portal bip.fullyqualifiedHostName EncryptionKey Host:3783



Each parameter in the file is defined as follows:

Example of the mcell.dir file

Figure 4 shows an example of the mcell.dir file with typical component entries.

Rules for mcell.dir file entries

The following rules apply when creating entries for the mcell.dir file:

■ Cells may be grouped into separate cell files readable only by certain users or groups (domains).

■ A cell must know, at a minimum, the cells to which it propagates events. A cell does not need to know the cell from which it receives events, even for backward propagation.

■ The mcell.dir file may define any number of entries, but each entry must be on a separate line.

Attribute Description

Type type of component. It can be■ cell— BMC Impact Manager cell name■ gateway.type—Gateway of type type■ gateway.jServer - predefined jServer gateway type ■ gateway.portal - BMC Impact Portal

Name Name is an abstract name for the component. Component names are not case-sensitive and may be any alphanumeric string, including underscores (_).

A Portal name is, by convention, the fully qualified host name of the Portal host, prefixed with bip.

EncryptionKey String to be used as part of the key for the encryption of the communication between a cell and the component. Default value is 0 (zero).

IPAddress:Port Host name or IP address and port number on which the component is listening. Default port number for a cell is 1828 and for a Portal is 3783.

Figure 4 Example of the mcell.dir file and its entries

### One line per component :# <Type> <Name> <EncryptionKey> <IpAddress:Port># <Type> = cell | gateway.type#cell anwar-bos-71 mc anwar-bos-71:1828cell local mc 127.0.0.1:1828gateway.portal bip.anwar-bos-71.amc.com mc anwar-bos-71:3783



■ You can place mcell.dir files on remote mountable partitions or distribute them using rdist, tftp, or any other distribution mechanism.

Ways to update an mcell.dir file

Update the mcell.dir file in one of the following ways.

■ If adding a new cell on the same computer as the existing cell, run the mcrtcell command.

The command updates a master mcell.dir file found in the MCELL_HOME\etc by adding the information for the new cell to the mcell.dir file. For more information, see “mcrtcell—Creating a new cell” on page 401.

■ If you are adding a new cell that is not on the same computer, add the new cell information to the mcell.dir file using a text editor. See “To configure the mcell.dir file using a text editor” on page 49.

Also, depending upon how your service model is set up, you may need to modify the mcell.dir file on the computer that contains the cell.

For example, you have two computers, computer A and computer B. Cell A is on computer A and cell B is on computer B. For cells A and B to communicate, you would have to enter the information for cell A in the mcell.dir file on computer B and the information for cell B in the mcell.dir file on computer A.

■ If you are setting communications up with a BMC Impact Portal after its installation, you must define the portal connection in the mcell.dir file.

To configure the mcell.dir file using a text editor

You should maintain a master mcell.dir file that contains directory entries for all cells on a computer. The file must be readable by all cells. As an alternative, make copies of this file available to all cells. This enables a cell to contact any other cell based on its cell name.

1 Open the mcell.dir file in a text editor.


WARNING You must maintain each cell’s mcell.dir file to ensure event propagation between cells and the ability to connect to the BMC Impact Portal. Ensure that each directory entry is correct and that every cell has an up-to-date directory file. An error in the mcell.dir file prevents cells from connecting to each other or to the BMC Impact Portal.


Configuring high availability cells

2 Create line entries using the format shown in Figure 3 on page 47.

3 Save the changes.

4 To ensure that the changes take affect, do one of the following:

■ Stop and start the cell; for more information, see “Starting or stopping the cell - mcell and mkill” on page 40.

■ Run the mcontrol CLI command to reload only the mcell.dir file:

For more information on the mcontrol command, see “mcontrol—Performing cell control operations” on page 398.

5 Register the cell with the BMC Impact Portal by doing one of the following:

■ Use the BMC Impact Portal Administrator page to register the cell.

For more information, see the BMC Impact Portal online Help.

■ With the BMC Portal running, run the admin utility to register the specified cell.


What is high availability?

Configuring a cell for high availability increases the availability of the cell in disaster cases. When a high availability cell server fails, another server can take over on another host, with minimal loss of data and state, and with minimal delay.

High availability only avoids cell failure. It will not improve the cell’s availability in other cases, such as when the load on the cell increases. In this case, the cell will become less responsive whether it is a high availability cell or not.

If the cell becomes unavailable on the primary host, it can be restarted in the same, or almost the same state on another machine. Clients will reconnect transparently to the alternate cell server. After the original cell server has been repaired, it can be reinstated and clients will switch back to it.

mcontrol -n cell_Name reload dir

admin.bat -ac name=cellname:key=key:host=hostname:port=port: usergroups=* (Windows)

admin.sh ac name=cellname:key=key:host=hostname:port=port: usergroups=* (UNIX)



High availability implementation

A high availability cell is implemented as two server processes. One of the two server processes is designated as the primary server, and the other server process is the secondary server. These two roles are not symmetric. The roles can be switched, but this requires a shutdown of both servers and a minor configuration modification.

The highest possible availability for a cell occurs when two server machines are close to each other with a highly reliable network connection. When the two server machines are on remote sites, the high availability cell functions more like a Disaster Recovery system.

Only one of the two servers should be active at any time.

How high availability functions during normal operation

When the environment is operating normally, the primary server is active, while the secondary server operates in standby mode. All clients communicate with the primary server.

The primary server sends all its transactions immediately to the secondary server. As a result, the secondary server is a synchronized duplicate of the primary.

How high availability functions during failover

When the primary server becomes unavailable, the secondary server becomes active. This process is called failover. This process can be either manual or automatic, depending on how the high availability cell is configured. By default, failover is automatic.

WARNING The primary and secondary servers of a high availability pair must run on two different logical OS images of the same type. Primary and secondary servers of a high availability pair running on the same system or running on different operating systems is not supported.

WARNING Although it is technically possible to activate both servers, this is not supported. If both servers are activated, incompatible server states can occur. If the server states are incompatible, manual intervention is required to resynchronize the primary and secondary servers. If this situation occurs, see “Problem: The primary and secondary servers for my high availability cell are in active mode simultaneously or are unsynchronized.” on page 376.



When the primary server becomes unavailable, all disconnected BMC Impact Explorer and BMC Impact Portal clients automatically reconnect to the secondary server. At that time, if the secondary server is in standby mode, reconnected users can see the information that was replicated from the primary server before it became unavailable, but they cannot take any action.

CLI clients and other cells do not connect to the secondary server until it is active. In the interval between when the primary server goes down and when the secondary server becomes active, the cells and adapters buffer their events.

If the primary server is only temporarily unavailable, and the secondary is not activated, all the clients will reconnect to the primary server as soon as it is available again. Alternatively, if the secondary server becomes active, the BMC Impact Explorer and BMC Impact Portal clients gain Read-Write access to the secondary server and the CLI clients and the other cells will connect to it.

How high availability functions when primary server becomes available after failover

The primary server must be activated again after it has been repaired and the secondary server must be reset to standby mode. Switchback is the process of the primary server becoming active and the secondary server reverting to standby mode. This process can be manual or automatic, depending on how the high availability cell is configured. By default, switchback is automatic.

When the secondary server switches back to standby mode, its clients are disconnected and they automatically reconnect to the primary server.

If the secondary server becomes temporarily unavailable and the primary server is also unavailable, clients connect to the first server that becomes active.

WARNING It is highly recommended that you disable automatic failover and enable manual failover when the connection between the primary and secondary server is unreliable. Otherwise, there is a risk that both primary and secondary servers would be active at the same time when they cannot communicate with each other. This situation is not supported. If this situation occurs, see “Problem: The primary and secondary servers for my high availability cell are in active mode simultaneously or are unsynchronized.” on page 376.



Installation and configuration considerations for high availability cells

To get the same behavior for the primary and for the secondary cells, both should be installed and configured similarly. It is highly recommended that the Knowledge Bases for both servers are identical. Configuration parameters also should be set to the same values for both servers, except for the CellDuplicateMode parameter that indicates whether the server is a primary or a secondary server. For details about the high availability cell configuration parameters, see “Cell failover configuration parameters” on page 446.

To install and configure a high availability cell, you must

1. Install BMC Impact Manager on the two machines that will host the two cell servers. For instructions, see BMC Impact Solutions: Installation.

2. Create an identical cell for each server. For instructions on creating cells, see BMC Impact Solutions: Installation.

For example a cell on host1:

mcrtcell -is -p port1 CellName

And an identical cell on host2:

mcrtcell -is -p port2 CellName

3. Specify the primary and secondary server locations for the cell. For instructions, see “To specify the primary and secondary server locations for the cell” on page 53.

4. Configure high availability options. For instructions, see “To configure high availability options” on page 54.

5. Configure the primary server. For instructions, see “To configure the primary server” on page 54.

6. Configure the secondary server. For instructions, see “To configure the secondary server” on page 55.

To specify the primary and secondary server locations for the cell

1 On both servers, open the mcell.dir file in a text editor.

2 Replace the line for CellName with:

cell CellName mc host1:port1 host2:port2



CellName is the name of the cell created on both servers. host1:port1 is the host name and port number of the primary server, and host2:port2 is the host name and port number of the secondary server.

This indicates two locations (host name and port number) for the same cell.

3 Save and close mcell.dir.

To configure high availability options

1 On both servers, open the mcell.conf file in a text editor.

2 Assign identical values to the following high availability configuration parameters for both servers:

■ CellDuplicateAutoFailOver—To enable automatic failover, set the value to Yes. To fail over to the secondary cell manually, set the value to No. By default, the value is Yes.

■ CellDuplicateAutoSwitchBack—To enable automatic switchback from the secondary cell to the primary cell, set the value to Yes. To switch back to the primary cell manually, set the value to No. By default, the value is Yes.

3 If you have opted for automatic failover, failover timeout values can also be configured. For more information, see “Automatic failover process” on page 58.

4 Save and close mcell.conf.

To configure the primary server

1 On the machine hosting the primary cell server, open the mcell.conf file in a text editor.

2 Set the value of the CellDuplicateMode parameter to 1.

The primary server is ready to be started. See “Starting a high availability cell.”

NOTE Modifying mcell.conf globally modifies all cells. To modify a single cell, ensure that you modify the configuration file specific to the individual cell.

NOTE Failover and switchback can be configured independently. It is not required to configure both as manual or both as automatic. For example, you could configure high availability so that failover is manual, but switchback is automatic.



To configure the secondary server

1 On the machine hosting the secondary cell server, open the mcell.conf file in a text editor.

2 Set the value of the CellDuplicateMode parameter to 2.

3 Save and close mcell.conf.

The secondary server is ready to be started. See “Starting a high availability cell.”

Starting a high availability cell

Both primary and secondary servers should be started almost at the same time. The preferred order is to start the secondary server first, and then immediately start the primary.

To re-initialize a high availability cell

1 Shut down the primary and secondary servers for the cell.

2 Erase the cell's entire log directory entirely on both servers.

3 Restart both cell servers without using any of the -i options. (Preferably, start the secondary server first.)

High availability operation mode

Cell-specific directories

All cells use the following cell-specific directories:

WARNING ■ If the primary server is started and terminates before the secondary server is started, the

state of primary and secondary servers may become unsynchronized. If this occurs, you must manually synchronize the servers before restarting either of them.

■ Do not start a high availability cell using any of the -i initialization options (for example, -ia, -id or other variants). This could cause the primary and secondary servers to become unsynchronized.

If the servers become unsynchronized for either of these reasons, see “Problem: The primary and secondary servers for my high availability cell are in active mode simultaneously or are unsynchronized.” on page 376 for instructions on how to manually synchronize the servers.



■ $MCELL_HOME/etc/CellName contains cell-specific configurations (including the Knowledge Base)

■ $MCELL_HOME/log/CellName contains the cell transaction logs and persistent state of the cell

■ $MCELL_HOME/tmp/CellName contains the cell’s temporary files

High availability cells use the cell-specific directories, but the names of the log and tmp directories are suffixed with # followed by the server number, 1 for the primary server and 2 for the secondary server. The names become:

■ $MCELL_HOME/log/CellName#1■ $MCELL_HOME/log/CellName#2■ $MCELL_HOME/tmp/CellName#1■ $MCELL_HOME/tmp/CellName#2

High availability related events

A high availability cell operates the same way that a standard cell operates.

To keep the primary and secondary cell servers synchronized, the primary cell server transmits all its transactions to the secondary server. This happens transparently. For instance, it is not visible in BMC Impact Explorer. Also, the Knowledge Base rules do not have to be modified for synchronization and there are no specific events generated for it.

When the primary server loses contact with the secondary server and cannot transmit its transactions, it generates an internal event of class MC_CELL_DUPLICATE_FAILURE with severity=MAJOR. All transactions are buffered for transmission to the secondary server. As soon as the primary server has re-established a connection with the secondary, it generates an internal event of class MC_CELL_DUPLICATE_ON with severity=OK and with the down_time slot indicating (in seconds) how long the connection between primary and secondary servers was down.

Each time a cell changes its operation mode, it generates an MC_CELL_ACTIVITY_CHANGED class event.

The active_server slot indicates which of the cell's servers became the active one. A value of 1 indicates the primary server is active and a value of 2 indicates the secondary server is active. If the cell is not a high availability cell, this slot is 0.

MC_EV_CLASS: MC_CELL_ACTIVITY_CHANGED ISA MC_CELL_CONTROLDEFINES { active_server : INTEGER; -- 0 = Regular cell / 1 = Primary node / 2 = Secondary node of HA cellduplicate_connected : MC_YESNO; paused : MC_YESNO; };

END



When the primary server is active for the high availability cell, the duplicate_connected slot indicates whether or not the secondary server is connected. If the primary server is not active and/or the secondary server is not connected, the value of the duplicate_connected slot is NO.

If the value of the paused slot is YES, the cell is paused (or has limited activity). If the value is NO, the cell is fully active.

This event is generated by a failover or switchback. It is also generated when the active server switches between limited activity and full activity. On a high availability cell, the event is generated only by the active server. In case of a switch between primary and secondary servers, the event is generated just after the switch.

Manually failing over to the secondary cell

If there is a problem with the primary server, a failover to the secondary server is required. If the cell is configured with CellDuplicateAutoFailOver=No, this failover must be performed manually.

To manually fail over from a primary server to a secondary server

1 Terminate the primary server (if it is still running) by entering:

mkill -n CellName#1

2 Activate the secondary cell server by entering:

mcontrol -n CellName#2 start

Manually switching back to the secondary cell

After a primary cell server has been repaired, a switchback operation is required to re-activate it. If the cell is configured with CellDuplicateAutoSwitchBack=No, switchback must be performed manually.

To manually switch back from a secondary server to a primary server

1 Clear the primary server log directory by entering:

rm -f $MCELL_HOME/log/CellName#1/*

2 Switch the secondary server to standby mode by entering:

WARNING You must explicitly include the #1 suffix after the cell name or the mkill command will terminate the secondary cell if there is a problem with the command connecting to the primary cell.



mcontrol -n CellName#2 standby

3 Transfer the state file from the secondary to the primary server:

copy host2:$MCELL_HOME/log/CellName#2/mcdb to host1:$MCELL_HOME/log/CellName#1/mcdb

4 Start the primary cell.

Automatic failover process

If a high availability cell is configured with CellDuplicateAutoFailOver=Yes, it will automatically perform a failover when needed.

Failover occurs when the secondary server loses its connection with the primary. If it cannot connect to the primary server within the time period specified in the CellDuplicateFailOverTimeOut parameter, the secondary server assumes that the primary server is no longer available and becomes active.

The CellDuplicateFailOverStartTimeOut parameter specifies the period after startup after which the secondary server will become active when it has no connection with the primary server. This parameter should be set high enough to allow primary and secondary servers to be started at more or less the same time.

Although you can start the secondary server before the primary server, if the secondary server is started first, it cannot connect to the primary server. Therefore, the value of the CellDuplicateFailOverStartTimeOut parameter should be set so that there is enough time for the primary server to start.

Automatic switchback process

If a high availability cell is configured with CellDuplicateAutoSwitchBack=Yes, it automatically performs a switchback when the primary server starts.

When the primary server is started, it connects to the secondary server and determines its activity level. If the secondary is active, the switchback procedure is started. The secondary server switches to standby mode and transmits its state to the primary server. Once the primary server has determined that the secondary server is in standby mode, the primary server restarts itself and reloads the state that it received from the secondary server.

Explicitly connecting a CLI to a selected server

A CLI will automatically connect to the primary cell server. If the primary cell server is not active, the CLI connects to the secondary server.


Configuring event slot propagation

It is possible to connect a CLI explicitly to either the primary or the secondary server, using the common CLI -n option.

One method is to indicate the host and port of the desired server explicitly. For example:

mgetinfo -n host2/port2 -v activity

This example retrieves the activity level of the secondary cell server.

Another method is to enter the cell name, followed by # and the server number (1 for primary and 2 for secondary). For example:

mgetinfo -n CellName#2 -v activity


Events can be processed locally or selectively propagated to other cells. To configure the event slots that must be propagated when they are changed, and in which direction (forward/backward), you configure the propagation configuration file mcell.propagate. The mcell.propagate file lists all of the slots whose modifications will be propagated.

In addition, using the BMC Impact Solutions gateways, events can be propagated to a third-party program in a specific format that is described in a gateway configuration file, gateway.GWType.

The default location for these files is MCELL_HOME\etc.

When an event has been propagated to a destination and that event is later modified, the modifications are then propagated to the same destination. The event can be propagated through a Propagate rule. If the destination is a gateway, gateway configuration rules also apply.

For the mcell.propagate file to be effective, one or more Propagate rules must be running. For information about Propagate rules, see the BMC Impact Solutions: Knowledge Base Development Reference Guide.

The format is Slotname = Value, where:

Slotname = slot name or CLASS for class-specific slots

Value = sequence of { b = backward f = forward }



You can specify a slot in the base CORE_EVENT class. However, if you want to specify a slot outside those in the base CORE_EVENT class you must use the CLASS specifier, which means that all class-specific slots are propagated in the direction given.

Table 4 on page 60 lists the parameters in the mcell.propagate file and the defaults.

If you have multiple instances of BMC Impact Manager installed, you might want to use event propagation to distribute the event processing load among the cells or to back up events on another cell for failover.

Figure 5 on page 61 illustrates a cell network that is collecting and processing numerous events in a distributed environment.

Table 4 Default mcell.propagate options

Parameter Action PerformedDefault Values

administrator propagates administrator value changes up (forward) within the cell hierarchy f

CLASS propagates changes to the class-specific slots up (forward) within the cell hierarchy

f

mc_modhist propagates changes to the mc_modhist up (forward) within the cell hierarchy

This is a system defined slot that requires such propagation.

f

mc_notes propagates changes to notes attached to an event up (forward) within the cell hierarchy

f

repeat_count propagates changes to repeat_count up (forward) within the cell hierarchy f

severity propagates severity value changes up (forward) within the cell hierarchy f

status propagates status value changes in both directions, backward and forward, in the cell hierarchy

bf



Figure 5 Distributed event management using event propagation

In this illustration, the lower-level cells process the source events and then propagate (or forward) the events on to higher-level cells according to a Propagate rule or an Event Propagation policy. As events pass through a series of cells, the cells discard unneeded events, identify and leave behind unimportant events, and resolve some of the problems reported by other events.

To enable event propagation, perform the following tasks:

■ enable cell-to-cell communication in mcell.dir ■ configure propagation parameters in mcell.conf

■ specify the slots whose modification has to propagate in mcell.propagate

■ either write a Propagate rule or define an Event Propagation policy

event sources

event sources

event sources

event sources

Some events are propagatedfor management by other cellsin the cell network.

cell

cellcell

cell

cell

cell

cell


Configuring passive connections

Configuring passive connections

If inbound connections to the cell are disallowed in a protected environment, the connection has to be established within the protected zone to allow a connection between an external client and a cell in the protected zone. To connect to the cell, the client issues a passive connection; that is, it waits until the cell establishes the connection to the client.

Configuring the client for passive connections

On the client side, the mcell.dir file has to indicate that the destination cell is located in an isolated protected zone.

To configure the client for passive connections

1 Open the mcell.dir file in a text editor.


2 For the destination cell, replace Host:Port with 0 as shown in Figure 6.

3 Save the changes.

4 Either reload the cell configuration or stop and start the cell.

When a cell or gateway client needs to connect to an isolated destination cell, it cannot establish a connection because it does not have the IP address and port number of the cell. Instead, the cell or gateway client registers the destination and waits for a connection from it.

Configuring a cell for passive connections

On the cell side, an indication is needed that a client could be waiting on a connection.

NOTE A passive connection is only possible with the “server” type clients, such as the cell and gateway clients.

Figure 6 Passive connection format

cell cellName EncryptionKey 0


Configuring slots for time stamping

To configure a cell for passive connections

To configure a cell for passive connection, you must create a data object and specify how to control it, as shown in Figure 7.

The cell slot, as defined in the MC_CELL_HEARTBEAT superclass, gives the name of the passive client. The enable slot in the superclass specifies whether or not monitoring and reconnection is enabled. The cell attempts to connect to passive client targets as configured with the standard connection parameters. As soon as a connection is established, the connection is reversed. At that moment, the client takes up the connection and behaves as an ordinary client.

Monitoring passive targets

The cell may not be aware that a connection has been terminated when a connection from a passive client to a cell is terminated. The passive client cannot try to reestablish the connection, nor can it signal the cell to reestablish the connection. To avoid such situations, the cell monitors the passive client, based on the standard heartbeat monitor mechanism. Then, when a disconnect is detected, the cell attempts to connect to the passive client target.

Configuring slots for time stamping

Each event has an mc_modification_date slot that contains the time stamp of the last modification of the event. Only select slot modifications set this time stamp. To add a time stamp to a slot so that the date and time is recorded when the slot is changed, you must configure the mcell.modify file. The mcell.modify file contains the names of the slots that affect the mc_modification_date slot. When one of the slots listed in the mcell.modify file is modified, the mc_modification_date slot is set with the time stamp of this change.

To configure slots for time stamping

1 Open the mcell.modify file in a text editor.


2 Create a line entry containing the name of the slot whose modification is to be time stamped. Figure 8 shows an example of the mcell.modify file.

Figure 7 Data object specification

MC_CELL_PASSIVE_CLIENT ISA MC_CELL_HEARTBEAT ; END


Configuring encryption

When CLASS is used as a slot name, all class-specific slots or those slots not defined in the base class CORE_EVENT update the mc_modification_date slot with a time stamp.

3 Save the changes.

4 Either reload the cell configuration or stop and start the cell.


You can encrypt communication among the various BMC Impact Solutions components. To enable encryption, make the appropriate settings in the following locations:

■ the cell’s configuration file mcell.conf

■ the BMC Impact Explorer configuration files mclient.conf

■ the BMC Impact Portal used by BMC Impact Explorer■ the cell directory file, which is MCELL_HOME\etc\mcell.dir by default

mcell.conf file settings that control encryption

The primary settings controlling encryption are in the cell configuration file mcell.conf. The following settings control encryption:

■ Encryption

■ ForceEncryption

■ EncryptionKey

If Encryption is set to Yes, encrypted communication to and from the cell is enabled, but not required. For example, if a BMC Impact Explorer does not have encryption enabled, then the communication with that particular BMC Impact Explorer console is not encrypted.

Figure 8 mcell.modify file

# Configuration of slots affecting mc_modification_date when modified# Format :# SlotName# Special name : CLASS : specifies all class-specific slotsstatusseveritymc_priorityrepeat_countCLASS



ForceEncryption requires encryption for all communications. If the BMC Impact Explorer attempts an unencrypted connection to the cell, the connection is rejected.

The encryption process uses the EncryptionKey value as part of the encoding key. If there is no encryption, the EncryptionKey value has no effect.

mclient.conf file settings that control encryption

All CLIs can use an mclient.conf file to determine encryption functionality. The parameters are

■ Encryption

■ EncryptionKey

For more information about the CLI configuration parameters, see “BMC Impact Manager CLI configuration” on page 440.

mcell.dir file settings that control encryption

The mcell.dir file contains a field for an EncryptionKey. At installation, the default EncryptionKey value is set to mc. BMC Software recommends that you modify the value for security.

Encryption behavior between cells and components

This section describes the encryption behavior of cells and components during communication. The following actions occur when a BMC Impact Solutions component initiates communication with a cell:

1. The component scans the cell configuration file, mcell.dir, for that cell’s connection information.

2. BMC Impact Explorer retrieves the cell’s connection information from the BMC Portal.

3. The component opens a connection to the cell.

If the cell has Encryption=yes, the component can use encrypted or non-encrypted communication. The component must use encrypted communication if the cell has ForceEncryption=yes and Encryption=yes.

If the communication is encrypted, both the cell and the component must use the same EncryptionKey values to establish communication.



Information Retrieval

A component must have the address and port of a cell to establish communications with it. To establish encrypted communications, the component must also have the encryption key of the cell. BMC Impact Explorer and the CLI commands determine the information in different ways:

■ BMC Impact Explorer acquires the information from the BMC Impact Portal (cell_info.list).

■ BMC Impact CLI commands obtain the information by determining the server location using one of the following methods:

— directly from the CLI command— from CLI configuration parameters in mclient.conf

— from mcell.dir if you use the -n cellName option

Default values

The default value for cellName is the name of the host (hostName). The default value for the port is 1828.

When the mcell.dir file is present, the default value is EncryptionKey=mc at installation. BMC Software recommends that you modify this value for security.

If the mcell.dir file is absent on the host and you do not specify an encryption key, the CLI command uses 0 (zero) as the default value for EncryptionKey. This value enables encrypted communications.

Mandatory key specification conditions

You must specify the encryption key if the following conditions apply:

■ you execute the CLI command on a host without an mcell.dir file■ the cell has an encryption key other than 0 (zero)

These conditions apply with the default installation. However, if the mcell.dir file is present on the host, and the file specifies the encryption key, you are only required to specify the cellName.

NOTE You can disable encryption by setting the configuration parameter to Encryption=No. You might want to use this setting to disable encryption while tracing.



Limiting cell access

A client is allowed to connect to the cell if its IP address matches the general AllowConnectionFrom as well as the client type-specific Allow*From.

Figure 9 shows an example of masking syntax.

The following conventions apply:

■ An abbreviated Addr or Mask is expanded with zeros.■ A numeric Mask (number without trailing dot) gives the number of 1 bit.■ An omitted Mask defaults to all bits set to 1.■ A connection is allowed if the source address ANDed with the Mask matches Addr

ANDed with the Mask.

When the Mask is all zeros, any address matches regardless of the value of Addr. For all Mask bits whose value is one (1), the equivalent bits in Addr must match the equivalent bits in the source address.

Table 5 lists the IP address parameters.

Figure 9 Masking syntax

AddrMaskList = AddrMask {':' AddrMask}AddrMask = Addr ['/' Mask]Addr = Nr '.' [Nr '.' [Nr '.' [Nr]]]Mask = Addr | NrNr = 0..255

Table 5 IP Address parameters (part 1 of 2)


AllowConnectionFrom=0./0 all systems allowed

(same as 0.0.0.0/0)

AllowConnectionFrom=0./32 no system allowed

(00.00.00.00 is not a valid IP address)

AllowConnectionFrom=198.12./255.255. any system from the 198.12.xx.xx

network can connect


Reloading cell configuration

The default is 0./0, indicating that the server should accept connections from any source. Usually this is useful only for testing or debugging, or for use with a system that is isolated from the network.

To specify one single address, specify the address without a mask, or use a 32-bit mask. The following examples are equivalent ways of specifying a single address:

■ 127.0.0.1■ 127.0.0.1/32■ 127.0.0.1/255.255.255.255

When you specify more than one address per mask pair, a system that matches at least one of the pairs can accept a connection.

Connection attempt using invalid encryption key

An attempt to connect to a cell using an invalid encryption key or from an disallowed address generates an internal event MC_CELL_UNALLOWED_CONNECT. This event contains a slot, reason, that includes the reason for the refused connection.

Reloading cell configurationThe cell does not automatically reconfigure itself, but you can customize and reload the configuration after you have made configuration changes.

To reload cell configuration

To trigger the reconfiguration, perform one of the following actions:

■ Send a hang-up signal on UNIX.

AllowConnectionFrom=127.0.0.1/1 allows any host with an IP address lower than 128.0.0.0, because it indicates there is only 1 bit in the mask

Only the highest-order bit is considered and must be the same as 127, which is a 0 bit.

AllowConnectionFrom=198.12.33./255.255.255.:198.12.92./255.255.255.

systems on the 198.12.33.xx and 198.12.92.xx networks may connect

Table 5 IP Address parameters (part 2 of 2)




■ Run the mcontrol command on UNIX or Windows. For information about the mcontrol command, see “mcontrol—Performing cell control operations” on page 398.

Table 6 lists the specific instances in which the reconfigure feature can be used and the effect that results from its use.

Table 6 Files for cell reconfiguration

Type Name/Directory Result of reconfiguration

cell directory mcell.dira

a For mcell.dir and mcell.trace, a hang-up signal on a UNIX platform performs maximum reconfiguration without a cell restart. For information about restarting a cell, see “Interpreting cell execution failure codes” on page 79.”

This internal directory is replaced with new contents from the mcell.dir file. Associated data objects are replaced as well. Connected clients and destinations remain connected, even if the corresponding directory entries are modified.

cell tracing mcell.tracea Tracing is adapted and has the same effect as through the mcfgtrace CLI.

cell configuration

mcell.conf The cell restarts automatically.

mcell.propagate

mcell.modify

KB collector kb\collectors The cell restarts automatically.

KB program kb\classes The cell restarts automatically.

\kb\rules

\kb\lib

\kb\bin

KB data kb\data The cell restarts automatically.

\kb\records


Monitoring event performance

Monitoring event performanceEvent processing metrics are internal counts maintained on cell performance categories in connection with event processing. These metrics count the following items:

■ number of events received, including erroneous ones ■ number of events containing errors■ number of events dropped by rules (Filter, Regulate) ■ number of events removed from the event repository during cleanup■ number of events propagated, including sendto■ number of events added to the event repository, that is, entering the permanent

context

Calculation is performed on a 60-second basis, so every minute the counters are restarted. Counts from the last five minutes are retained. Running counters are reset only on demand.

The resulting metrics are:

■ short term—total count of the last complete one-minute interval■ medium term—sum of the five last, completed one-minute intervals■ long term—running total

Metrics are stored in MC_CELL_METRIC data objects, one object instance for each metric. Each metric mentions the subject. For each of the short-, medium-, and long-term results, it contains the length of the interval, in seconds, and the total count. An average per second is also provided, rounded to an integer. Other averages per second, minute, or hour can be calculated by the application from this information, if needed.

Metrics are stored in the Saved State, to ensure persistency. They can be reset explicitly when the cell is restarted, using the -i option with parameter m (-im), which resets the metric counters.

A configuration parameter, CellMetricsEnabled, determines whether metrics are collected or not.

The mcontrol CLI is used to switch metric collection on and off, and to reset the counters. Short- and medium-term metrics are reset whenever metrics are disabled. Metrics can be retrieved through rules by data object access, or through a command. The BMC Impact Explorer console and the mgetinfo CLI can use that command.


Monitoring client to cell interactions

The received event counter does not include incoming messages that cannot be parsed as events. It does include events of nonexistent classes or events with erroneous slots. These are added to the erroneous event counter. Internally generated events are counted as received events. Dropped events include those that are dropped when an event with the same universal ID exists.

Table 7 lists the metrics data objects MC_CELL_METRIC slots.

Subject names available are:

ReceivedEventsErrorEventsDroppedEventsStoredEventsRemovedEventsPropagatedEvents

CLI commands for collecting metrics are:

mcontrol metrics on|off|resetmgetinfo [-v] metrics

Monitoring client to cell interactionsWhenever a client connects, disconnects, or modifies an event, the cell generates an internal event to represent this operation. Such events are only generated for certain clients configured by means of the ReportConnectClients and ReportModifyClients settings.

Table 7 MC_CELL_METRIC slots

Slot Description

description metric description

long_average long-term average, per second

long_interval long-term interval lengths, in seconds

long_total long-term total count

medium_average medium-term average, per second

medium_interval medium-term interval lengths, in seconds

medium_total medium-term total count

short_average short-term average, per second

short_interval short-term interval lengths, in seconds

short_total short-term total count

subject metric subject name


Monitoring client to cell interactions

The parameter value is interpreted from left to right. Settings that conflict with previous settings override the previous ones. Table 8 lists the defaults for these two parameters.

Every parameter corresponds to a reporting clients set. Such a set has a positive and a negative list. Clients that belong to the positive list will have their operation reported while operations performed by clients on the negative list will not be reported. Clients that are not named in the parameter are considered to be on the default list. The default list initially is the negative list. The default list can be modified through a special setting of the parameter.

A value for a reporting configuration parameter consists of a comma separated sequence of client names. Every client name can be prefixed with a minus sign (-) or a plus sign (+). The client name prefixed with the minus sign (-) is added to the negative list. When not prefixed, or prefixed with a plus sign (+), it is added to the positive list.

The special value ALL in place of a client name refers to the default. Including ALL or +ALL modifies the default list so it becomes the positive list. With -ALL, the default list is the negative list. Both parameters could include -ALL, as this is the default setting for clients that are not explicitly mentioned.

The superclass for client operation related events is MC_CELL_CLIENT. Table 9 lists the slots.

Table 8 Default values for client parameters

Parameter Value

ReportConnectClients browser, Console, mcontrol, mkill, mposter, msetmsg, msetrec

ReportModifyClients mposter, msetmsg, msetrec

Table 9 MC_CELL_CLIENT slots

Slot Data

client_location the location of the client as IPAddress:Port

client_name the client's name, as announced by the client, or noname

client_type type of client, such as adapter, CLI, console, cell


Configuring cell tracing

There are three subclasses of this class:

■ MC_CELL_ALLOWED_CONNECT to represent successful client connection

■ MC_CELL_UNALLOWED_CONNECT to represent a refused connection

An attempt to connect using an invalid encryption key generates an internal event, MC_CELL_UNALLOWED_CONNECT, that contains the slot reason, which details why the connection is refused.

■ MC_CELL_DISCONNECT to represent a disconnect.

Another class, MC_CELL_MODIFIED_EVENT, represents the operation of modification of an event. Table 10 lists the slots.

Configuring cell tracingTo set up cell tracing, configure

■ the trace configuration file, mcell.trace

■ tracing parameters in the mcell.conf configuration file

You can also configure cell tracing using the mcfgtrace command. For further information, see “mcfgtrace—Configuring tracing” on page 389.

Configuring mcell.trace

The trace configuration file, mcell.trace, configures the tracing of the cell’s operation. Tracing messages are divided in several levels. Every module of the cell can be configured differently. An output destination can be determined per message level and per module. Messages also can be disabled at the same granularity.


The configuration commands in mcell.trace are incremental. Every new command adds to the configuration, possibly overriding previous commands either completely or partly.

Table 10 MC_CELL_MODIFIED_EVENT slots

Slot Data

event universal event ID of the event being modified

requestor identification of the user that performed the modification


Configuring mcell.trace

Figure 10 shows the format of a configuration line in the mcell.trace file.

.

Table 11 lists the parameters that must be defined in a configuration line.

Figure 10 Format of configuration line in mcell.trace file

<Module> <Level> <Destination>SWITCH <Switch> <Destination>

Table 11 Trace configuration file parameters


Destination destination file name or predefined value for the selected trace messages or switch

predefined values:no—disables these tracing messagesconsole—sends to the console devicestderr—sends to standard error stream

Levela

a You can also specify ALL or * (wildcard) for these parameters.

message severity value level

predefined values:

■ FATAL■ ERROR■ WARNING

■ INFORM■ VERBOSE

Modulea name of module, each of which corresponds to a particular category of information, such as filtering or configuration; values are as follows:

■ ACTION■ COLLECT■ COLLMAP■ CONFIG ■ CONTROL■ DATAPROC■ DBDATAID■ DBEVTID■ DBEVTTM■ EVTLOG■ EVTPROC■ EXPORT■ FILTER

■ HEARTBEAT■ INTEVT■ MC2TEC■ MCBAROC■ MESSAGES■ METRIC■ PROPAGATE■ QUERY■ RECOVERY■ RECTRL■ REGEX■ REGULATE

■ RESULT■ ROLES■ RULES■ SERVICE■ SRVMGT■ STATBLD■ SVCMGT■ SVRCOMM■ SVRDIR■ SYNCH■ SYSPROC■ TRACE

SWITCH keyword that enables access to a sublevel or category of messages for a module

Switch switch name


Configuring a destination for cell trace output

Configuring a destination for cell trace output

You can use the tracing parameters to configure the cell to output information to a specified destination. The destination for cell trace output is determined by the value of the DESTINATION parameter in the mcell.trace file.

Possible destinations for cell trace output are:

■ the console■ the standard error stream■ an external file or files■ no trace output

In addition to sending trace output to one of these destinations, you also can send trace output to another cell. For information, see “Sending trace output to another cell” on page 76.

Sending trace output to a console

To send trace output to a console, open the mcell.trace file and set the DESTINATION parameter to the value console.

Sending trace output to the standard error stream

To send trace output to the standard error stream of the command window where the cell is running, open the mcell.trace file and set the DESTINATION parameter to the value stderr.

If the cell runs as a service or daemon, all trace output that is configured to go to stderr will be redirected to the file specified in the TraceDefaultFileName parameter in the mcell.conf file.

If you specify for the trace output to go to stderr, the trace file is truncated every time the cell restarts, and a new trace file is written.

Sending trace output to an external file

To send trace output to an external file or files, open the mcell.trace file and set the DESTINATION parameter to the path and file name of the destination file.

The cell keeps the trace file open on both UNIX and Windows systems. On UNIX, any attempt to remove the file will succeed. However, all trace output goes to an invisible file that becomes visible when the cell is restarted.


Sending trace output to another cell

A trace destination file can be located anywhere, but the BMC Impact Solutions process must have write access to that location.

Disabling trace output

To disable trace output, open the mcell.trace file and set the DESTINATION parameter to the value no.


Sending trace output to a cell allows you to capture the traces of one or more cells in a centralized location. To send the trace of one cell to another cell, the trace of the originating cell should be produced as events. Those events can be sent to the destination cell using a propagate rule.

To enable sending cell trace information to another cell, you must

■ configure which module/level combinations of trace messages will be produced as events

■ add a propagate rule to the Knowledge Base to specify which trace log events have to be propagated to which destination(s)

Once configured, the cell trace module will generate an internal event for each trace log message.

Definition of the class of trace log events

Each trace message is represented through a single MC_CELL_LOG_MSG event, as shown:

WARNING The MCELL_HOME\tmp\cellName directory is for temporary files only. A trace file placed in that directory will be deleted by the cell when it restarts. To maintain your trace file across cell sessions, place it in a different directory.

ENUMERATION MC_LOG_LEVEL 10 VERBOSE 20 INFORM 30 WARNING 40 ERROR 50 FATALEND



The log_time date and time slot is an integer in timestamp format.

The textual representation of the log message log_text uses the originating cell's local message catalog.

Configuring trace messages to be produced as log events

By default, a cell will not produce log events for its trace. This has to be enabled explicitly using the TraceEvents configuration parameter in the mcell.conf file. The value of this parameter is a comma-separated sequence of module:level combinations. Each one is optionally prefixed with a + or a - sign to indicate addition or removal, respectively, from the list. The special value ALL for module and for level indicate all modules and all levels.

For example

This setting specifies that events must be generated for messages from all modules, of all but the VERBOSE level.

For more information about the trace configuration parameters in mcell.conf, see “Trace parameters” on page 461.

MC_EV_CLASS: MC_CELL_LOG_MSG ISA MC_CELL_CONTROL DEFINES { log_time: INTEGER; -- Timestamp log_program: STRING; -- Name of the program generating the message log_module: STRING; -- Name of the module producing the message log_level: MC_LOG_LEVEL; -- Message level log_src_file: STRING; -- Source file name log_src_line: INTEGER; -- Source file line number log_msg_id: STRING; -- Unique message identifier (form BMC-IMCxxxxxxC) log_args: LIST_OF STRING; -- Message argument list log_text: STRING; -- Message text in origin's locale };END

TraceEvents=ALL:ALL,-ALL:VERBOSE

WARNING Event tracing should be configured with care, as it may produce an excessive number of events. In particular, VERBOSE level messages should not be configured as events.


Event processing errors

Adding a propagate rule to the Knowledge Base to specify which trace log events have to be propagated to which destination(s)

The propagate rule syntax is described in the BMC Impact Solutions: Knowledge Base Development reference guide.

The following is an example of a propagate rule for trace log events:

Event processing errors

When an error occurs during the processing of an event, the cell’s trace displays an error message. It also generates an internal event of class MC_CELL_PROCESS_ERROR, with the slots listed in Table 12.

Automatic notification of trace configuration changes

The cell automatically generates the following MC_CELL_LOG_CHANGED event when trace configuration is modified for a cell:

If the modification applies to all modules, then log_module=ALL.

propagate PropTraceEvents: MC_CELL_LOG_MSGto CentralAdminCell

END

Table 12 MC_CELL_PROCESS_ERROR slots

Slot Data

error_code the error number

error_goal the part of the processing command that has the error

error_message an error description message

error_source the position in the rule source where the error occurred

event the mc_ueid of the event that was being processed

MC_EV_CLASS: MC_CELL_LOG_CHANGED ISA MC_CELL_CONTROL DEFINES { log_module: STRING; -- Name of the module log_level: MC_LOG_LEVEL; -- Message level log_destination: STRING; -- Destination file name };END


Interpreting cell execution failure codes

If the modification applies to all message levels, then log_level=ALL.

The log_destination slot contains the full path to the destination file, in normalized (UNIX) form. Other possible values are:

■ no—indicates disabling■ stderr—indicates redirection to the standard error stream ■ console—indicates redirection to the console terminal

Interpreting cell execution failure codesWhen the cell runs as a daemon or a service, it has no standard output or error stream. Tracing that is configured to go to stderr will be redirected to a file in this case. The path for that file can be configured in mcell.conf. The default is MCELL_HOME\tmp\cellName\trace.

If the cell service setup fails, an error file, mcell.err, is generated. Additional service setup failures can be appended to the original file, resulting in a file content of multiple lines. Normally, each line corresponds to one failed service setup. This error file contains exit codes specific to BMC Impact Manager.

Table 13 lists the exit codes for BMC Impact Manager.

Table 13 BMC Impact Manager exit codes (part 1 of 2)

Code Description

1 invalid command line options used

2 bad home directory specification through option -l

3 no home directory could be determined

4 specified home directory is invalid

5 internal initialization failure

16 tracing configuration failed

17 system process handling module initialization failure

19 logging facility initialization failure

27 service control module initialization failure

29 Knowledge Base load failed

37 message handling module initialization failure

39 internal object initialization failure

47 event processing module initialization failure

49 saved state reload failed

57 query handling module initialization failure

59 service activation failed


Using the BMC IX Administration view to manage cells

Using the BMC IX Administration view to manage cells

You can also manage cells by using a pop-up menu in the navigation pane of the Administration view of BMC Impact Explorer to perform the following tasks:

■ connect and disconnect a cell■ view cell information■ stop and start a cell■ pause a cell■ reload cell configuration■ propagate events■ register for state change events■ collect metrics

For more information on using BMC Impact Explorer, see Part 2, “Event management administration” and the BMC Impact Solutions: Event Monitoring Operator’s Guide user guide.

Connecting or disconnecting a cell

Use the Disconnect and Connect menu commands to connect or disconnect a cell from BMC Impact Explorer.

To connect or disconnect a cell

1 Right-click the cell icon or name.

2 Select Connect or Disconnect from the pop-up menu.

67 internal object module initialization failure

69 metrics initialization failed

77 data processing module initialization failure

79 metrics activation failed

97 service setup failed

Table 13 BMC Impact Manager exit codes (part 2 of 2)

Code Description


Viewing cell information

This menu item toggles between Connect and Disconnect, depending on the state of the cell when you right-click it. The result of your action in the Administration view is reflected in the Events and Services views.

Viewing cell information

Use the View Manager Info menu command to view information about and the metrics associated with the cell selected.

To view cell information

1 Right-click a cell.

2 Choose View Manager Info.

The Impact Manager Info dialog box appears with cell property information presented on the Info tab.

3 To refresh the information in the Metrics tab of this dialog box, click Refresh in the top right corner of the tab.

Controlling cells

Use the Cell Control menu command to pause and resume, restart, and stop cells.

To pause and resume a cell


2 Choose Cell Control => Pause.

When a cell is paused, two black vertical bars appear on the cell icon.

3 To resume cell operation after a pause, right-click the cell and choose Cell Control => Resume.

To restart a cell


2 To stop a cell briefly and then restart the operation, select Cell Control => Restart.



To stop a cell


2 Select Cell Control => Stop.

3 In the Stop Confirmation dialog box, click Yes to stop the cell’s service.

If a cell has been stopped with this command, you must manually start the cell’s service for the cell to resume operations. For more information, see “Interpreting cell execution failure codes” on page 79.

To perform a StateBuild


2 To force a cell to perform a StateBuild immediately, select Cell Control => Build State.

The cell performs a StateBuild immediately, rather than waiting for the next scheduled StateBuild.


Use the Reload menu command to access the commands for reloading a cell’s configuration.

To reload all of the cell configuration


2 Select Reload => All.

All configuration files and the KB are reloaded.

To reload the knowledge base


2 Select Reload => Knowledge Base.

The KB is reloaded.


Forcing event propagation

To reload the directory


2 Select Reload => Directory.

The mcell.dir file is reloaded.

To reload cell configuration


2 Select Reload => Configuration.

The configuration files mcell.conf, mcell.propagate, and mcell.modify are reloaded.

To reload trace configuration


2 Select Reload => Trace.

The mcell.trace file is reloaded.

Forcing event propagation

You can use the Propagate command to force the selected cell to send the contents of the destination buffers to one or all its destination cells immediately.

To force propagation to all target cells


2 Select Propagate => Retry All to force propagation of the buffer contents to all target cells.

To force propagation to a single target cell


2 Select Propagate => Retry

3 In the Propagate dialog box, specify the target cell to which you want to propagate the buffer contents.


Registering for SIM notification events

4 Click OK.


BMC Impact Manager can generate events that notify you of changes to components in the SIM service model. These events are called SIM notification events. The four types of SIM notification events are

■ SIM_COMPONENT_CHANGE■ SIM_COMPONENT_DELETE■ SIM_RELATIONSHIP_CHANGE■ SIM_RELATIONSHIP_DELETE

The SIM_COMPONENT_DELETE and SIM_RELATIONSHIP_DELETE events are generated when you remove a configuration item or an impact relationship from the published service model. The SIM_COMPONENT_CHANGE and SIM_RELATIONSHIP_CHANGE events are generated when a configuration item or an impact relationship is altered by the cell because of a change in status or priority.

BMC Impact Manager generates these notification events upon request by a client. For example, the BMC Impact Portal can register to receive notification events just as a gateway client can. Another BMC Impact Manager or even the BMC Impact Manager containing the SIM model can register to receive the notification events.

NOTE In the mc_sm_notify.baroc file under mcell_home/etc/cellName/kb/classes, you can view the definitions of the SIM_NOTIFICATION_EVENT base class and the event classes SIM_COMPONENT_CHANGE, SIM_COMPONENT_DELETE, SIM_RELATIONSHIP_CHANGE, and SIM_RELATIONSHIP_DELETE.



The following slots are reported:

■ Slots for configuration item:

— status— manual_status— computed_status— self_status— impact_status— manual_status_comment— manual_status_requestor— consolidate_function— root_causes— schedule_status— cost— self_priority— impact_priority— computed_priority— maintenance_mode

■ Slot for relationships:

— true_impact

To register for notification events, you create a SIM_NOTIFICATION_REGISTRY instance in the cell, telling it which notification events to look for and which clients to forward the events to.

You perform this procedure through the BMC IX GUI or through the mposter CLI.

To register for notification events in the BMC IX

1 In the Adminstration tab, expand the cell for which you want to create a SIM_NOTIFICATION_REGISTRY data instance.

2 Expand the DATA folder.

3 Expand the MC_CELL_DATA folder.

NOTE Refer to the BMC Impact Solutions: Knowledge Base Development Reference for mposter examples that show how to register for notification events.



4 Right-click SIM_NOTIFICATION_REGISTRY.

5 Select New.

6 Fill in the editable fields in the SIM_NOTIFICATION_REGISTRY dialog box.

Table 14 SIM_NOTIFICATION_REGISTRY dialog box fields (part 1 of 2)

Field Description

mc_udid populated automatically

client_data allows you to define a rule set for the SIM notification events that your client has registered for. For example, the rule could look for the text john in the client_data to determine if it is a state change requested by john.

The content of this slot is copied to the client_data slot of the corresponding SIM notification event. Each SIM_NOTIFICATION_REGISTRY data instance must have a different value for this slot. This slot is available only in BMC Impact Manager versions 7.0.x and later.

clients comma-separated list of clients where the notification must be sent. The clients in the list must be defined in mcell.dir.

By default, the cell name is listed as the client in mcell.dir, so you do not need to change mcell.dir if you are sending events internally.

requested_notifications comma-separated list of SIM notification events for which notification is requested

■ SIM_COMPONENT_CHANGE■ SIM_COMPONENT_DELETE■ SIM_RELATIONSHIP_CHANGE■ SIM_RELATIONSHIP_DELETE

notification_mode specifies how slot values that have not changed are reported in the SIM notification event

■ DELTA — the slots whose values do not change are reported with their default values, not their current values. The default value is an empty string for symbolic values and -1 for numer ic values. See the .baroc class definition of the SIM notification event for the default slot values.

■ FULL — the current values of all slots are reported, including those that have not changed


Collecting metrics

7 Click OK.

In the Administration tab, the new SIM_NOTIFICATION_REGISTRY instance is displayed under SIM_NOTIFICATION_REGISTRY.

To delete a SIM_NOTIFICATION_REGISTRY data instance

1 Right-click the SIM_NOTIFICATION_REGISTRY data instance.

2 Select Delete.

To modify a SIM_NOTIFICATION_REGISTRY data instance

1 Right-click the SIM_NOTIFICATION_REGISTRY data instance.

2 Select Edit.

3 Make the necessary changes to the fields in the SIM_NOTIFICATION_REGISTRY dialog box.

4 Click OK to accept the changes.

Collecting metrics

Use the Metrics menu command to access the commands for working with metrics.

notifications_at_registration instructs the cell whether or not to send the current component states at the moment of registration

■ YES — instructs the cell to send the current component state at the moment of registration

■ NO — instructs the cell not to send the current component state at the moment of registration

asset_filter filter contains one class name. When you specify a class name, only state change notifications for configuration items of this class or a sub-class are generated.

Table 14 SIM_NOTIFICATION_REGISTRY dialog box fields (part 2 of 2)

Field Description


Collecting metrics

To turn metrics collection off


2 Select Metrics => Disable.

To reset collection counters


2 Select Metrics => Reset.

The collection counts are reset to 0.


C h a p t e r 3
3 Managing the BMC Impact Administration server
This chapter presents the following topics:

Overview to BMC Impact Administration server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Master or Standard BMC Impact Administration server . . . . . . . . . . . . . . . . . . . . 90Starting and stopping the BMC Impact Administration server . . . . . . . . . . . . . . . 91Command line interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Impact Administration cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

How to configure BMC Impact Administration server files . . . . . . . . . . . . . . . . . . . . . 94Defining group roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Defining permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Receiving synchronized data from the BMC Portal . . . . . . . . . . . . . . . . . . . . . . . . 102File-based authentication: updating user information. . . . . . . . . . . . . . . . . . . . . . 103Synchronizing cell information with BMC Atrium CMDB. . . . . . . . . . . . . . . . . . 105Updating cell information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Editing logging properties for IAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Defining client logging for the iadmin script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Customizing colors for severities, statuses, and priorities . . . . . . . . . . . . . . . . . . 109Defining standalone, primary, and secondary BMC Impact Administration

servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Defining an HA configuration for the Impact Administration cell . . . . . . . . . . . 112Transaction and trace logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Advanced tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Configuring the BMC Impact Administration server to support remote actions . .

114Configuring Lightweight Directory Access Protocol for BMC Impact

Administration server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115


Overview to BMC Impact Administration server

Overview to BMC Impact Administration server

The BMC Impact Administration server (IAS)

■ authenticates logins to BMC IX■ defines user groups and roles and their permissions to view and edit the BMC IX

tab views and functions■ receives the synchronization actions of the BMC Portal for users and groups ■ updates cell-related information as cells are added to or removed from the IAS

and/or BMC Atrium CMDB■ supports high availability (HA)■ controls log files■ determines the BMC IX color scheme for severities, statuses, and priorities■ provides CLIs that manage its configuration files

In this 7.1 release, the IAS determines much of the functionality that the BMC Impact Portal had controlled in previous 5.x and 7.0.x releases.

Master or Standard BMC Impact Administration server

You can select a Master or Standard IAS at installation. A Master IAS enables the Infrastructure Management feature in BMC Impact Explorer and installs an accompanying Impact Administration cell (IAC) on the same host as the Master IAS. (The Impact Administration cell is designated by default as Admin in the BMC Impact Explorer GUI.)

A Standard IAS provides all the features of the IAS, except support for Infrastructure Management and the IAC.

NOTE To switch from a Master IAS to a Standard IAS or vice versa after installation, you must uninstall the existing server and then install the new server.


Starting and stopping the BMC Impact Administration server

Starting and stopping the BMC Impact Administration server

On MS Windows, restart the IAS service through the Services window.

On UNIX, execute the run_IAS script from the appropriate path. The default path is /opt/bmc/Impact/server/bin. You must be logged on as root or as the user with the appropriate permissions to start and stop the script.

You need to restart the IAS anytime you manually edit one or more of its configuration files to initialize the configuration changes.

If you use the provided CLIs to manage the files, the IAS is automatically refreshed and does not require a restart. BMC recommends that you use the CLIs whenever possible.

Configuration files

End users can configure the following IAS files, located under the IMPACT_SOLUTIONS_HOME/server/conf directory:

■ ias.properties■ user_definitions.xml■ ldap_configuration.xml■ role_permission.xml■ group_roles.xml■ cell_info.list■ cmdb.properties■ server_logging.properties■ client_logging.properties■ color.properties

Command line interface

The IAS uses an iadmin script or command to launch the file management options. The iadmin script or command is located under the IMPACT_SOLUTIONS_HOME/server/bin directory.

NOTE The full path to the server directory under IMPACT_SOLUTIONS_HOME is /opt/Impact/server on UNIX and drive letter:\Program Files\BMC Software\Impact\server on MS Windows.


Command line interface

You can use the iadmin script or command to manage the following configuration files:

■ user_definitions.xml■ group_roles.xml■ cell_info.list■ role_permission.xml

Remember that you do not have to restart IAS to initialize your changes if you use the iadmin script or command.

The iadmin options are summarized below in Table 15 on page 92. You can display these options from the command line by entering iadmin -h.

Table 15 iadmin options

Option Description

-ac add a cell to the cell_info.list file

-mc modify a cell

-dc delete a cell

-lc list connected cells

-aru add a new user

-mru modify the user group or groups to which an existing user belongs

-dru delete an existing user

-lru list all the users

-ar add a new mapping between a role and permissions

-dr delete an existing role/permissions mapping

-lr list all the roles

-mr modify the mapping between a role and a list of permissions

-ag add a new mapping between a group and a list of roles

-dg delete a group/role mapping for a specified group

-lg list all the groups

-mg modify the mapping between a group and a list of roles

-cp change the password for an existing user

-reinit [fullsync] in an HA setup, -reinit restarts the primary or secondary server with the latest configuration data. Use the [fullsync] option on the secondary server to copy the primary server’s configuration to it and restart it with the new configuration

-sync in an HA setup, synchronizes the secondary server before the expected synchronization interval


Impact Administration cell

When using iadmin to manage files, remember to

■ enclose values within quotation marks if they contain spaces ■ omit spaces in lists■ execute the iadmin command or script from the /bin subdirectory of your

IMPACT_SOLUTIONS_HOME/server directory


The essential component of the Master IAS is the Impact Administration cell (IAC). Its default cell instance name is Admin. The IAC is a custom SIM cell that contains a specialized Knowledge Base. This cell accepts registration, configuration, and other events from BMC product components and applications. It then creates the component definitions based on the event information.

The default mcell.dir file of the IAC is as follows:

Admin is the default name of the Impact Administration cell. The default name is provided at installation. It is the same name as the IAS instance name. Its default port number is 1827.

You can change the default name of the IAC and the IAS instance name simultaneously during installation as an installation option. After installation, you can change the name of the IAC independent of the IAS instance name. You can change the default port number as long as the port number that you assign does not conflict with any other.

IAC is the alias name that other cells use to propagate events to the Impact Administration cell.

Each SIM or BEM cell that registers with an Impact Administration cell and a Master IAS should have an IAC entry in its mcell.dir file along with its own cell name, as in the following example:

cell Admin mc hostName:1827 cell IAC mc hostName:1827

cell cellName mc hostName:1828 cell IAC mc hostName:1827


How to configure BMC Impact Administration server files

How to configure BMC Impact Administration server files

This section describes the following configuration tasks:

■ Defining group roles and permissions■ Adding Impact Manager cells to the cell_info list■ Defining standalone, primary, and secondary BMC Impact Administration servers■ Defining HA configuration for Impact Administration cells■ Synchronizing cell information with BMC Atrium CMDB■ Receiving synchronized data from the BMC Portal■ Defining server-side logging levels■ Defining client-side logging levels■ Customizing the GUI color scheme for status, priority, and severity levels■ Setting LDAP authentication■ Configuring IAS to support remote actions

Depending on the goal of the task, you may need to edit multiple files.

Guidelines for manual edits

Use the iadmin script or command whenever possible. If you have to manually edit a file, follow these basic guidelines:

1 Open the file in a text editor.

2 Make the changes in the proper format.

3 Save the file without changing its extension or file path.

4 Restart IAS.

NOTE When manually editing files to enable a high availability (HA) configuration, you must follow the special guidelines outlined in the topic“Defining an HA configuration for the Impact Administration cell” on page 112.


How groups, roles, and permissions are related

How groups, roles, and permissions are related

In the IAS configuration, users are assigned to one or more groups. Each group includes one or more roles. The role determines the predefined permissions that the user has. Permissions determine which

■ BMC IX tab views ■ cells ■ events ■ collectors■ service model component objects

that the user can access, view, or edit.

Defining group roles

The ias.properties file specifies the default group roles, which are identified in the group_roles.xml file:

Group roles

IAS provides the following default groups and user roles, both of which are listed in Table 16. You can view these roles in the group_roles.xml file. Refer to Table 17 on page 98 for a complete listing of access permissions for group and role combination.

com.bmc.sms.ixs.group.role.mapping=group_roles.xml

Table 16 Groups and roles

Group Role

Full Access Full Access. Has write access to all features

Read Only Read Only. Has read-only access

Service Administrators Service Administrators. Has write access to all features

Service Managers Service Managers

Service Managers - Senior Service Managers - Senior

Service Operators Service Operators

Service Operators - Senior Senior Service Operator

Admins Full Access, Service Administrators

Operators Service Operators, Senior Service Operators

Supervisors Service Manager, Senior Service Managers


You can update user groups and roles and create new ones by editing the group_roles.xml file, shown below:

To add a new group with mapping roles

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -ag option, as in the following example:

To modify an existing group and/or mapping roles

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -mg option, as in the following example:

NOTE If you are using Lightweight Directory Access Protocol (LDAP) authentication, you must map your LDAP user groups to the IAS roles defined in the group_roles.xml file. See “Configuring Lightweight Directory Access Protocol for BMC Impact Administration server” on page 115 for more information.

<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd"><properties><entry key="Full Access">Full Access</entry><entry key="Read Only">Read Only</entry><entry key="Service Administrators">Service Administrators</entry><entry key="Service Managers">Service Managers</entry><entry key="Service Managers - Senior">Service Managers -

Senior</entry><entry key="Service Operators">Service Operators</entry><entry key="Service Operators - Senior">Service Operators -

Senior</entry><entry key="Admins">Full Access,Service Administrators</entry><entry key="Operators">Service Operators,Service Operators -

Senior</entry><entry key="Supervisors">Service Managers - Senior,Service

Operators - Senior</entry></properties>

NOTE If you’re adding a new role to the group, you must first create the role and add permissions to it using the iadmin -ar option before you create the group. See “To add a new role/mapping permission” on page 101.

iadmin -ag group=”NewGroup”:roles=”Role”

iadmin -mg group=”Service Administrators”:roles=”Service Administrators”,“Service Operators”


Any roles that you add to a group must have already been defined in the group_roles.xml file.

To delete an existing group

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -dg option, as in the following example:

You do not specify a role.

To list groups in the group_roles.xml file

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -lg option, as in the following example:

To update user groups and roles (file editor)

1 Open the group_roles.xml file in an editor.

2 Update or delete the existing entries, or add a new entry where

■ key is the name of the group■ the values inside the <entry></entry> element are the roles

3 Save and close the group_roles.xml file.

4 Restart the IAS to initialize the changes.

iadmin -dg group=”Service Operators”

iadmin -lg


Defining permissions


The default_role_permissions.xml file defines the view and edit permissions for each tab view and menu option in BMC IX. For each role, it lists the permissions in a comma-separated string as shown in the following extract for the Full Access role:

Any permission that you add or modify must be taken from the predefined default_role_permissions.xml file.

Table 17 on page 98 matches the default mapping of roles/permissions to BMC IX functionality.

....<properties><entry key="Full Access">administration_tab_view_and_access,events_tab_view_and_access,services_tab_view_and_access,services_tab_access_component_event_list,events_tab_edit_drill_down,events_tab_edit_user_event_filter,events_tab_edit_user_slot_order, .....

</entry>....</properties>

WARNING Do not modify the default_role_permissions.xml file. Use the role_permissions.xml file instead.

Table 17 BMC Impact Explorer user group mapping to functionality (part 1 of 3)

Perm

issi

on (P

) or

Righ

t (R

)

Function Choi

ces

Full

Acc

ess

Serv

ice

Adm

inis

trat

or

Serv

ice

Man

ager

, Sen

ior

Serv

ice

Man

ager

Serv

ice

Ope

rato

r, Se

nior

Serv

ice

Ope

rato

r

Read

Onl

y

BMC Impact Explorer R Events tab View X X X X X X X

R Configuration–Edit Relationship View

Edit X X X X X X

R Configuration–Edit Personal Filters

Edit X X X X X X

R Configuration–Edit Personal Attribute (Slot) Orders

Edit X X X X X X



R Configuration–Edit Personal MetaCollectors

Edit X X X X X

R Configuration–Edit Global Event Filters

Edit X X X X

R Configuration–Edit Global Attribute (Slot) Orders

Edit X X X X

R Configuration–Edit Impact Manager Group on Impact Manager Configuration window

Edit X X X X X X X

R Events tab–Jump from an Event to Its Services Impacted View

Edit X X X X

R Events tab–Reopen Events Edit X X X

R Events tab–Event Operation Supervisor Privileges (for example, close events owned by someone else)

Edit X X X

R Events tab–Assign Events Edit X X X

R Events tab–Add Image View Edit X X X X

R Events tab–Delete Image View

Edit X X X X

R Services tab View X X X X X

R Services tab–Search for Service Components

Edit X X X X

R Services tab–Event List View of a Service Component

View X X X X X

R Services tab–Edit My Services Navigation Tree

Edit X X X X

R Services tab-Create, Edit, Delete Relationship between components

Edit X X X X

R Services tab–Set or Remove Manual Status (of a component) Action

Edit X X X X

Table 17 BMC Impact Explorer user group mapping to functionality (part 2 of 3)Pe

rmis

sion

(P) o

r Ri

ght

(R)

Function Choi

ces

Full

Acc

ess

Serv

ice

Adm

inis

trat

or

Serv

ice

Man

ager

, Sen

ior

Serv

ice

Man

ager

Serv

ice

Ope

rato

r, Se

nior

Serv

ice

Ope

rato

r

Read

Onl

y



Full Access role permissions

Members of the Full Access user group can view, edit, and create all components and relationships, including the objects and relationships that were created by other users. Service Administrators, Service Managers - Senior, and Service Managers user groups can edit components and their associated relationships only if they already have write permission on the objects.

If the user group member who creates a component does not specify otherwise, then the Read Users and Write Users slots of the component are populated by the user group of the BMC IX login account. To illustrate, if a user account belonging to the Service Administrators group creates a component, then by default its Read Users and Write Users slots are populated by the user group Service Administrators.

Adding customized role/permission mappings

Use the role_permissions.xml file to add customized role/permission mappings. The com.bmc.sms.ixs.role.permission.mapping property of the ias.properties file specifies this default file for containing customized role/permission mappings, as shown in the following excerpt:

R Services tab–Set or Clear Maintenance Mode (of a Component) Action

Edit X X X X

R Administration tab View X X X X

R Timeframes Edit X X X X

R Administration tab: all actions

Edit X X

R Infrastructure Management subtab

Edit X X

R Infrastructure Management subtab: all actions

Edit X X

com.bmc.sms.ixs.role.permission.mapping=role_permissions.xml

Table 17 BMC Impact Explorer user group mapping to functionality (part 3 of 3)

Perm

issi

on (P

) or

Righ

t (R

)

Function Choi

ces

Full

Acc

ess

Serv

ice

Adm

inis

trat

or

Serv

ice

Man

ager

, Sen

ior

Serv

ice

Man

ager

Serv

ice

Ope

rato

r, Se

nior

Serv

ice

Ope

rato

r

Read

Onl

y



If you create a separate .xml file to contain your customized role/permission mappings, you must specify its name in the com.bmc.sms.ixs.role.permission.mapping property of the ias.properties file. Then you must restart IAS to initialize the change.

The user-defined .xml file does not override the default file. Its individual entries override matching ones in the default file. Any entries in the default file that are not overridden by matching ones in the user-defined file remain valid.

When you use the iadmin script to add, modify, or delete a role/permission mapping, the change is saved to the role/permissions file specified by the com.bmc.sms.ixs.role.permission.mapping property.

To add a new role/mapping permission

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -ar option, as in the following example:

To modify an existing role/mapping permission

You can modify the permissions associated with a role in a user-defined roles/permissions file. The modified entry is saved to the user-defined roles/permissions file, which overrides any corresponding role entry in the default file.

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -mr option, as in the following example:

To delete an existing role/mapping permission

You can delete an existing role in a user-defined roles/permissions file.

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -dr option, as in the following example:

iadmin -ar role=”Test”:permissions=”services_tab_delete_component”

iadmin -mr role=Test:permissions=”services_tab_view_and_access”

NOTE If the role to be deleted only exists in the default file, then an entry is added to the user-defined file. The entry contains the role name only, without any permissions associated with it. Because the user-defined entry overrides the default one, the role is effectively deleted.

iadmin -dr role=Test


Receiving synchronized data from the BMC Portal

The entry role=Test is written to the user-defined file and effectively overrides any identical role in the default file.

To list roles defined in roles/permissions mapping files

You can list all roles defined in both the default and in the user-defined roles/permissions mapping files.

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -lr option, as in the following example:

Receiving synchronized data from the BMC Portal

BMC Portal 2.5 has a task named Synchronize Users with IAS. This a manual synchronization feature that pushes data one way from the BMC Portal to IAS. The synchronization is available in Standard and BMC Atrium installations.

The BMC Portal connects with IAS through IAS’s administrative account. The default password is IAS$Admin$. (There is no user name associated with administrative access.) During synchronization, only BMC Portal user groups that have defined permissions in BMC IX are exported. You can check for the permissions in the User Groups task off of the Configure tab in the BMC Portal. Look for permissions that begin Impact Explorer.

BMC Portal groups are mapped to IAS roles with the same name. When a BMC Portal group is exported to IAS, a new role is created in IAS with the same name. To illustrate, if the BMC Portal group abc is exported to IAS, a role/permission mapping is created in IAS for abc and all the permissions that abc maps to in the BMC Portal. Then IAS creates a group/role mapping abc/abc.

User passwords are not exported, but are set to the default value user.

Any cells that are added to the BMC Portal are registered with IAS.

For the Atrium installation scenario, BMC Atrium CMDB parameters are not synchronized with either the BMC Portal or IAS. They need to be added manually.

iadmin -lr


File-based authentication: updating user information

In LDAP authentication, the IAS and BMC Portal connect separately to an LDAP server. The mappings of BMC Portal groups to LDAP group mappings are sent to IAS as group to role mappings. The BMC Portal uses the fully qualified distinguished name for an LDAP group (for example, ldapG1.bmc.com) while the IAS uses the common name (ldapG1). For example, if the BMC Portal group abc maps to several LDAP groups—for example, ldapG1.bmc.com and ldapG2.bmc.com—then IAS creates the following group/role mappings: abc/abc, ldapG1/abc, and ldapG2/abc.

To set up LDAP authentication in IAS, see “Configuring Lightweight Directory Access Protocol for BMC Impact Administration server” on page 115.


You choose file-based authentication in test environments or in small production environments. Using file-based authentication, you can manage users of the BMC EM and SIM products independent of your corporate environment.

To enable file-based authentication

1 In the IAS.properties file, ensure that the com.bmc.sms.ixs.enable.file.login parameter is set equal to true.

2 In the user_definitions.xml file, define the user’s attributes. These include user id, password, group names and their descriptions, and so forth.

You can use the iadmin command to update user information in the user_definitions.xml if you have enabled file-based authentication (see “File-based authentication: updating user information” on page 103). You can add, modify, or delete users, and you can modify the password of an existing user.

The user_definitions.xml file defines a userid, password, and group of a specified user, as in the default example below:

<?xml version="1.0" encoding="UTF-8"?><userList xmlns="urn:bmc:schemas:impact" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:bmc:schemas:impact user_definitions.xsd "><user userid="user">

<password encrypted="false">user</password><groupList>Full Access</groupList><description>This is optional</description>

</user></userList>



To add a user entry

When adding a user entry, enter a plain-text password with the <password encrypted> element set equal to false. When the file is initialized, the password becomes encrypted and the <password encrypted> element is changed to true.

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -aru option, as in the following example:

To modify a user group of an existing user

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -mru option, as in the following example:

To delete an existing user

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -dru option, as in the following example:

To modify a password of an existing user

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -cp option, as in the following example:

To list all users in the user_definitions file

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -lru option, as in the following example:

iadmin -aru loginId=qa:password=qa:usergroups:”Full Access”:description:”Full Access User Group”

iadmin -mru loginId=qa:usergroups:”Read Only”

iadmin -dru loginId=qa

iadmin -cp loginId=qa:oldPassword=qa:newPassword=bsm

iadmin -lru


Synchronizing cell information with BMC Atrium CMDB

Synchronizing cell information with BMC Atrium CMDB

You can synchronize your cell information with the BMC Atrium CMDB by modifying the cmdb.properties, an excerpt of which is shown below:

To synchronize with the BMC Atrium CMDB

1 Change the com.bmc.sms.ixs.cmdb.enable.sync property to true.

2 Enter the fully qualified domain name or the IP address of the host system where the AR Server resides.

3 Enter the port number of the AR Server. If the AR Server is using portmapper, then enter 0.

4 Enter the user Id of the AR Server.

5 Enter the password in plain text. When IAS restarts, it encrypts the password and displays the encryption in the file.

6 Restart the IAS.

......# "true" if this IAS will synchronize with the CMDB server.com.bmc.sms.ixs.cmdb.enable.sync=false

# host name for AR servercom.bmc.sms.ixs.cmdb.host.name=localhost

# port number for AR servercom.bmc.sms.ixs.cmdb.port.number=0

# user id for AR servercom.bmc.sms.ixs.cmdb.user.id=Demo

# password for AR server.......com.bmc.sms.ixs.cmdb.password=


Updating cell information


You can add cells to the IAS, modify cells, delete cells from the IAS, and list the cells that are currently registered with the IAS. This cell information is stored in the cell_info.list, an example of which is shown below:

Each cell entry contains the following information:

To add a cell

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -ac option, as in the following example:

cell test mc test.company.com:1828 Production *cell.Admin IAC mc localhost:1828 Production *cell.SIM qa mc qa.company.com:1828 qa.company.com:1888 Test "Full Access, Read Only"

Table 18 Cell entry format in cell_info.list

Entry Description

cell required. Each entry must begin with “cell.” The cell type is appended after cell, with a period separating cell and the type. The available cell types are SIM, BEM, and Admin. IAS retrieves the type from the cell and appends to the entry.

name matches the name in the mcell.dir file of the cell server

key The default value is mc.

primaryHost system where the cell resides. It can be an unqualified or fully qualified host name, or an IP address.

primaryPort port number of the cell

failoverHost optional. If this is an HA pair, then enter the system name where the secondary cell resides.

failoverPort optional. If this is an HA pair, then enter the port number that the secondary cell uses.

environment Production or Test

usergroups user group or groups who can access this cell. If all groups can access the cell, enter an asterisk. Otherwise enter the user group name, separating multiple groups with commas. If the group name contains a space, use double quotation marks to enclose the entire name.

iadmin -ac name=testCell:key=mc:primaryHost=moondog:primaryPort=1828:failoverHost=suncat:failoverPort=1828:environment=Production:usergroups=*



The cell information is added to the cell_info.list. It is also added to the BMC Atrium CMDB if the cell is synchronized with BMC Atrium CMDB as defined in the cmdb.properties.

To modify a cell

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -mc option. After you specify the cell name, you only to need to include the options that you are changing, as in the following example:

In this example, the secondary cell is removed and thus failoverHost is defined by null. The environment is changed from Production to Test. If you were to change the primaryHost or primaryPort value, then IAS connects to the cell to retrieve its type.

All updates are saved into the cell_info.list and to the BMC Atrium CMDB, if the cell is synchronized with the BMC Atrium CMDB.

To delete a cell

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -dc option to delete a cell from the cell_info.list, as in the following example:

If the cell is synchronized with the BMC Atrium CMDB, it is removed from the CMDB.

To list cells

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -lc option, as in the following example:

iadmin -mc name=testCell:failoverHost=null:environment=Test

iadmin -dc name=testCell

iadmin -lc


Editing logging properties for IAS

Editing logging properties for IAS

IAS generates a default log file, ias<numeral>.log, under the IMPACT_SOLUTIONS_HOME/server/tmp/ias directory. This log file captures diagnostic trace messages generated by the server’s activity. You can manually edit the

■ logging level■ file name and path■ maximum size of each file■ number of log files in a cycle

This information is defined in the server_logging.properties file. describes the properties that you would typically modify:

After you make changes, save the server_logging.properties file, and restart IAS.

Defining client logging for the iadmin script

You can define the log message level that is directed to the command console when you execute the iadmin script. The default level is SEVERE, meaning that notices of only the most crucial changes are transmitted to the command console. All other notices are omitted.

The client log information is defined in the client_logging.properties file. You can manually edit the log level by changing the value of the java.util.logging.ConsoleHandler.level property. All levels below the one you specified are omitted from the client log.

Table 19 Server logging properties

Property Description

.level message levels that the log captures. The default is INFO. The log ignores all levels lower than the specified one. The values range from SEVERE to FINEST.

java.util.logging.FileHandler.pattern specifies the file name, file path, and the generated numeral that distinguishes the log file cycle. The default pattern /tmp/ias/ias%g.log.

java.util.logging.FileHandler.limit the maximum size of each log file in bytes. The default is 5 million bytes (about 5 MB).

java.util.logging.FileHandler.count maximum number of log files in each cycle. The default is 10. After the maximum of files is reached, a new cycle starts and the new log files override the existing ones in sequence.


Customizing colors for severities, statuses, and priorities

After you make changes, save the client_logging.properties file.

Customizing colors for severities, statuses, and priorities

You can modify the default colors that BMC IX uses fill in row backgrounds in tables to indicate event severities, service component statuses, and priority computation by changing the hexadecimal numbers that represent the amount of red, green, and blue (RGB) in the color. The default colors are defined in the color.properties file.

You should be consistent when changing the color values of the same parameter. For example, if you change the color for DOWN to indicate event severity, you should make the same change to the DOWN parameter for service component status. Otherwise, if you specific different colors, one color change overrides the other.

After you make changes, save the color.properties file, and restart IAS.

Defining standalone, primary, and secondary BMC Impact Administration servers

By default the IAS is configured to work in standalone mode. However, after installation, you can choose to implement an HA configuration, in which define an HA pair of primary and secondary servers to handle failover situations.

You must first install another BMC Impact Administration server on a second system. Rerun the installation, and make the appropriate Standard or Master IAS selection for the second system. Assign a unique name to each instance of IAS that you install.

NOTE These changes to the color properties do not affect the icon colors.

NOTE At installation, you can choose to install and implement a high availability (HA) configuration for the IAS. If you select to define an HA setup for the Master IAS, the accompanying IAC is also defined as HA automatically.

NOTE If you define a standalone Master IAS as an HA pair, you must also define its accompanying IAC as an HA pair.



When you define primary and secondary servers, you also define the synchronization properties for both. The synchronization process updates IAS records and files, such as the following files:

■ user_definitions.xml■ group_roles.xml■ role_permissions.xml■ cmdb.properties■ cell_info.list

During synchronization of HA pairs, data is carried from the primary to the secondary IAS and from the secondary to the primary. Each server of an HA pair has its own ias.properties and logging configuration files. These files are not synchronized.

IAS synchronization properties

You can define your IAS synchronization properties by modifying the following properties in its corresponding ias.properties file.

NOTE To enable synchronization between servers, they must be installed on the same platform: either all on MS Windows or all on the same UNIX operating system (for example, Solaris to Solaris, Linux to Linux).

Table 20 IAS synchronization properties (part 1 of 2)


com.bmc.sms.ixs.transaction.history for HA definitions. The number of days that entries in the transaction log are kept before they are removed by synchronization. The default is 5 days.

com.bmc.sms.configService.keepBackupFile for standalone and HA definitions. Indicates whether the IAS maintains a backup copy (.bak extension) when it writes a file. The default is false.

com.bmc.sms.ixs.sync.interval for HA definitions. Interval in minutes between synchronization requests from a secondary server to a primary server. The default is 15 minutes.

com.bmc.sms.ixs.primary.server for HA definitions. The host name or IP address of the primary server along with its default port number in the following format: host:port.

You define the primary server in the ias.properties file of the paired secondary server.



iadmin reinit/sync options

You can use the following iadmin reinit/sync options to restart a server, copy the primary server’s configuration to its secondary server, or start a synchronization between the two servers immediately.

From the /bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, you can

■ execute the iadmin -reinit command on the primary or secondary server to restart the server with the latest configuration data

You usually execute the iadmin -reinit command on the primary server after you have manually edited any of its files.

■ execute the iadmin -reinit fullsync command on the secondary server only to copy the primary server’s configuration to it and to restart it with the new configuration

You should execute the iadmin -reinit fullsync command on the secondary server the first time you start it after you have installed it.

■ execute the iadmin -sync command on the secondary server to start the synchronization process immediately instead of waiting until the next synchronization interval

Use the iadmin -reinit and iadmin -reinit fullsync commands to restart the respective server anytime you have manually edited one or more of the primary server’s configuration files.

com.bmc.sms.ixs.backup.server for HA definitions. The host name or IP address of the secondary server along with its default port number in the following format: host:port.

You define the secondary server in the ias.properties file of the primary IAS server.

com.bmc.sms.ixs.server.mode the server role. Options are standalone (default), primary, and backup.

If you specify primary or backup, then of course you must complete the primary and backup server entries in the respective ias.properties files of the two servers.

Table 20 IAS synchronization properties (part 2 of 2)



Defining an HA configuration for the Impact Administration cell

Your typical use case would look as follows:

1. Manually edit the configuration files on the primary server.

2. Execute the iadmin -reinit command on the primary server.

3. Execute the iadmin -reinit fullsync command on the secondary server.

(BMC recommends that you use the iadmin CLI to edit files whenever possible, thereby eliminating the need to restart the server.)

Defining an HA configuration for the Impact Administration cell

As a general practice, you configure the IAC as an HA pair whenever you configure the Master IAS as an HA pair. Use this table as a guideline for changing the respective mcell.dir files of the primary IAC on one host system and the secondary IAC on the second host system:

Remember that the primary IAC resides on the same host as the primary Master IAS and the secondary IAC resides on the same host as the secondary Master IAS.

After you define the entries in the mcell.dir files, you must modify the respective mcell.conf files as you would any normal cell that you are configuring for high availability. Refer to “Configuring high availability cells” on page 50 for more information.

Transaction and trace logs

The IAS automatically generates the log files listed in Table 22 on page 113.

Table 21 mcell.dir entries for HA pair of Impact Administration cells

Primary IAC on Host 1 Secondary IAC on Host 2

cell Admin mc host1:1827 host2:1827

cell IAC mc host1:1827 host2:1827

cell Admin mc host2:1827 host1:1827

cell IAC mc host2:1827 host1:1827


Transaction and trace logs

You can edit the properties of the diagnostic trace log ias0.log in the server_logging.properties file.

Example trace output

An example trace excerpt, showing INFO level messages, is shown below:

Table 22 IAS log files

File name Description

transaction.log stored under IMPACT_SOLUTIONS_HOME/server/log/ias. Records transactions for file synchronization

record_transaction.log stored under IMPACT_SOLUTIONS_HOME/server/log/ias. Records transactions for record synchronization

ias0.log stored under IMPACT_SOLUTIONS_HOME/server/tmp/ias. This is the diagnostic trace log. They are numbered incrementally. A new log file is created whenever IAS restarts or when the current log file reaches its specified maximum size.

When the maximum log file count is reached, then the process repeats itself because only one cycle of logs is maintained.

The new log file is always named ias0.log. The logger renames the existing log files in ascending chronological order. So the earliest log file is ias1. log and the oldest log file in the cycle has the greatest number.

INFO: Sending to primary server: <SyncReqRecordLog> <ETX>Jul 4, 2007 2:20:42 AM com.bmc.sms.ixscomm.server.CommandParser setTokenizer

INFO: successfully retrieved fileC:\work\SIM\dev\sms\main\java\ixs\server2\data\cell_info.listJul 4, 2007 2:20:42 AMcom.bmc.sms.ixscomm.configservice.manager.PlainFileManager setFile

INFO: successfully saved fileC:\work\SIM\dev\sms\main\java\ixs\server2\data\cell_info.list Jul 4, 2007 2:20:42 AM com.bmc.sms.ixscomm.configservice.manager.IMInfoManageraddCell


Advanced tasks

Advanced tasksThis section describes two tasks that require background knowledge of third-party products and utilities. The task “Configuring the BMC Impact Administration server to support remote actions” on page 114 requires knowledge of secure protocols, and the task “Configuring Lightweight Directory Access Protocol for BMC Impact Administration server” on page 115 requires knowledge of Lightweight Directory Access Protocol (LDAP).

The person who performs these tasks should have the appropriate background knowledge.

Configuring the BMC Impact Administration server to support remote actions

If the BMC Impact Administration server and the target application share an MS Windows platform, then remote actions are enabled by default. The IAS relies uses New Technology LAN Manager (NTLM), v. 2, to secure communications between MS Windows systems.

If the BMC Impact Administration server and the target application share a UNIX Solaris or Linux platform, then remote actions are enabled by default also but through the Secure Shell (SSH), v. 2, protocol. SSH, v. 2, should be installed with the Solaris or Linux operation system. You may have to configure it for use if it is not already enabled.

If either the BMC Impact Administration server or the target application is installed on an HP-UX or an AIX system, then you must download the SSH package from a third-party vendor to the HP-UX or AIX system. Then you must configure it to enable remote actions.

If the BMC Impact Administration server resides on a UNIX or Linux system and the the target application sits on an MS Windows system, then you must download the SSH package to the MS Windows systems. Then configure it to enable remote actions.

BMC recommends that you use SSH to secure communications.

Enabling Telnet

By default, the Telnet protocol is turned off. Telnet is not a secure protocol. User name and password credentials that you enter are sent in plain text to the remote system. Also, the Telnet session times out during the creation of support packages.


Configuring Lightweight Directory Access Protocol for BMC Impact Administration server

However, you can enable Telnet and ftp. You will need to start the Telnet service on the Windows system. You also need to modify the centraladmin-strings.properties file located under the IMPACT_SOLUTIONS_HOME/server/conf/resources path.

The relevant section of the centraladmin-strings.properties file is depicted below:

To enable Telnet and ftp, modify the properties as follows:

Restart the BMC Impact Administration server to initialize your changes.


Use Lightweight Directory Access Protocol (LDAP) authentication in a production environment. In this way, you can link your BMC Impact Administration server (IAS) authentication with your corporate infrastructure for user authentication and authorization management. Using LDAP authentication allows you to use the same user definitions across multiple BMC product lines. After you define your LDAP user and user groups, you can map your LDAP user groups to IAS user groups. Any users you add to a LDAP user group share the permissions of the IAS user group to which you have mapped.

You can use a single sign-on to access multiple products. You do not have to create a separate user definition and sign-on information for each product.

To enable LDAP authentication for the IAS on a Windows system, your login account must have administrator privileges on the target system. On a UNIX system, you must be logged in as root or under a user account with write and execute permission on the IMPACT_SOLUTIONS_HOME/server directory.

unix.execute.command=com.bmc.sms.marimba_cas_tools.SSHTaskunix.putfile=com.bmc.sms.marimba_cas_tools.SCPTaskunix.getfile=com.bmc.sms.marimba_cas_tools.SCPTask

NOTE Make sure that you are familiar with security protocols before modifying these settings.

unix.execute.command=com.bmc.sms.marimba_cas_tools.SSHTask,com.bmc.sms.marimba_cas_tools.TelnetTaskunix.putfile=com.bmc.sms.marimba_cas_tools.SCPTask,com.bmc.sms.marimba_cas_tools.FTPTaskunix.getfile=com.bmc.sms.marimba_cas_tools.SCPTask,com.bmc.sms.marimba_cas_tools.FTPTask



Set up your LDAP server according to your LDAP server procedures. Next, enable the LDAP login entry in the ias.properties file. Then you can your LDAP configuration information for each LDAP server that you’re enabling.

To enable the LDAP login entry in the ias.properties file

1 In an editor, open the IMPACT_SOLUTIONS_HOME/server/conf/ias.properties file, where IMPACT_SOLUTIONS_HOME/server is the installation directory of your server. Locate the com.bmc.sms.ixs.enable.ldap.login parameter, and set it equal to “true”:

2 Save and close the ias.properties file.

3 Restart IAS.

4 In an editor, open the IMPACT_SOLUTIONS_HOME/server/conf/jaas.conf file. Do not modify this file. Verify that it contains an entry such as the following:

5 Close the file.

To add LDAP configuration information

You are now ready to add your LDAP configuration information to the IMPACT_SOLUTIONS_HOME/server/conf/ldap_configuration.xml file. Figure 11 on page 117 depicts a sample ldap_configuration.xml file with a single LDAP server configuration:

NOTE If you are using a solution that requires the BMC Portal and/or BMC Atrium CMDB, you may need to set up LDAP authentication on the BMC Portal server and on the AR System server. Refer to the BMC Portal Getting Started guide for information on setting up LDAP authentication on the BMC Portal server. Refer to the BMC Remedy Action Request System 7.1 Integration with Plug-ins and Third-Party Products for information on setting up LDAP authentication on the AR System server.

#-----------------------------------------------------------------# Enable/disable LDAP login module.# When it is enabled, "ldap_definition.xml" file has to be filled.#-----------------------------------------------------------------com.bmc.sms.ixs.enable.ldap.login=true

com.bmc.sms.ixscomm.authentication.ldap.LdapLoginModule Sufficient;



Figure 11 Excerpt from ldap_configuration.xml file

1 Make only one <ldap></ldap> entry for each LDAP server you are using. You can specify an alias for the LDAP name.

2 Using Table 23 on page 117 as a guide, complete the LDAP configuration parameters.

<?xml version="1.0" encoding="UTF-8"?><ldapList xmlns="urn:bmc:schemas:impact" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:bmc:schemas:impact ldap_definitions.xsd"> <ldap alias="test"> <host>majestix.bmc.com</host> <port>389</port> <version>3</version> <baseDN>DC=pinfrastruct,DC=rd,DC=bmc,DC=com</baseDN>

<connectionUserName>[email protected]</connectionUserName> <useridAttribute>sAMAccountName</useridAttribute> <useSSL>false</useSSL> <memberOfAttribute>memberOf</memberOfAttribute> <userSearchFilter>(objectClass=organizationalPerson)</userSearchFilter> <groupSearchFilter/> <connectionPassword encrypted="true">fisSCap4ZhOLOUENWPLe==

</connectionPassword> </ldap>......</ldapList>

Table 23 LDAP configuration parameters (part 1 of 2)

LDAP parameter Description

host the fully qualified host name where LDAP is installed. You should be able to verify the connection between the LDAP server and the IAS using the ping command.

port port number by which to connect to the LDAP server. Normally the nonsecure port number is 389. The secure (SSL) port number is 636.

version LDAP version number. The most recent version is version 3.

baseDN top-level directory of the LDAP structure. This is the base Fully Qualified Distinguished Name (FQDN) from which all user and group queries occur. The Distinguished Name represents an object and the path to the object in the directory hierarchical namespace. Objects are ordered from most to least specific.

connectionUserName login Id that the programs use to connect to the LDAP server

userIdAttribute attribute in the user entry that contains the login Id

useSSL indicates whether LDAP authentication is using OpenSSL

memberOfAttribute attribute in the user entry that specifies whether the user belongs to certain user groups



3 After completing your changes, restart the IAS.

■ On MS Windows, restart the IAS service through the Services window.

■ On UNIX, execute the run_IAS script from the appropriate path. (The default path is /opt/bmc/Impact/server/bin.) You must be logged on as root or as the user with the appropriate permissions to start and stop the script.

The IAS connects to the LDAP servers one at a time in succession. When it finds a user’s matching login credentials, the IAS returns the match. It does not attempt to connect to other LDAP servers that might be defined in the ldap_configuration.xml file.

Next, after you add your LDAP server or servers, you can add a user group and assign it a user role.

To add a new user group with mapping roles

userSearchFilter search filter that the LDAP server uses to look up a user entry. If left blank, this parameter defaults to the following filter:

“(|(objectClass=person)(objectClass=user)(objectClass=inetOrgPerson)(objectClass=organizationalPerson))”

groupSearchFilter search filter that the LDAP server uses to look up a user group entry. If left blank, this parameter defaults to the following filter:

“(|(objectClass=group)(objectClass=groupOfUniqueNames)(objectClass=groupOfNames)(objectClass=groupOfUrls))”

connectionPassword authentication password (encrypted) that is used to connect to the LDAP server

Note: Set the encrypted attribute equal to false and then enter the password in plain text. When IAS restarts, it encrypts the password and changes the encrypted attribute value from false to true.

NOTE If you’re adding a new role to the group, you must first create the role and add permissions to it using the iadmin -ar option before you create the group. See “To add a new role/mapping permission” on page 101.

Table 23 LDAP configuration parameters (part 2 of 2)

LDAP parameter Description



From the/bin subdirectory of your IMPACT_SOLUTIONS_HOME/server directory, execute the iadmin command using the -ag option, as in the following example:

The new entry would look similar to the following in the group_roles.xml file:

To add the user group name to the cell’s KB definition files

You add the user group name to the collector definition and operation definition files in the connected cell or cells.

1 Add the user group name to each of the following collector definition files. Where indicated, associate the read, write, and execute permissions (r, w, x) with the group name entry:

■ biip4p_collectors.mrl■ catchall_collector.mrl■ mc_bylocation_collectors.mrl■ mc_bystatus_collectors.mrl■ mc_evr_collectors.mrl ■ mc_sm_collectors.mrl■ mcxpcoll.mrl■ self_collector.mrl

You may need to change the file permissions on these files before editing them.

Code examples follow that show sample modifications to each file:

biip4p_collectors.mrl

iadmin -ag group=”NewGroup”:roles=”Role”

<entry key="nameofUserGroup">IAS_defaultRoleName</entry>

collector PATROL :{ r['Service Administrators','Service Operators - Senior','Service Operators','Service Managers - Senior','Service Managers',’nameofUserGroup’] w['Service Administrators','Service Operators - Senior','Service Operators','Service Managers - Senior','Service Managers',’nameofUserGroup’] x['Service Administrators','Service Operators - Senior','Service Operators','Service Managers - Senior','Service Managers',’nameofUserGroup’]}END



catchall_collector.mrl

mc_bylocation_collectors.mrl

mc_bystatus_collectors.mrl

collector 'All Events' :{ r['Service Administrators',’nameofUserGroup’] w['Service Administrators',’nameofUserGroup’] x['Service Administrators',’nameofUserGroup’]}

collector 'By Location':{r['Service Administrators',’nameofUserGroup’]w['Service Administrators',’nameofUserGroup’]x['Service Administrators',’nameofUserGroup’]

}END

...............

collector 'By Location'.*:{ r['Service Administrators','Service Operators - Senior','Service Operators','Service Managers - Senior','Service Managers',’nameofUserGroup’] w['Service Administrators','Service Operators - Senior','Service Operators','Service Managers - Senior','Service Managers',’nameofUserGroup’] x['Service Administrators','Service Operators - Senior','Service Operators','Service Managers - Senior','Service Managers',’nameofUserGroup’]}:

collector 'By Status':{ r['Service Administrators','Service Operators - Senior',’nameofUserGroup’] w['Service Administrators','Service Operators - Senior',’nameofUserGroup’] x['Service Administrators','Service Operators - Senior',’nameofUserGroup’]}END



mc_evr_collectors.mrl

You can add a user group to this .mrl file, but be sure not to edit any other parameter or value.

mc_sm_collectors.mrl

You can add a user group to this .mrl file, but be sure not to edit any other parameter or value.

collector MC_Related_Events:{r['Service Administrators',’nameofUserGroup’]w['Service Administrators',’nameofUserGroup’]x['Service Administrators',’nameofUserGroup’]

}END

collector MC_Related_Events.*:{r['Service Administrators',’nameofUserGroup’]w['Service Administrators',’nameofUserGroup’]x['Service Administrators',’nameofUserGroup’]

}:EVENTwhere [mc_relation_source: != '']create $THIS.CLASSEND

collector MC_SMC_Events:{r['Full Access', 'Service Administrators'’nameofUserGroup’]w['Full Access', 'Service Administrators'’nameofUserGroup’]x['Full Access', 'Service Administrators'’nameofUserGroup’]

}END

collector MC_SMC_Events.*:EVENT where [$THIS.mc_smc_id != ""]create cond($THIS.mc_smc_type == '', "Unknown", $THIS.mc_smc_type)END

collector MC_SMC_Events.*.Impacts:EVENT where [$THIS.mc_smc_impact == 1]END

collector MC_SMC_Events.*.History: SMC_STATE_CHANGE END



mcxpcoll.mrl

self_collector.mrl

2 Next, assign the group name to the appropriate event management operations in the im_operations.mrl file. Each event operation can be performed by a predefined set of groups, as shown in Table 24.

collector 'By Location'.*.*.*.*.*:PATROL_EV where [p_application: not_equals '']create $THIS.p_applicationEND

{r[‘nameofUserGroup’]w[‘nameofUserGroup’]x[‘nameofUserGroup’]}

collector self :{ r['Full Access', 'Read Only',‘nameofUserGroup’] w['Full Access', ‘nameofUserGroup’] x['Full Access', ‘nameofUserGroup’]}END

Table 24 Event operations

Event operation Group names

Acknowledge Service Administrators, Service Operators - Senior, Service Operators

Take Ownership Service Administrators, Service Operators - Senior, Service Operators

Decline Ownership Service Administrators, Service Operators - Senior, Service Operators

Close Service Administrators, Service Operators - Senior, Service Operators

Assign to Operation Service Administrators, Service Operators - Senior

Set Priority Service Administrators, Service Operators - Senior

Reopen Service Administrators, Service Operators - Senior



An example of a group name assignment to a specific event management action is shown below:

3 Recompile the cell’s kb using the mccomp command, as in the following example:

You must include the path to the manifest.kb file.

4 Restart the cell using the mcell command.

action im_operations.Acknowledge: { ['Service Administrators','Service Operators - Senior','Service Operators',‘nameofUserGroup’] }

mccomp -n cellName | manifestKBFilePath


C h a p t e r 4
4 Managing the BMC Impact Portal
This chapter describes how to configure the BMC Impact Portal and contains the following topics:

Accessing the BMC Impact Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Starting and stopping the BMC Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Starting and stopping the BMC Portal on Windows . . . . . . . . . . . . . . . . . . . . . . . 127Starting and stopping the BMC Portal on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Configuration tasks for BMC Impact Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Registering production and test cells in the BMC Impact Portal . . . . . . . . . . . . . 128Customizing BMC Impact Portal configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Configuring Dashboard Table View columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Configuring Events Table columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Changing the Console Navigation Tree icons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Configuring Status Table columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Configuring object link synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Configuring reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Configuring the number of events displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Changing the maximum number of recent items displayed . . . . . . . . . . . . . . . . 134Configuring the general properties displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Setting up Image Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Modifying connection settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Configuration file and parameter definitions for BMC Impact Portal. . . . . . . . . . . . 137smsIwc/application.properties file and parameters . . . . . . . . . . . . . . . . . . . . . . . 137smsConsoleServer/application.properties file and parameters. . . . . . . . . . . . . . 138ixs.properties file and parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141


Accessing the BMC Impact Portal

Accessing the BMC Impact PortalCommunication between the Web browser and the BMC Portal is encrypted and requires the use of the https:// communication protocol.

To access the BMC Portal

1 In the browser’s address box, type the BMC Portal URL address using the following syntax:

https://computerName:portNumber

■ computerName—represents the host name of the BMC Portal server

■ portNumber—represents the port number assigned to the BMC Portal; the default port number is 443

2 In the security alert window, click Yes to accept the security certificate.

3 In the logon screen, type your logon user name and your password, and then click Log On.

If you receive the message user name and password invalid after entering a valid user name and password, the BMC Portal server might not be running. Start the BMC Portal and log on to it again.

Starting and stopping the BMC Portal The installation process does not automatically start the BMC Portal service. The following topics describe how to start and stop the BMC Portal service on both Windows and UNIX.

NOTE The Transport Layer Security (TLS) protocol is used to secure communication between the BMC Portal Application Server and the Web browser.

WARNING If you leave your BMC Portal session by selecting a different URL and then return to the session before the expiration of the timeout period, the BMC Portal fails to prompt you for your user name and password. To ensure the integrity of the session, log out of the session every time you leave your BMC Portal session.


Starting and stopping the BMC Portal on Windows

Starting and stopping the BMC Portal on Windows

You can start and stop the BMC Portal by using either of the following methods:

■ using the Services window■ using the net start and net stop commands

To start or stop the BMC Portal from the Services window

1 Open the Services window.

2 From the scroll list, select BMC Portal.

3 To start the service, click Start Service.

4 To stop the service, click Stop Service.

To start or stop the BMC Portal from the command line

From a command prompt, use the following methods to start and stop the BMC Portal:

■ To start the BMC Portal, enter the following command:

net start “BMC Portal”

■ To stop the BMC Portal, enter the following command:

net stop “BMC Portal”

Starting and stopping the BMC Portal on UNIX

The BMC Portal starts and stops as a daemon on UNIX platforms.

To start or stop the BMC Portal daemon on UNIX

To start or stop the BMC Portal on Solaris, use the BMCPortalAppserver script in the /etc/init.d directory and enter one of the following commands:

■ ./BMCPortalAppserver stop

■ ./BMCPortalAppserver start


Configuration tasks for BMC Impact Portal

Configuration tasks for BMC Impact PortalThis section contains some of the tasks you perform to configure the BMC Impact Portal.

Registering production and test cells in the BMC Impact Portal

Production and test cells must be registered in BMC Impact Portal so BMC Impact Explorer users can access the data defined to cells. Administrators can register a cell by using the BMC Impact Portal Register Impact Managers tab. For information on registering a cell in BMC Impact Portal, see the online Help or the BMC Portal Getting Started.

Customizing BMC Impact Portal configuration

You customize a BMC Impact Portal by editing the configuration parameters found in the ixs.properties file located in the jboss/server/all/conf/properties/ smsConsoleServer directory. These configuration parameters can affect several services.

If you make changes to the ixs.properties file, you will need to stop and start the BMC Impact Portal.

For more information about the ixs.properties file and its configuration, see “ixs.properties file and parameters” on page 141.

Configuring Dashboard Table View columns

You can change the columns displayed in dashboard table views by editing the ..\smsIwc\application.properties file.

To configure Dashboard Table View columns

1 Open the application.properties file in a text editor. This file is located at installationDirectory\tools\jboss\server\all\conf\properties\smsIwc\.

2 Edit the file to add or remove columns using the following format:

table_name=comma separated attribute (slot) names


Configuring Events Table columns

3 Save the application.properties file.

4 Restart the BMC Portal service.

Configuring Events Table columns

You can edit the columns that appear in the table in the Events tab by editing the ..\smsIwc\application.properties file. All columns in the events table are configurable.

To configure Events Table columns


2 Edit the appropriate events table column as shown in Table 25 on page 129.



WARNING To preserve the .properties suffix, save as type All Files. Do not save the application.properties file as a .txt file. The configuration changes may not be recognized.

Table 25 Event Table column default values

Column heading Description

status event status of the selected component

mc_priority value of the possible priorities of the event (values 5, 4, 3, 2, or 1)

severity value of the possible severities of the event (unknown, ok, info, warning, minor, major, or critical)

date_reception date and time the event was received

owner_name name of the owner of the component

msg relevant information related to the event

mc_smc_id the identifier for this service model component

WARNING To preserve the .properties suffix, save as type All Files. Do not save the application.properties file as a .txt file. The configuration changes may not be recognized.


Changing the Console Navigation Tree icons

For more information on this file, see “smsIwc/application.properties file and parameters” on page 137.

Changing the Console Navigation Tree icons

You can change the default icons displayed in the navigation tree for Recent Items by editing the ..\smsIwc\application.properties file.

To Change the Navigation Tree Icons


2 To change the navigation tree icons, add the relative path to the new icon to com.bmc.sms.iwc.domain.recentitem.RecentItemsFolderIcon.



For more information on this file, see “smsIwc/application.properties file and parameters” on page 137

Configuring Status Table columns

You can edit some of the columns in the tables in the Status tab by editing the ..\smsIwc\application.properties file. However, not all columns are configurable. The first three columns (status, type, and name) cannot be changed. A smaller version of each primary status table is displayed in the dashboard view, if the Status window is selected for one or more of the dashboard panes. By default, no columns beside the status, type, and name are configured for these smaller tables, but columns can be added in the application.properties file.

WARNING To preserve the .properties suffix, save as type “All Files.” Do not save the application.properties file as a .txt file. The configuration changes may not be recognized.


Configuring object link synchronization

To configure Status Table columns


2 Edit the appropriate status table column as shown in Table 26.



For more information, see “smsIwc/application.properties file and parameters” on page 137.

Configuring object link synchronization

You can change the objectlinksync values by editing the ..\smsIwc\application.properties file.

Table 26 Status table column default values

Table Configuration file listing Default columns

Providers com.bmc.sms.iwc.status.table.providers last_status_modificationdescriptionowner_nameowner_contact

Providers(dashboard view)

com.bmc.sms.iwc.status.table.providers. small none

Consumers com.bmc.sms.iwc.status.table.consumers last_status_modificationdescriptionowner_nameowner_contact

Consumers(dashboard view)

com.bmc.sms.iwc.status.table.consumers. small none

Causes com.bmc.sms.iwc.status.table.causes last_status_modificationdescriptionowner_nameowner_contact



Configuring reports

To configure object link synchronization


2 To change the object link type, modify the com.bmc.sms.iwc.objectlinksync.types entry.

3 To change the reconciliation link type, modify the com.bmc.sms.iwc.reconciliation.type entry.




Configuring reports

You can configure the following items for reports by editing the ..\smsConsoleServer\application.properties file:

■ scheduling■ value of report goal lines■ length of time report data is retained■ length of time event data is retained

To configure reports

1 Open the application.properties file in a text editor. This file is located at installationDirectory\tools\jboss\server\all\conf\properties\smsConsoleServer\.

2 Edit the appropriate status table column as shown in Table 27 on page 133.



Configuring reports


Table 27 Report parameters

Parameter type Parameter Description

Report Schedule com.bmc.sms.reportSummarizer.scheduler.frequencyHours

The frequency, in hours, that the report information is summarized. Default value is 1.

com.bmc.sms.reportSummarizer.scheduler.delaySeconds

The number of seconds that will be added to the starting hour for every scheduled summarization time. Default value is 30.

com.bmc.sms.reportSummarizer.scheduler.isStartingNextHour

Determines whether or not the setting of startingHour will be ignored. If set to true, startingHour will be ignored. Default value is true.

com.bmc.sms.reportSummarizer.scheduler.startingHour

Determines the desired starting hour. No summarization is made until this value is reached. If the startingHour has passed on that day, the summarization will start at that hour the next day. Default value is 0.

Report Goals com.bmc.sms.reportSummarizer.goal.default.SMS_CS_RT_AVAIL

Availability report goal line, expressed as a percentage. Default value is 90.0%.

com.bmc.sms.reportSummarizer.goal.default.SMS_CS_RT_MTTR

Mean Time to Repair goal line, expressed in milliseconds. Default value is 300000 (5 minutes).

com.bmc.sms.reportSummarizer.goal.default.SMS_CS_RT_MTBF

Mean Time Between Service Failures goal line, expressed in milliseconds. Default value is 172800000 (2 days).

com.bmc.sms.reportSummarizer.goal.default.SMS_CS_RT_MTBSI

Mean Time Between Service Incidents goal line, expressed in milliseconds. Default value is 172800000 (2 days).

Retention Age com.bmc.sms.consoleserver.retention.policy.age.SMS_CS_STATUS_EVENT

The number of days Status tab data will be retained. Default value is 395.

com.bmc.sms.consoleserver.retention.policy.age.SMS_CS_RT_AVAIL

The number of days Availability data will be retained. Default value is 395.

com.bmc.sms.consoleserver.retention.policy.age.SMS_CS_RT_MTTR

The number of days Availability data will be retained. Default value is 395.

com.bmc.sms.consoleserver.retention.policy.age.SMS_CS_RT_MTBF

The number of days Mean Time Between Failure data will be retained. Default value is 395.

com.bmc.sms.consoleserver.retention.policy.age.SMS_CS_RT_MTBSI

The number of days Mean Time Between Service Incidents data will be retained. Default value is 395.

com.bmc.sms.consoleserver.retention.policy.age.EG_EVENT

The number of days event data will be retained in the BMC Datastore. Default value is 395.


Configuring the number of events displayed



Configuring the number of events displayed

You can set the maximum and minimum number of events displayed in the Events tab by editing the ..\smsIwc\application.properties file.

To configure the number of events displayed


2 To change the minimum number of events shown on the Events table, edit the value for com.bmc.sms.iwc.event.table.minimumevents. The default value is 5.

3 To change the maximum number of events shown on the Events table, edit the value for com.bmc.sms.iwc.event.table.maximumevents. The default value is 50.




Changing the maximum number of recent items displayed

You can change the maximum number of objects displayed in the Recent Items group in the navigation tree by editing the ..\smsIwc\application.properties file.




Configuring the general properties displayed

To change the maximum number of recent items displayed


2 To change the maximum number of recent items displayed in the navigation tree, edit the value for com.bmc.sms.iwc.ui.recentitems.maxsize.




Configuring the general properties displayed

You can change the general properties in the Configuration tab by editing the ..\smsIwc\application.properties file.

To configure the general properties displayed


2 Add or remove property types associated with com.bmc.sms.iwc.component.properties.generalProperties.properties.







Setting up Image Views

Setting up Image Views

Image Views provide an alternative method for displaying components contained in a service model. Using a background image, you can organize the service model components to represent an area of your environment. For example, you can create an Image View that illustrates the geographic locations of a service model on a map.

The background images used for Image Views are located in the following directory:

BMC_PORTAL_KIT_HOME\appserver\websdk\tools\jboss\server\all\data\smsConsoleServer\Image\Background

To add a background image, place a copy of the graphic file in this directory. You can use the following types of graphic files for background images:

■ GIF■ JPEG■ PNG

Use the Configure tab in the BMC Impact Portal to create, edit, and delete Image Views. For more information on setting up image views, see the BMC Impact Portal online Help.

Modifying connection settings

You can modify the settings that BMC Impact Portal server uses when connecting to BMC Impact Manager instances.

To modify BMC Impact Portal connection settings

1 In a text editor, open the %BMC_PORTAL_KIT_HOME%\appserver\websdk\tools\jboss\server\all\conf\properties\smsConsoleServer\application.properties file.

2 Search for the Cell connection configuration stanza, and review the connection properties. The following figure depicts the default values for the connection properties.

CellName.timeout = 30CellName.reconnect_attempts = 5CellName.reconnect_frequency = 30CellName.polling_frequence = 3600CellName.encryption = on


Configuration file and parameter definitions for BMC Impact Portal

3 Modify the connection properties.


5 Restart the BMC Portal service (or daemon) to initialize the file.

The BMC Impact Portal settings are reset.

Configuration file and parameter definitions for BMC Impact Portal

Normally, you make changes to BMC Impact Portal component configurations through the user interface. However, you can manually edit three sets of configuration files that contain configuration information for the BMC Impact Portal module. These files pertain to these components:

■ BMC Impact Portal■ BMC Impact Service Model Editor■ BMC Impact Publishing Server

smsIwc/application.properties file and parameters

Table 28 describes the application.properties file in the smsIwc folder and its parameters.

Table 28 application.properties file

Filename application.properties in the ..smsIwc folder

File path BMC_PORTAL_KIT_HOME/appserver/webskd/tools/jboss/server/all/conf/properties/smsIwc

Descriptioncontains the general BMC Impact Portal configurations for component properties and user interface presentation

Parameter name Description Default value

com.bmc.sms.iwc.ui.recentitems.maxsize

sets the maximum number of objects that can display in the Recent Items group folder in the navigation tree of the BMC Impact Portal

Refer to “Changing the maximum number of recent items displayed” on page 134 for more information.

5


smsConsoleServer/application.properties file and parameters


Table 29 describes the application.properties file in the smsConsoleServer folder and its parameters.

com.bmc.sms.iwc.status.table

sets the columns that will display in the status and dashboard table views

Refer to “Configuring Dashboard Table View columns” on page 128 for more information.

See the application.properties file.

com.bmc.sms.iwc.component.properties.generalProperties.properties

determines which general properties are displayed in the Configure tab for selected components

Refer to “Configuring the general properties displayed” on page 135 for more information.

See the application.properties file for more information.

com.bmc.sms.iwc.event.table determines which columns in the events table are visible in the BMC Impact Portal module

Refer to “Configuring Events Table columns” on page 129 for more information.


com.bmc.sms.iwc.domain.notification.impact.type

sets the impact definitions included in a component notification e-mail

You can designate multiple types of impact definitions, separating each by a comma. If no impact type is set explicitly, the default is BMC_BaseElement.

BMC_BaseElement

com.bmc.sms.iwc.domain.recentitem.RecentItemsFolderIcon

specifies the default icon for the Recent Items folder ServiceComponent.gif

com.bmc.sms.iwc.status.table.providerscom.bmc.sms.iwc.status.table.consumerscom.bmc.sms.iwc.status.table.causescom.bmc.sms.iwc.status.table.existinggroupcom.bmc.sms.iwc.status.table.causal.componentscom.bmc.sms.iwc.status.table.components.small

determines which columns that you can add to the tables and dashboards under the Status tab in the BMC Impact Portal module

Refer to “Configuring Status Table columns” on page 130 for more information.


com.bmc.sms.iwc.event.table.minimumeventscom.bmc.sms.iwc.event.table.maximumevents

sets the maximum and minimum number of events retrieved per component instance; this information is displayed on the Events tab

minimum: 5maximum: 50





Filename application.properties in the ..smsConsoleServer folder

File pathBMC_PORTAL_KIT_HOME/appserver/webskd/tools/jboss/server/all/conf/properties/smsConsoleServer

Description contains the configurations for report scheduling, report goals, and report data retention


com.bmc.sms.configService.dataLocation

defines where the user configuration data is stored no value; the location BOSS_HOME/server/all/data/smsConsoleServer is used

com.bmc.sms.configService.keepBackupFile

if configuration data is changed, defines whether a backup file is saved

false; no backup file is saved

com.bmc.sms.reportSummarizer.goal.default.SMS_CS_RT_AVAIL

sets the value of the goal line for the Availability report as a percentage

90.000%

com.bmc.sms.reportSummarizer.goal.default.SMS_CS_RT_MTTR

sets the value of the goal line for the Mean Time to Repair (MTTR) report

300000 milliseconds (5 minutes)

com.bmc.sms.reportSummarizer.goal.default.SMS_CS_RT_MTBF

sets the value of the goal line for the Mean Time Before Failure (MTBF) report

172800000 milliseconds(2 days)

com.bmc.sms.reportSummarizer.goal.default.SMS_CS_RT_MTBSI=172800000

sets the value of the goal line for the Mean Time Before Service Impact (MTBSI) report. Goal line value is expressed in milliseconds.

172800000 milliseconds(2 days)

cellName.timeout sets the timeout value for data queries by the BMC Impact Portal to the specified cell

The timeout value is measured in seconds.

30 seconds

cellName.reconnect_attempts sets the number of times for the BMC Impact Portal to try to reconnect to the specified cell when it is unavailable cell (such as the cell or host is down)

60 tries

cellName.reconnect_frequency sets the polling cycle, measured in seconds, for the BMC Impact Portal reconnection attempt to the specified cell

30 seconds

cellName.polling_frequency sets the polling cycle, measured in seconds, for the BMC Impact Portal data query attempt to the specified cell

1800 seconds

<cellname>.encryption sets whether is encryption is enabled (off or on) for the connection with the specified cell

on

com.bmc.sms.icon.webdir defines the path in which the icon images for service model components are maintained

/smsConsoleServer/images/objects/

com.bmc.sms.event.maxDelayedHours

defines the maximum number of hours an event can be delayed and will still be processed.

24 hours



Table 30 describes the aggregator.properties file and its parameters.

com.bmc.sms.consoleserver.retention.policy.age.SMS_CS_STATUS_EVENT

com.bmc.sms.consoleserver.retention.policy.age.SMS_CS_RT_AVAIL

com.bmc.sms.consoleserver.retention.policy.age.SMS_CS_RT_MTTR

com.bmc.sms.consoleserver.retention.policy.age.SMS_CS_RT_MTBF

com.bmc.sms.consoleserver.retention.policy.age.SMS_CS_RT_MTBSI

com.bmc.sms.consoleserver.retention.policy.age.EG_EVENT

sets the length of time, in days, that report data is retained for each report and that event data is retained in the BMC Datastore.

395 days

com.bmc.sms.service.os.unrestricted

sets whether the Object Store communication service should run in unrestricted mode when connecting to the Remedy server

true

com.bmc.sms.service.os.restrict.read.access

sets whether the Object Store communication service filters are read-only objects

true

com.bmc.sms.service.os.filtersim

sets whether the Object Store communication service filters classes and attributes that are marked SIM=false

true

com.bmc.sms.remedy.serverHostName

identifies the host computer on which the BMC Portal host resides

BMC Portal host computer name

com.bmc.sms.remedy.serverPortNumber

lists the port number by which the BMC Portal connects to the Remedy server

0

Table 30 aggregator.properties file

Filename aggregator.properties


Descriptioncontains the configurations for BMC Impact Portal communications with cells, including port number used for cell communications, encryption key, and encryption enablement


com.bmc.sms.eventaggregator.jserverPortNumber

sets the port number through which the BMC Impact Portal communicates with the BMC IM cell

3783



ixs.properties file and parameters


Table 31 describes the ixs.properties file and its parameters.

com.bmc.sms.eventaggregator.jserverEncryptionKey

sets the encryption key used to communicate with the BMC IM cell

mc

com.bmc.sms.eventaggregator.jserverEncryptionEnabled

communication encryption indicator (true or false) true

Table 31 ixs.properties file

Filename ixs.properties


Description

contains the configurations for BMC Impact Portal communications with the BMC Impact Explorer console, including the port number used for BMC Impact Explorer communications and parameters for building an IP address in a multi-homed environment.


com.bmc.sms.ixs.port.number sets the port number through which the BMC Impact Portal communicates with the BMC Impact Explorer console

3084

com.bmc.sms.ixs.enable.bind.ip sets whether the BMC Impact Portal can bind an IP address on a multi-homed (multi NIC card) system

false

com.bmc.sms.ixs.bind.ip.address specifies the IP address on a multi-homed system to which the BMC Impact Portal is bound

0.0.0.0

Table 30 aggregator.properties file


C h a p t e r 5
5 Managing the BMC Impact Explorer (BMC IX) console
This chapter describes how to configure BMC Impact Explorer (BMC IX) console and contains the following topics:

Connecting BMC IX to a BMC Impact Portal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Specific configuration tasks in BMC IX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Defining a user’s home directory on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Defining property files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Defining console-wide policy files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Configuring display and connection settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Defining global event severity and priority color values . . . . . . . . . . . . . . . . . . . 151Event group configuration files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152XML files that define user interface elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153


Connecting BMC IX to a BMC Impact Portal

Connecting BMC IX to a BMC Impact PortalIf you have multiple BMC Impact Portals in your environment, you can set up BMC IX to connect to each of them.

The following procedure describes how to add one or more BMC Impact Portals to the BMC IX console configuration. You can then select the BMC Impact Portal that you want to connect to from the Logon dialog box when you start the console. This task applies to BMC IX as a stand-alone console or as a Java Web Start application.

To connect to a BMC Impact Portal and make cells available to BMC IX

1 Start the BMC Impact Explorer.

2 Define the name and port of each BMC Impact Portal to which you want BMC IX to connect by following these steps:

A Choose Edit => Configuration.

The Edit Configuration dialog box appears.

B Click the Impact Portals tab.

C In the Host box, enter the name of the computer hosting the BMC Impact Portal.

D In the Port box, enter the port number for the BMC Impact Portal.

E Click Add to include the BMC Impact Portal in the list of servers to which you want connect.

F Repeat steps 2C through 2E for each BMC Impact Portal to which you want to connect.

3 Connect to the BMC Impact Explorer as a user.

4 Identify the cells to make available to BMC Impact Explorer by following these steps:

A From BMC Impact Explorer, choose Edit => Configuration.

B In the Edit Configuration dialog box, click the Impact Managers tab.

NOTE Each portal uses a different BMC Atrium Configuration Management Database (CMDB), so if you connect to a different portal, you will be accessing a different service model and all its related data. Using a different BMC Impact Portal as a backup requires that the administrator replicate the entire environment and maintain it as a backup.


Specific configuration tasks in BMC IX

The Available Cells list box lists all cells associated with the BMC Impact Portal to which you are connected.

C Select a cell from the Available Impact Managers list, and select a group (the defaults are MyTest or MyProduction).

D Click the arrow to move the cell.

E Click OK. The cell you added appears in the navigation pane of the console.

For complete information about configuring BMC IX, see the BMC Impact Solutions: Event Monitoring user guide.

Specific configuration tasks in BMC IXThis section describes specific configuration tasks for BMC IX.

Defining a user’s home directory on Windows

The first time a user opens the BMC Impact Explorer console interface, a preferences file called mccs.prop is created and stored in the user’s home directory (represented here as %HOME%):

%HOME%\.econsole\etc\mccscommunication\mccs.prop

On computers running Windows, ensure the path to the user’s home directory is in the user’s profile. You can create a user’s home directory anywhere and it can have any name, as shown in the following example.

NOTE You can select multiple cells at one time. To select adjacent cells, select the first cell, hold down the Shift key, and select the last cell. To select nonadjacent cells, select a cell, hold down the Ctrl key, and select each of the other cells.

TIP You can also click and drag a cell from the Available Cells list box to the Selected Cells list box.


Defining property files

Steps for defining a user’s home directory differ for each Windows version. For instructions, consult the documentation for your version.

Defining property files

The BMC Impact Portal creates a unique properties file username.econ.config in the jboss\server\all\data\smsConsoleServer\econsole directory of the BMC Impact Portal. This file is based on the default.econ.config properties file that is created at installation.

Figure 12 illustrates the username.econ.config file.

Figure 13 illustrates a file Operator.econ.config created for a user named Operator.

EXAMPLE C:\usernameC:\Documents and Settings\username

WARNING If multiple users are working on a single Windows computer and a separate home directory for each user is not defined, each subsequent user overwrites the previous user’s profile.

Figure 12 default.econ.config file contents

#Mon Jan 20 17:51:13 CDT 2003toolbar_orientation=0toolbar_layout=Northframework_bounds=444,256,512,384user.region=US

Figure 13 Operator.econ.config file contents

#Wed Feb 05 11:52:22 CST 2003user.region=UStoolbar_orientation=0config_dialog_position_y=191config_dialog_height=520toolbar_layout=Northconfig_dialog_position_x=288config_dialog_width=394framework_bounds=229,259,512,384


Defining console-wide policy files


Another aspect of control vested in the BMC Impact Portal is the policy file that BMC Impact Explorer retrieves each time a user connects to the BMC Impact Portal. This file contains parameters that define BMC Impact Explorer console-wide policies for all users. At installation, the default policy file, default.console_policy.prop, is created; it is located in the jboss\server\all\data\smsConsoleServer\policy directory.

The policy file is never saved from the BMC Impact Explorer console, only retrieved. If a specific user has a particular need, it is possible to create an individual user policy file, username.console_policy.prop, based on the default and located in the same jboss\server\all\data\smsConsoleServer\policy directory. This individual user policy file will be returned to the BMC Impact Explorer console, rather than the default file, default.console_policy.prop, when the user logs on. For ease of maintenance, BMC Software recommends that the default be used for most users.

Table 32 summarizes the parameters in the default policy file.

Table 32 default.console_policy.prop parameters (part 1 of 2)


local_action_event_operations controls the tracking of local actions performed against events

default_filter_name specifies the default filter used to display the event list when no view is selected

default_slotorder_name specifies the default slot order used for the event list when no view is selected

eventlist_icon_slots controls the slots shown as icons in the event list (values of hidden slots can be viewed only as icons)

filter_hidden_slots controls the hidden slots that are available for creating filters

Note: Filters that rely on hidden slots may be broken in future releases because they rely on undocumented contents.

administration_editor_classes controls the classes (with their subclasses) that are available to the Dynamic Data Editor

administration_editor_acls specifies the ACLs that control access to the Dynamic Data Editor

no_import_slots controls exclusion of slots when exporting

config.save.freq controls the time interval between saves of configuration information (such as window sizes and locations)

ix.servicetree.save.timer controls the time interval between saves of Services View navigation tree information

local_action_event_notes (deprecated)a controls creation of notes for events that have local actions performed against them; replaced with local_action_event_operations



Figure 14 lists its contents, including the default values for each parameter.

remote_action_event_notes (deprecated)a controls creation of notes for events that have remote actions performed against them

status_mod_event_note (deprecated)a controls creation of notes for events that change status by means of user-initiated action

a Deprecated parameters remain in version 4.1 and earlier cells. However, the parameters do not exist in newer releases.

Figure 14 Default policy file (part 1 of 2)

# This document keeps default Policies for different BMC Impact Explorer wide functions.# Format:# <policy_name>=<polcy specific value>

# Policy which controls the creation of an event operation track for events which# have local actions performed against them.# value: on=operation track created when local action performed, off=operation track not created.local_action_event_operations=on

# Policy which controls the creation of an event note for events which# have local actions performed against them.# deprecated: On im's 4.1 and further mc_notes is no longer used to track history, mc_operations is dedicated to this purpose.# replaced with local_action_event_operations# value: on=note created when local action performed, off=note not created.local_action_event_notes=on

# Policy which controls the creation of an event note for events which# have remote actions performed against them.# deprecated: On im's 4.1 and further mc_notes is no longer used to track history, mc_operations is dedicated to this purpose.# The registering of history in mc_operations is configured at the im.# value: on=note created when remote action performed, off=note not created.remote_action_event_notes=on

# Policy which controls the creation of an event note for events which# change status via user initiated action (e.g.: OPEN -> CLOSED).# deprecated: On im's 4.1 and further mc_notes is no longer used to track history, mc_operations is dedicated to this purpose.# The registering of history in mc_operations is configured at the im.# value: on=note created when event status changes, off=note not created.status_mod_event_note=on

# default filter and slot order when no view is ever selected.# value: the name of a defined filter and slotorder.default_filter_name=All Eventsdefault_slotorder_name=Basic Information

# controls if ClassDetailProvider detail tabs show hidden slots#ClassDetailProvider_shows_hidden_slots=false

Table 32 default.console_policy.prop parameters (part 2 of 2)




# Policy which controls the slots shown as icons in the event lists.# Values of hidden slots can only be viewed as icons.# value: <className> "." <slotName> { "," <className> "." <slotName> }# default value: CORE_EVENT.mc_abstracted, CORE_EVENT.mc_abstraction, CORE_EVENT.mc_action_count, CORE_EVENT.mc_cause, CORE_EVENT.mc_effects, CORE_EVENT.mc_history, CORE_EVENT.mc_notes, CORE_EVENT.mc_smc_cause, CORE_EVENT.mc_smc_effects, CORE_EVENT.mc_smc_impact#eventlist_icon_slots=CORE_EVENT.mc_abstracted, CORE_EVENT.mc_abstraction, CORE_EVENT.mc_action_count, CORE_EVENT.mc_cause, CORE_EVENT.mc_effects, CORE_EVENT.mc_history, CORE_EVENT.mc_notes, CORE_EVENT.mc_smc_cause, CORE_EVENT.mc_smc_effects, CORE_EVENT.mc_smc_impact

# Policy which controls the hidden slots that will be available for filter building.# Impartant remark: Filters that rely on hidden slots may be broken in future release without notice, because they rely on undocumented contents.# value: <className> "." <slotName> { "," <className> "." <slotName> }# default value: <empty list>#filter_hidden_slots=

# Policy which controls what classes (with their subclasses) are visible in Administration's editor# value: <className> { "," <className> }# default value: DATA#administration_editor_classes=DATA

#Policy which controls what acls control the classes (with their subclasses) in Administration's editor# value: <aclName> { "," <aclName> }# default value: MC_DATA_EDITOR#administration_editor_acls=MC_DATA_EDITOR

# Slots that, though parsable, should be excluded from import (thus paste and export for import), because of specific semantics# value: <className> "." <slotName> { "," <className> "." <slotName> }no_import_slots=CORE_DATA.mc_udid, MC_SM_OBJECT.creation_mode, MC_SM_COMPONENT.ext_id, MC_SM_COMPONENT.home_cell, MC_SM_RELATIONSHIP.provider_id, MC_SM_RELATIONSHIP.consumer_id

# Configuration information (such as window sizes and locations) will be saved on a periodic basis.# Policy which controls the time window (in seconds) for this operation.# default value: 5 minutes (300 seconds).config.save.freq=300

# Service Views navigation tree information stored as XML will be saved to the IXS on a periodic basis.# Policy which controls the time window (in seconds) for this operation.# default value: 5 seconds (5000 milliseconds).# Based on section 4.1.1.2.1 in Impact Explorer 4.1 Functional Specificationix.servicetree.save.timer=5

Figure 14 Default policy file (part 2 of 2)


Configuring display and connection settings

When you execute a local action, a remote action, or modify the status of an event, a note is written to the event as a value to the mc_notes slot and appears in the Notes tab of the details pane of BMC Impact Explorer Events View. The initial filter is set to display all events and the initial slot order is to display as basic information, as indicated on the event source tab in the event list display. The last entry in the policy file identifies those slots that should not be imported because of their specific semantics.

The policy file’s console-wide application can be used to protect the individual user’s cell groupings from being accessed and modified by other users on a multi-user BMC Impact Explorer console. This enables a business to assign multiple users with limited use requirements to one BMC Impact Explorer console, fully utilizing one resource, rather than investing in several BMC Impact Explorer consoles that will be under utilized.

Another beneficial aspect of the global nature of the policy file is that you can use it to create a customized default event filter and slot order for a BMC Impact Explorer console for new users and as the default filter and slot order when a user selects an improper filter.

Configuring display and connection settings

You can use the ix.properties file to configure the display and connection settings for BMC IX. Table 33 lists the property settings included in the ix.properties file.

Table 33 Property descriptions from ix.properties file (part 1 of 2)

Console property Description

framework_debug when set to true, enables debugging for the console

help_url sets the directory location and URL address for the BMC Impact Explorer Help file

java_plaf specifies the look and feel for BMC Impact Explorer according to the Java GUI settings

macro_connect_timeout sets the amount of time, in seconds, a macro waits to connect to a cell

remote_server_port sets the port number used by the Remote Method Invocation (RMI) service in BMC Impact Explorer

remote_server_enabled enables the RMI service for BMC Impact Explorer for remote access to event data

all_connection_allowed enables any connection to the RMI service for a BMC Impact Explorer

If set to false, the RMI service can only accept connections from the local computer where the console is running.


Defining global event severity and priority color values

Defining global event severity and priority color values

Event records are displayed in the BMC Impact Explorer Events View using colors that represent their level of severity and priority. The color.properties file, located in the JBOSS/server/all/conf/properties/smsConsoleServer directory, defines severity and priority value colors for the events and contains the default color values. The color.properties file also can contain custom definitions for the status conditions of BMC Service Impact Manager components.

Modify this file if you want to define custom colors for event severities and priorities. To avoid confusion, each user receives the same colors for events that the BMC Impact Explorer console interface displays.

Table 34 lists the default severity level colors and their values, as defined in color.properties.

mc_console_remote_object_name specifies the name of the remote object used by the RMI client

This value must be matched in the -Dremote_object_name option in the run_client.bat or run_client.sh scripts.

user.region specifies the region used for the console to provide II8N support

By default, this information is retrieved from the environment setup of the computer.

collector_tree_color specifies the background color for the navigation tab on the Events tab of the console

max_msg_history sets the maximum number of status bar history messages that are stored in the console

new_groups_name specifies the default name assigned to newly created subgroups on the Services tab on the console

svc_view_tooltip length of time, in milliseconds, the console waits to display tooltips in the Services View

svc_view_link_thickness_normal sets the width for line indicators that connect service model components in the relationships pane of the console

svc_view_link_thickness_true_impact sets the width of the line indicators that indicate impact relationships between service model components in the relationships pane of the console

Table 34 Event severity levels and colors (part 1 of 2)

Severity level Color Hexadecimal RGB values in color.properties

Down Black 000000,FFFFFF

Critical Red FF0000,FFFFFF

Table 33 Property descriptions from ix.properties file (part 2 of 2)

Console property Description


Event group configuration files

Table 35 lists the default priority level colors and their values, as defined in color.properties.

To globally change the default severity or priority colors, modify the color.properties file and stop and start the BMC Impact Portal.


The event group configuration file structure is listed in Table 36:

Major orange FF9900,000000

Minor light orange FFCC33,000000

Warning yellow FFFF00,000000

Information blue 3366CC,FFFFFF

OK green 33CC00,000000

Unknown gray CCCCCC,000000

WARNING ■ The entries are the default color properties. Do not delete these properties.

■ If you customize the severities by increasing the number of levels to be greater than the number of default severity levels, the severity list on the Event and Services Views becomes truncated and partially illegible. Restrict your customizations to the same number or fewer severity levels.

Table 35 Event priority levels and colors

Priority level Color Hexadecimal RGB values in color.properties

Priority_1 red FF0000,FFFFFF

Priority_2 orange FF9900,FFFFFF

Priority_3 light orange FFCC33,000000

Priority_4 yellow FFFF00,000000

Priority_5 green 33CC00,000000

NOTE Modifications made to the color.properties file do not immediately appear in the BMC Impact Portal. By default, the BMC Impact Portal configuration.update.interval parameter checks for changes every 300 seconds.

Table 34 Event severity levels and colors (part 2 of 2)

Severity level Color Hexadecimal RGB values in color.properties


XML files that define user interface elements


Table 37 lists XML files that control some user interface characteristics in BMC Impact Explorer that cannot be edited in the BMC IX user interface.

Use care when you edit these files to avoid unexpected and undesirable results.

These files are located in

■ Windows: %BMC_PORTAL_KIT_HOME% \appserver\websdk\tools\jboss\server\all\data\smsConsoleServer\extdetails

■ UNIX: $BMC_PORTAL_KIT_HOME /appserver/websdk/tools/jboss/server/all/data/smsConsoleServer/extdetails

Table 36 Event group configuration files

Folder Contains

\Images Backgrounds and Icons directories

\Images\Backgrounds background image files that are shared by all Map definitions

\Images\Icons image files which are shared by all Map definitions

\Map event group tree node template MapObjectTemplate.xml

\Map event group default image view configuration DefaultMapPage.xsl

\Map Map tree definition Maps.xml

\Map\Map_xxx Map.xml for Map_xxx as well as its MapPages directory

\Map\Map_xxx\MapPages all map page definitions for Map Map_xxx

Table 37 xml files that define user interface elements in BMC IX

File name Description

default.DataEditor.extdetails.xml defines the default tabs if the global.DataEditor.extdetails.xml file is not present or does not contain values

global.DataEditor.extdetails.xml defines the tabs that appear in the data editor

global.extdetails.xml defines the tabs that appear for events and components

global.PolicyEditor.extdetails.xml defines the policy type to policy editor mapping

global.SmcToolTips.extdetails.xml defines the tooltips that appear on a component instance


C h a p t e r 6
6 Working with Infrastructure Management

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Default Infrastructure Management service model . . . . . . . . . . . . . . . . . . . . . . . . 156Roles and permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Walkthrough. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Displaying the out-of-the-box real-time service model . . . . . . . . . . . . . . . . . . . . . 158Sampling context-sensitive information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160Managing files on remote systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161Packaging support files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162Launching remote actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Common Infrastructure Management tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Navigating the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Displaying and understanding the Details and Administer tab data . . . . . . . . . 169Editing infrastructure relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173Creating logical components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Deleting components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Executing remote actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Executing other actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179Configuring the audit log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179Creating the support package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Background to Infrastructure Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185Impact Administration cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185Impact Administration server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186Unidirectional event flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186Remote actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187


Overview

Overview Infrastructure Management makes it easier for administrators with a Full Access or Service Administrator role to monitor and manage BMC SIEM infrastructure components in a real-time service model. These infrastructure components include Impact Manager cells, servers, and integrations. In the Infrastructure Management GUI, you not only can monitor the different states of the components based on their color codes, but you also can perform actions on them, such as

■ stop, start, and other operations■ edit configuration and log files■ package support files for troubleshooting purposes

Default Infrastructure Management service model

The default Infrastructure Management model consists of logical groupings of BMC infrastructure applications and components. Upon installation certain components send registration events and become automatically registered with the Infrastructure Management model.

Figure 15 Default Infrastructure Management service model

In the color scheme, green indicates that the object has registered with the Impact Administration cell. Grey indicates that the object is a logical grouping, the components of which are not registered with the Impact Administration cell. The bold lines that connect the components represent the active impact relationships. The arrows indicate the direction (provider to consumer) of the event feed. A dotted line indicates that the relationship is inactive.

156 BMC Impact Solutions:General Administration

Roles and permissions

In this current 7.1 release, the following version 7.1 BMC components register with this service model. They can be added as components instances to the respective logical group.

Roles and permissions

The following group roles have full write permission to the components and features of the Infrastructure Management subtab:

■ Service Administrators■ Full Access

Only members of either group can view the Infrastructure Management subtab.

Refer to “Defining group roles” on page 95 for information on assigning roles.

WalkthroughThis section provides a walkthrough of Infrastructure Management, highlighting its main features. You can use this walkthrough to learn about and become familiar with Infrastructure Management.

Table 38 Supported application groups in version 7.1

Group Id Name

100 EM_CELL

101 EM_SERVER_1

102 EM_SERVER_2

103 SIM_CELL

104 SIM_SERVER_1

105 SIM_SERVER_2

106 IAC (Impact Administration Cell)

111 IAS (Impact Administration Server)

112 PS (BMC Impact Publishing Server)

142 Integration for BMC Remedy Service Desk

160 EM_Server_Standby

161 SIM_Server_Standby


Displaying the out-of-the-box real-time service model


Infrastructure Management automatically deploys a BMC infrastructure service model, called BMC Impact Solutions. It consists of logical groupings of BMC services and applications, together with registered components that send all relevant information and latest statuses. The out-of-the-box service model reflects the real-time states of the registered components.

To display the service model

1 In BMC Impact Explorer, click the Administration tab.

2 In the icon bar at the top of the navigation area on the left, click the Infrastructure Management icon (the wrench or spanner icon).

3 Under Find Infrastructure Components in the bottom pane of the navigation area, choose Find to list the services and applications.

The logical groupings of components and applications are displayed, along with registered components.

Alternatively, you can open the BEM Infrastructure Management group to display the navigation tree, as shown in Figure 16 on page 159.



Figure 16 Infrastructure Management navigation pane

4 Locate the BMC Impact Solutions object in the Find list, and then, using the mouse, click and drag it into the graph viewing area in the top right pane to reveal the service model.

You can also choose to select BMC Impact Solutions in the navigation tree under BEM Infrastructure Management to display it in the graph viewing area.

You may need to click the Orientation icon at the top of the graph viewing area to reposition it vertically.

The default service model should look similar to the example in Figure 17 on page 160.


Sampling context-sensitive information

Figure 17 Default service model BMC Impact Solutions (with active services)

The services and applications are color-coded to reflect their real-time status. You can check the multi-colored Status legend to see the status associated with each color. (The grey-colored icons represent logical groupings.)

Sampling context-sensitive information

The Infrastructure Management GUI offers a range of context-sensitive information that you can access from right-click pop-up menus and multilayered notebook tabs.

For example, you can expand the model and select a component under the SIM Cells heading.

■ Click on the leaf component under SIM Cells to select it.

■ Click on the Details tab. Click on the subtabs such as General, Status, Related Components and Schedule. These tabs provide component specific information.


Managing files on remote systems

■ Click on the Administer tab. Click on the subtabs. Note that you can access the Workload and Components tabs. These tabs are not visible if you had selected an EM cell instead.

■ Click on Edit Component in the Details=>General tab and change a property of the component.

Managing files on remote systems

From the Infrastructure Management GUI, you can edit and save the configuration and log files of other SIEM applications and services, both of which are running on remote systems.

To edit and save configuration files

1 Click on the leaf component under a service or an application, such as SIM Cells, to select it.

2 From the notebook tabs, choose Administer=>Configuration.

The dropdown list reveals the configuration files of the selected component.

3 To modify a file, select it from the list, and click Edit. The Credentials dialog box displays.


Packaging support files

The Additional command credentials check box applies mainly to UNIX systems, where you may need to log into the system under one user account, but then switch to another user account (for example, root) to execute the action.

4 In the dialog box, enter the credentials of the remote system, and click OK.

The configuration file is displayed in the editor.

5 Edit the file.

6 When you’re done, you can click either of the following:

■ File=>Save a Copy to save a copy of the file to your local system■ File=>Update Original to update the file on the remote system

To edit and save log files

1 Click on the leaf component under a service or an application, such as SIM Cells, to select it.

2 From the notebook tabs, choose Administer=>Logs.

The dropdown list reveals the log files of the selected component.

3 To modify a file, select it from the list, and click Edit.

4 In the dialog box, enter the credentials of the remote system, and click OK.

The log file is displayed in the editor.

5 Edit the file.

6 When you’re done, click File=>Save a Copy to save a copy of the file to your local system.

You cannot update a log file on a remote system. You can save it only to the local system.


You can package selected debug files to help troubleshoot customer cases. Infrastructure Management automatically packages the selected files into a zipped file.



To package support files

1 Click on the leaf component under SIM Cells, for example, to select it.

2 From the notebook tabs, choose Administer=>Support Package.

3 In the Destination field, enter the file path where the package should be saved on the local system. You can use the Browse button to navigate to the directory.

The file name of the support package is created automatically.

4 Optional. Enter a tracking number in the Issue Number field.

5 Optional. Enter a description of the issue in the Description field.

6 Click Create Package.


Launching remote actions

7 Enter the credentials of the remote system from which you are retrieving the files.

A pop-up progress indicator shows the status of the retrieval. If it completes successfully, go to the specified directory and review the contents of the zipped package. The file contents vary based on the type of component. Here are typical files for a SIM server component.

8 Repeat steps 1 through 7 for an Impact Administration Server component, verifying that the file contents of its zipped package are different from those of the SIM Cell.


From the Infrastructure Management GUI, you can execute actions through the right-click pop-up menus on components and applications that are running on remote systems.



To launch remote actions

For this exercise, you must have a registered cell component installed on a remote system.

1 Right-click the leaf component under SIM Cells or EM Cells to select a cell residing on a remote system.

2 Choose Actions to display a list of all possible actions for that component.

3 Choose Stop Cell Server Process, and enter the logon credentials for the remote system.

If the selected component resides on an MS Windows system, your login credentials should have administrative rights to the system. The Additional Command Credentials are needed check box is disabled.

When the component on the remote system has stopped, its status changes to Unavailable.

4 Return to the Infrastructure Management GUI, right-click on the SIM Cells component to display the pop-up menu, and choose Actions=>Start Cell Server Process.

5 Verify that the cell has started—for example, you can execute an mcstat command to check the cell’s status. Then you can verify that the status of the selected component is changed to OK.

6 Repeat steps 1 through 5 for a BMC Impact Administration Server (IAS) component. The actions permitted on this component are different from those of the EM or SIM Cell component. They are limited to Stop Process and Start Process.

You can also launch remote actions for selected components by clicking one of the Action toolbar icons of the Infrastructure Management view.


Common Infrastructure Management tasks

Depending on the type and state of the selected component, you can choose from among the following actions:

■ Start Cell Server Process (Start)■ Stop Cell Server Process (Stop)■ Restart Cell Server Process (Restart)■ Set to Passive (Standby)■ Set to Active (Active)■ Pause Events Admittance (Pause)■ Resume Events Admittance (Resume)

Different actions are enabled based on the status and type of component. For example, if a component in an unknown state is already started and you choose Actions=>Start, you receive a status message notifying you that the component is started already. Refer to “Remote actions” on page 187 for more information.

Common Infrastructure Management tasksThis section describes the most common Infrastructure Management tasks. For the most part, you manipulate objects in the Infrastructure Management GUI just as you would in the other BMC Impact Explorer Services tab views.

Navigating the GUI

In the Administration tab view, select the Infrastructure Management subtab, represented by the wrench icon at the far right in the icon row atop the navigation pane:

In the Of type drop-down list, click All if it’s not already displayed.

Click Find to open the list of logical groupings and registered components in your infrastructure.

Logical groupings and registered components are depicted by different icons:


Navigating the GUI

Select the grouping BMC Impact Solutions, which contains the default infrastructure model, and drag-and-drop it on the graph viewing area. You may need to select the Orientation icon to display it along a vertical axis.

Table 39 Icon listing for infrastructure management model

Icon Definition

logical services grouping

IAS (Impact Administration Server)

SIM cell

SIM cell server 1

SIM cell server 2 (high availability implementation)

SIM cell server standby (high availability implementation)

EM Cell

EM cell server 1

EM cell server 2 (high availability implementation)

BEM cell server standby (high availability implementation)

BMC Publishing Server

Integration for BMC Remedy Service Desk


Navigating the GUI

Multiple graphs

You can display multiple graph views. For example, you can select registered components from the Results list in the navigation pane, and drag-and-drop them on the graph viewing area, creating new graph views. You can switch from one view to the other by selecting the tabs at the top of the graph viewing area.

Navigation tree

To help organize your model, you can display and manipulate the grouping and component hierarchy in the navigation tree view under the Infrastructure Management heading.

You can select objects in the navigation tree and display them in the graph viewing area.

You can drag objects from the graph viewing area and drop into the navigation tree, creating a navigation link between the two.

You can create customized subgroups under the Infrastructure Management heading. After selecting the heading, right-click to open the Add a sub group menu item.

After you define your group, you can drag and drop component objects into it.

TIP You can click both CTRL and the object in the navigation tree to display the object in the graph viewing area without closing any displayed objects.


Displaying and understanding the Details and Administer tab data


The Details subtabs display information that identifies the characteristics of the selected component and returns its status. They let you perform common BMC IX actions, such as changing provider\consumer relationships between components. The Administer subtabs display specific infrastructure information and let you perform unique infrastructure actions, such as editing configuration and log files and collecting debug files for troubleshooting.

To view data about an object in the GUI, first select it. Then you can scan the corresponding subtabs under Details and Administer. To view information on one of the Administer tabs, the selected object must be a registered infrastructure component, not a greyed-out logical services group icon.

Details tab data

General

In the General subtab, you can view the name, class, and subtype of the selected object. Depending on the subtype, you can also view other slot values, as described in Table 40.

Table 40 Slot values: Details: General subtab (part 1 of 2)

Slot Description

Editable Here contains a Boolean Yes/No indicator that says whether the selected component object can be edited in BMC IX.

Infrastructure Management only contains objects that are not published. Therefore, Editable Here is always set to Yes in Infrastructure Management.

Master Repository specifies the data source of the component object. For example, component objects that originate from a direct feed source, such as BMC IX, mposter, or an MRL, are designated in this format: Cell-cellName. The default name for Infrastructure Management is Cell_Admin.

Run State the current state of the object, which helps to determine its status, its icon shape, the icon’s color, as well as which actions can be performed against the object. This slot value is updated whenever the component changes its state, from start to stop, from start to paused, from stop to start, and so forth.

Role indicates whether a component, such as a cell server or IAS, is standalone or, in an HA pair, either primary or secondary



From the General subtab, you can click Edit Component to open the Edit Service Component dialog in which you can modify the component’s properties.

Status

In the Status subtab, you can view the applicable status levels of the component: Service Level Agreement, manual status, maintenance mode, and computation statuses.

Priority and Cost

Under the Priority and Cost subtab, you can view the schedule status, impact priority, and impact cost.

Other

In the Other subtab, you can view the following slot values:

Cell Type identifies a selected cell component as Service Impact Management, Event Management, Impact Administration, or Integration

Cell Server 1 for a selected cell component, the IP address of the standalone cell server or of the primary cell server in an HA pair

Cell Server 1 Port for a selected cell component, the port number of the standalone cell server or of the primary cell server in an HA pair

Cell Server 2 for a selected cell component, the IP address of the secondary cell server in an HA pair

Cell Server 2 Port for a selected cell component, the port number of the secondary cell server in an HA pair

Table 41 Slot values: Details: Other subtab (part 1 of 2)

Slot Description

Additional Support Files list of files that you can add to the default support package

Bin Directory the file path to the /bin directory of a component

Configuration Files configuration files (.conf files) for a component

Home Directory home directory of the component

Default Support Files editable list of support files associated with this component and contained in the support package

Filter Files default parameters for filtering in and out events that are sent and received. Used by integration components

Table 40 Slot values: Details: General subtab (part 2 of 2)

Slot Description



Related Components

In the Related Components subtab, you can retrieve status causes, possible problems, providers, and consumers of the selected component type. You can modify the relationship by selecting Edit Relationship..., which opens the Edit Relationships dialog where you can add, modify, or remove relationships. Using the right-click menu options, you can highlight a retrieved component in the list, and add a link to the navigation tree by choosing the Add Navigation Link option. You can view the events associated with the component.

This subtab also lets you view other components that have relationships with the selected component.

SLM

In the SLM subtab, you can list and view the details of Service Level Management agreements assigned to the component. This subtab view is not available for the Admin cell (IAC).

Map Files customized files for event enrichment. Used by integration components

Trace Conf File trace configuration file for the particular component, such as a cell server (mcell.conf), BMC Publishing Server (pserver.trace and pclient.trace), and for integrations (trace.conf)

Trace Files log files that record the activity of the component

Selector Files files that help to determine which events an integration component can send or receive

Dir File directory file of a component, such as the mcell.dir for a cell or the integrationName.dir for an integration component

KB Directory Knowledge Base directory of the cell

OS Class operating system of the machine where the component is installed

Build build number of the selected component’s software package

Release release number of the selected component’s software package

OS version version of the operating system on which the selected component resides

Table 41 Slot values: Details: Other subtab (part 2 of 2)

Slot Description



Schedules

In the Schedules subtab, you can view the times when the component is in service together with its priority costs when it is in service and when it is out of service. This subtab view is not available for the Admin cell (IAC).

Administer tab data

Configuration

The Configuration subtab lists the editable configuration files of the selected component. You can retrieve these files, even those associated with components on remote systems. Click Edit... . Then enter the logon credentials for the system where the component resides. (On UNIX, your login account must have permission to access the target system. On MS Windows, you must have administrative privileges on the system.) The file opens in a default text editor.

You can edit any supported configuration file of an infrastructure component. The type of file varies with the component, but the files include:

■ mcell.dir■ .conf files■ filter files■ selector files ■ mapping files■ trace.conf files■ cell_info.list

You should know the parameters of the file before trying to edit it. Refer to the component’s respective documentation.

You can save the edited configuration file to a local or remote system. If saving to a local system, you can specify a different file path. If saving to a remote system, you update the configuration file in its current directory path. You cannot save it to a different file path.

Logs

Similar to configuration files, you can open and annotate log files of components on local systems in the Log subtab. You cannot save an edited or update an viewed log file to a remote system, however. You must save it to the local system.


Editing infrastructure relationships

Support Package

In the Support Package subtab, you can prepare a zipped package of predefined support files for troubleshooting purposes. See “Creating the support package” on page 182 for more information.

Workload

The Workload subtab dynamically tracks the event activity of the cell server component. It presents counts, averages, and percentages of different event actions, such as sent, received, dropped, and removed. You can refresh the table by clicking the Refresh button. This subtab view is available for SIM cell servers, but not for BEM cell servers.

Components

The Components subtab dynamically tracks the component instances that are sending events to the selected object. You refresh the table by clicking the Refresh button. This subtab view is available for SIM cell servers, but not for BEM cell servers.


To open the Edit Relationships dialog box, select an infrastructure object in the graph area. Then do one of the following:

■ Select the Related Components subtab from the Detail notebook tab. Click the Edit Relationship... button.

■ Choose Edit=>Edit Relationship... .■ Click the Edit Relationship toolbar icon.

The Edit Relationships dialog box is opened. Figure 18 on page 174 shows an open Edit Relationships dialog box with a selected SIM cell opened for editing in the Edit This Relationship subdialog.



Figure 18 Edit Relationships dialog with Edit This Relationship subdialog

The Edit Relationships dialog box contains the following fields:

Table 42 Edit Relationship dialog: field descriptions

Field Description

Component name name of the selected infrastructure component

Component type identifies the infrastructure component subtype that has a consumer or provider relationship to the selected component and for which you want to search

Relationships lists the consumer, provider, or both consumer and provider relationships of the selected component subtype and component

Component identifies the infrastructure object related to the selected component

Direction indicates the event flow of the object relationship. A consumer direction indicates that the component object receives events and data from the selected component. A provider direction indicates that the component object sends events and data to the selected component.

State identifies current state of the relationship: active or inactive

Type specifies the class that contains the relationship type

Propagation Model identifies the status propagation model used for determining the propagated status from the provider’s main status

Editable indicates whether you can edit the object in BMC IX


Creating logical components

You can search on component types by selecting an Impact Administration subtype from the drop-down list. When you click on Search, it retrieves the relationships associated with the selected subtype.

Select an item in the Edit Relationships dialog, and right-click to open the pop-up menu. You can perform actions common to all object relationships: View Service Impact Graph, View Events, Edit Component..., Add Link, and Add Relationship... .

You can edit any of the component’s relationships by selecting it and then choosing the Edit Relationship button at the bottom of the dialog. The Edit This Relationship subdialog contains the following fields:

Creating logical components

You can add logical components to the Infrastructure Management service model. Logical components in this context refer to components that do not have a predefined registration event associated with them, as do the BMC infrastructure components listed in Table 38 on page 157.

Although logical components are not registered with the IAC and therefore do not provide real-time status information, they can help to complement the BMC infrastructure model. For example, you can add logical integrations and server processes to the model to represent an idealized infrastructure environment.

Deleting components

You can delete both logical service groupings/objects and live, registered objects from the Infrastructure Management service model.

Table 43 Edit This Relationship subdialog

Field Description

Consumer/Provider indicator

indicates the directional flow of the relationship between the selected component and the component subtype. You can modify the relationship.

Relationship Type Direct, Increasing, Decreasing,

Relationship Status Active or Inactive

Description Summary description of the relationship

NOTE The names of logically created components do not display in Korean in the graph viewing area while its component object does.


Deleting components

To organize your service model around its real-time components, you can delete logical groupings that do not have registered components associated with them.

Generally, you should delete the leaf objects, not objects that lie between other objects. If you delete objects that lie between other objects, some objects that should be deleted because of relationship associations with the other objects will nonetheless remain.

BMC recommends that you do not delete components that have been registered automatically with the Infrastructure Management service model. However, if you delete a live, registered object, it is removed from the Infrastructure Management service model, and an event of the class Service Model Component Delete is sent to the IAC.

TIP You can recover a deleted registered object by modifying the DATA/ADMIN_DATA/ADMIN_REGISTRATIONS table of the IAC in the Administration tab view.

You change the enable parameter for the specific component from NO to YES in the Edit tab. Then you restart the component to reregister it.


Executing remote actions


You can manage the infrastructure objects from the GUI. Select the object, right-click to open the pop-up menu, and choose Actions to display a list of the available actions.

Figure 19 Actions right-click menu

Depending on the current state of the component, not all actions are available.

You can also launch remote actions from the toolbar icons.

Depending on the type of component and its current state, a range of actions are available to you. See “Remote actions” on page 187 for an explanation.

(You can connect to remote systems from the Configuration and Support Package subtabs of the Administer notebook tab.)

Considerations when working with high availability cells

Your remote actions are restricted when working with a high availability (HA) configuration in which the primary cell server is down and the secondary cell server is in a passive state.

■ When the Impact Administration cell (IAC) is in an HA configuration, do not launch a remote action against any components in the Infrastructure Management view when the IAC primary server is down and its secondary server is in a passive state. In this case, the IAC rejects the actions.

■ When BEM or SIM cell servers are in standby mode, you can perform only the permitted actions on them.

NOTE An IAC cell that is in standby mode is shown in yellow.



When the secondary cell server is an active state while the primary cell server is down, which is the situation depicted by SIM Cell Server 1 and SIM Cell Server 2 in Figure 20 on page 178, the range of permitted actions increases.

Figure 20 High availability (HA) view: two cell servers

Special considerations for UNIX systems

If the Impact Administration Server resides on a UNIX or Linux system and the target application resides on Windows system, then you must configure the SSH or Telnet protocols on the Windows system to enable remote action. See “Configuring the BMC Impact Administration server to support remote actions” on page 114 for more information.

When launching remote actions against components that reside on UNIX systems, you may need to log in under one account to access the system and then log in under a separate account to launch the command. For example, you may not be able to log into the UNIX system as root. Instead, you log in under a separate user account. However, to execute the command, you may have to log in as root or as another user with the permission to execute the command.

When you select the Additional command credentials check box in the Credentials Information dialog box, the dialog box expands to provide you with two sets of login credentials to handle this situation.


Executing other actions

Executing other actions

Where appropriate for the component, you can perform the actions that are available in the Services tab view. These actions include

■ viewing the graph of a selected component and its relationships■ viewing events associated with the selected component■ setting manual status and maintenance mode■ adding links to components from container folders■ refreshing the graph view after making an edit to a component or relationship

Configuring the audit log

By default, Infrastructure Management automatically maintains an audit log of all remote actions that an administrator performs on remote hosts. The audit log uses the following format:

Table 44 on page 179 describes the audit log parameters:

TIME_STAMP LOG_LEVEL IAS_USER OS_USER SUB_TYPE:OBJECT ACTION_IDEXPLANATION

Table 44 Audit log parameters (part 1 of 2)

Audit log parameter Description

TIME_STAMP month, day, year, hour, minute, and second that the log entry was created. Uses the format mm/dd/yyyy hh:mm:ss

LOG_LEVEL the severity level of the logged action. Valid values include

■ INFO: informational message■ SEVERE: error message

A typical SEVERE message documents the error exceptions that occur during the execution of a remote action, such as Unable to save file on remote machine.

IAS_USER current BMC IX user name that has logged on and connected with the Impact Administration server

OS_USER user name that logs into the remote host’s operating system. This is the user name under which the action is executed on the remote host.



Supported component or application types

Infrastructure Management supports the following types in this product version:

Sample logs

A sample audit log for a remote startup action on a SIM cell might look as follows:

Similarly an audit log for a remote startup action on an IAS server might look like this:

SUB_TYPE the component or application type on the BMC IX administrator is performing the remote action. In version 7.1, Infrastructure Management supports the subtypes listed under “Supported component or application types” on page 180.

OBJECT user-specified value in the Object slot of the component or application on the which remote action is being executed

ACTION_ID unique Id associated with the remote action. This unique Id is defined in the corresponding actions.xml file stored on the computer where the BMC Impact Administration Server resides. For example, the ImpactManager.xml file is an actions file that applies to BEM and SIM cells. It is stored under the IMPACT_SOLUTIONS_HOME/server/data/admin/actions folder on the IAS computer.

EXPLANATION short text description of the logged action

■ EM_CELL ■ SIM_SERVER_1 ■ IBRSD

■ EM_SERVER_1 ■ SIM_SERVER_2 ■ BEM_SERVER_STANDBY

■ EM_SERVER_2 ■ IAC ■ SIM_SERVER_STANDBY

■ SIM_CELL ■ IAS ■ PS

Mon 07/23/2007 16:50:15 INFO iasuser superuser SIM_CELL:PUNE_CELL start_im_windows Executing action

Mon 07/23/2007 16:52:10 INFO iasuser superuser IAS_Server:PUNE_IAS_Server start_IASserver_window Executing action

Table 44 Audit log parameters (part 2 of 2)

Audit log parameter Description



Sample audit logs for the remote actions of restarting and stopping a SIM server cell follow:

Configuration parameters

These audit logs are stored by default under the IMPACT_SOLUTIONS_HOME/server/log/ias directory on the Impact Administration server.

You can configure the audit log by modifying the following properties in the ias.properties file:

Tue Aug 14 20:14:06 IST 2007 INFO user ADPROD\slondhe SIM_SERVER_1 :slondhe-pun-01 restart_im_WINDOWS Executing action. Tue Aug 14 20:14:40 IST 2007 INFO user ADPROD\slondhe SIM_SERVER_1 :slondhe-pun-01 stop_im_WINDOWS Executing action.

Table 45 Audit log IAS properties (part 1 of 2)


com.bmc.sms.ixscomm.util.auditLogEnable Boolean true/false value that indicates whether auditing is enabled. The default is true.

com.bmc.sms.ixscomm.util.auditLogFilename specifies the file path and name of the audit log file, using the %g indicator to show that the audit log files are cycled through a numerical sequence. For example, if

■ auditLogFilename=AuditLog%g.log■ auditLogFilecount=10■ auditLogLimit=5000

then the initial audit log is assigned the name AuditLog1.file. When its file size reaches 5000 bytes, a new audit log is generated with the same name but incremented by one: AuditLog2.file. As each log reaches the maximum size, a new audit log is created and incremented by one. When the maximum log file count (10 in this example) is reached, then the process repeats itself because only one cycle of logs is maintained. The first audit log of the new cycle starts at 1 (AuditLog1), overwriting the existing file. As new logs are generated in the new cycle, they overwrite the existing ones in sequence.

By default the audit logs are stored in the IMPACT_SOLUTIONS_HOME/server/log/ias directory. You can specify another directory path in this parameter value: for example, auditLogFilename=log/AuditLog%g.log, provided that the specified directory exists under IMPACT_SOLUTIONS_HOME/server.


Creating the support package

After you modify any of the properties in the ias.properties file, you must restart the Impact Administration server.


You can create a support package for troubleshooting purposes by collecting files from remote systems and saving them to a specified file path on the local or a remote system.

The support package contains the following files:

■ .dir files■ .conf files■ filter files■ selector files ■ mapping files■ trace files■ trace.conf files

In addition, it contains

■ default support files

These are internal files of the infrastructure application. They are not included in the other categories. They vary among the applications, but they include .baroc, .mrl, .wic, and .cmd files. Generally, for a cell server, this package contains the files of its KB directory and its log directory. You can choose which files to include. They also include a sysinfo.text file that captures active port connections, OS and hardware configurations, and network card details. The absolute file path to each file is included.

com.bmc.sms.ixscomm.util.auditLogLimit size in bytes of the audit log file. The default is 5000 bytes (approximately 4.88 kilobytes). While there is no predefined maximum size, BMC recommends that each log file not exceed 5 MB.

com.bmc.sms.ixscomm.util.auditLogFileCount indicates the number of audit log files that are cycled through during a rotation. After the specified number is reached, the cycle repeats itself, overwriting in sequence the log files of the previous cycle. The default is 1.

Table 45 Audit log IAS properties (part 2 of 2)




■ additional support files

This is a customizable list of files that the user can edit by adding or deleting files to or from the support package. It is designed to enable the user to add other files to the support package.

Specifying your support files

You can specify which support files you want to receive by the editing the corresponding slot in the Edit Service Component dialog for the selected component.

To specify which support files to include, select the component and choose Edit=>Edit Component... or choose Edit Component... from the right-click pop-up menu. The Edit Service Component dialog is displayed. Scroll down the list of slots. You can specify values in the slots specified in Table 46.

Your support files should be on the system on which the component is running. Enter the full path to the file you want to include. If you are adding multiple files, separate the complete file paths with commas. There is no limit to the number of files that you can add.

To compile your support package, choose the Administer=>Support Package tab. Browse to the destination folder where you want to save the list of configuration and log files, and select it. You can enter the issue number (maximum of 16 characters) if one has been assigned.

Table 46 Slots for specifying support files

Slot Description

Additional Support Files full path to other support files that you want to include

Configuration files full path to configuration files (.conf)

Dir files full path to *.dir files, such as mcell.dir or admin.dir

Filter files full path to *.filter files

Map files full path to *.map files

Selector files full path to *.selector files

Trace conf files full path to the *.trace file

Trace files full path to the trace logs

WARNING MS Windows does not support the creation of files that have any of the following special characters in their file names: , \, /, ?, *, ", |, <, >. If the BMC IX is installed on MS Windows, do not enter any of the special characters in the Issue Number slot. Otherwise, the support package creation fails.



If you do enter the issue number, assign it as a prefix to the support package name. You can type a short, but informative, description of the package (maximum of 256 characters). Then click Create Package.

The file name of the support package file follows this format:

The OBJECT_NAME value is taken from the object slot of the selected component. The time stamp is in the format: MMDDYY_HHMMSS.

UNIX processing note

Under UNIX, it may take several minutes to create a support package. Two causes can contribute to the delay in processing:

■ whether the component for which you are creating the support package resides in a different domain from the system on which you are running BMC IX. If it does lie in a different domain, expect a delay.

■ the size of the zipped or tarred file. The greater the size, the longer the delay, especially as the file approaches 500 kb or larger.

Reviewing the audit log of the support package

Internally, the process of building a support package consists of these actions:

1. saving the OS-based compression utility (zip or zip.exe) to the remote system

2. creating the support package

3. removing the OS-based compression utility from the remote system

4. executing the get-file action to retrieve the support package from the remote system and putting on the system where IAS resides

5. getting the binary file from the IAS system to the local system where BMC IX resides

OBJECT_NAME_support_package_TIMESTAMP.zip


Background to Infrastructure Management

Because this is a remote action, the audit log captures the process. If the support package creation is a success, you receive an audit log message that looks similar to the following MS Windows example:

In a successful support package creation, the audit log does return an error message: Fri Aug 17 12:49:31 IST 2007 SEVERE user ADPROD\slondhe SIM_SERVER_1 :slondhe-pun-01 remove_zip_WINDOWS Stderr returned with some error. You can ignore this error because users can still retrieve the zipped support package automatically from the remote system without any manual intervention.

If you receive a SEVERE error message on any of the other support package actions, such as saveRemoteFile, create_support_package, get_file, and getBinaryFile, it indicates that the support package creation failed. Discard it, and try again.

Background to Infrastructure ManagementThe information in this section describes some of the internal workings of Infrastructure Management.


The essential component of Infrastructure Management is the Impact Administration cell (IAC). Its name is displayed as Admin in the GUI.

The IAC is a custom SIM cell that contains a specialized Knowledge Base. This cell accepts registration, configuration, and other events from BMC product components and applications and then creates the component definitions based on the event information.

Fri Aug 17 12:49:25 IST 2007 INFO user ADPROD\slondhe SIM_SERVER_1 :slondhe-pun-01 saveRemoteFile : zip.exe Executing action. Fri Aug 17 12:49:28 IST 2007 INFO user ADPROD\slondhe SIM_SERVER_1 :slondhe-pun-01 create_support_package_WINDOWS Executing action. Fri Aug 17 12:49:30 IST 2007 INFO user ADPROD\slondhe SIM_SERVER_1 :slondhe-pun-01 remove_zip_WINDOWS Executing action. Fri Aug 17 12:49:31 IST 2007 SEVERE user ADPROD\slondhe SIM_SERVER_1 :slondhe-pun-01 remove_zip_WINDOWS Stderr returned with some error. Fri Aug 17 12:49:32 IST 2007 INFO user ADPROD\slondhe SIM_SERVER_1 :slondhe-pun-01 get_file : Test1_support_package.zip Executing action. Fri Aug 17 12:49:33 IST 2007 INFO user ADPROD\slondhe SIM_SERVER_1 :slondhe-pun-01 getBinaryFile : Test1_support_package.zip Executing action.


Impact Administration server

How a product component registers and communicates with the IAC

To register with the IAC, the component or application sends a configuration information event. This configuration event contains certain required slots such as mc_event_model_version, mc_object and mc_tool, os_class, and so forth. The component or application sends the configuration information event upon each startup or change in its configuration.

After it registers with the IAC, the application or component sends status information such as startup, shutdown, and error events.

Unregistering with the IAC

In the current 7.1 release, you cannot formally unregister a component. To remove a component from the Intrastructure Management model, you must manually delete it. It is removed from the Infrastructure Management GUI, but not from the model contained in the IAC. For example, its .log and .conf files persist in the IAC. The application or service, however, is no longer operational.

Impact Administration server

The IAC is a component of the Master version of the Impact Administration Server (IAS). The IAS determines several properties of BMC Impact Explorer, including roles and permissions, cell-related information for connected cells, high availability, and other properties. The IAS provides a series of CLIs that enable you to modify its property files.

Unidirectional event flow

All registered components pass events and statuses to the Infrastructure Management GUI via the Impact Administration cell. This event flow is one way: from the components to Infrastructure Management. However, you can perform actions on components that reside on remote systems from the Infrastructure Management GUI.

NOTE All event information should be compliant with the event format strictures of version 1.1.00 of the Common Event Model (CEM). See the Common Event Model appendix in the BMC Impact Solutions:Knowledge Base Development guide for more information.


Remote actions

Remote actions

While events flow only from the components to the Infrastructure Management GUI, administrators can initiate actions on the components from the GUI. Depending on the type of component and its status, you can initiate several actions on the local or remote component.

How context-sensitive remote actions are processed

The current state of a selected component is shown in its run_state slot (Run State), which you can view in the Details=>General subtab in the Infrastructure Management tab. The different run_state values are described in Table 47 on page 187:

The current run_state of the component determines which context-sensitive actions are disabled or enabled from the Actions option on the right-click menu.

Table 48 on page 188 indicates which menu options are enabled (Yes) or disabled (blank) for each run_state of a normal cell or a primary cell in an HA configuration.

Table 47 run_state values for components

run_state value Description

unknown state of the component cannot be determined

active indicates that the cell is the active server component of an HA relationship

unavailable the connection with the component is disrupted or the component is down

started the component is online; unable to determine if it’s the active component in an HA relationship

stopped the component has sent is stopped and has sent a status event indicating that it is stopped

paused the component is in maintenance mode

passive the secondary cell in an HA relationship is in standby mode


Remote actions

Table 49 on page 188 indicates which menu options are enabled (Yes) or disabled (blank) for each run_state of a secondary cell in an HA configuration.

Table 48 Component state and menu options: normal or primary cell in an HA configuration

Menu options

run_state

Start Cell

Server Process

Stop Cell

Server Process

Restart Cell

Server Process

Pause Events Admittance

Resume Events Admittance

Set to Standby

Set to Active

state_unknown Yes

state_active Yes Yes Yes

state_unavailable Yes

state_started Yes Yes Yes

state_stopped Yes

state_paused Yes Yes Yes

state_passive None

NOTE If a component in an unknown state is already started and you choose Actions=>Start, you receive a status message notifying you that the component is started already.

Table 49 Component state and menu options: secondary cell in an HA configuration

Menu options

run_state

StartCell

Server Process

StopCell

Server Process

RestartCell

Server Process

Pause Events Admittance

Resume Events Admittance

Set to Standby

Set to Active

state_unknown Yes

state_active Yes Yes Yes Yes

state_unavailable Yes

state_started Yes Yes Yes

state_stopped Yes

state_paused Yes Yes Yes

state_passive Yes Yes Yes


Remote actions

Exceptions

Generally, most component objects receive the actions Start, Stop, Restart, Pause, and Resume.

For cell servers, the Start, Stop, and Restart menu options in the Actions submenu are described as

■ Start Cell Server Process■ Stop Cell Server Process■ Restart Cell Server Process

For other objects apart from cell servers, the Start, Stop, and Restart menu options in the Actions submenu are described as

■ Start Process■ Stop Process■ Restart Process

Different actions are available to different types of components. Table 50 lists the main exceptions:

Logical components that you add to the Infrastructure Management service model receive no actions.

Table 50 Components and actions

Component Exception

HA cell all actions. The HA cell is the only component that allows the Set to Standby and Set to Active menu options.

Impact Administration server (IAS)

receives the Restart action only

Publishing Server receives the Start, Stop, and Restart actions

IBRSD receives the Stop, Start, and Restart options

normal cells receives the Stop, Start, Restart, Pause Events Admittance, and Resume Events Admittance options


Remote actions


C h a p t e r 7
7 Configuring BMC Impact Event Adapters
This chapter describes the function and contents of the mcxa.conf file, emphasizing the structure and contents of the configuration specifications for the various Adapters.

Configuration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Adapter definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Configuration tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

About the mcxa.conf file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196Configuration file structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196Configuration file definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198msend command configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Parameter types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Global parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200Common parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202Specific parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Applying configuration changes during run-time . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211BMC Impact Event Log Adapter for Windows configuration . . . . . . . . . . . . . . . . . . 211

NOTE The BMC Impact Event Log Adapter for Windows runs independently of the mcxa process and the mcxa.conf file.


Configuration overview

Configuration overviewYou configure the BMC Impact Event Adapters by modifying the parameters that control their behavior. All parameters are recorded in the mcxa.conf file.

■ Global parameters control certain behavioral aspects of all Adapters running on the engine manager (mcxa process). Global parameters are listed in the Global Parameters section of the mcxa.conf file.

■ Common parameters behave like global parameters. Common parameters are listed in the Common Parameters section of the mcxa.conf file.

■ Specific parameters dictate selected aspects of the behavior on an individual Adapter instance. These parameters are recorded in the mcxa.conf file in a definition that is specific to an Adapter instance.

Adapter definitions

The mcxa.conf file contains definitions for all of the Adapters running on the computer, as follows:

■ All types of BMC Impact Event Adapters are listed in and are run from the mcxa.conf file. For example, IP Adapters do not use a separate mcxa.conf file from LogFile Adapters.

■ Multiple Adapter instances can be defined in the file. For example, you can have three different TCP Client Adapters running, each with a unique configuration.

For more information about the structure of the mcxa.conf file, see “About the mcxa.conf file” on page 196.

Configuration tasks

To configure the global aspects of the Adapters environment and the parameters specific to each Adapter instance, perform the tasks in the order described in Table 51.


Configuration tasks

NOTE You can add, remove, or modify global or common parameters, Adapter instance definitions, or parser definitions in the mcxa.conf file at any time.

If you make a change when the engine manager (the mcxa process) is stopped, your changes will be applied when you restart the engine manager. You can also make changes during run-time. To ensure that these changes are recognized, see “Applying configuration changes during run-time” on page 211.

Table 51 Adapter configuration tasks (part 1 of 4)

Phase Action Details Where to go

Accessing the configuration file

Open the mcxa.conf file.

The file is located at MCELL_HOME\etc\mcxa.conf

“About the mcxa.conf file” on page 196

Configuring the Adapter environment

Specify values for global parameters.

Some parameters are required and some are optional.

“Global parameters” on page 200

Specify values for common parameters.

Some parameters are required and some are optional.

“Common parameters” on page 202

Configuring Adapters

Decide which Adapters you want to use.

Determine what you want to accomplish with the Adapters and select the Adapters appropriate to the task.

■ BMC Impact Solutions: Event Monitoring Operator’s Guide

■ “IP Adapter types” on page 491


Configuration tasks

Configuring Adapters, continued

Gather the information required to define the Adapter instances.

Review the specific parameters associated with each Adapter that you want to use. Make a list of values that you want to add or modify for each Adapter instance (such as port numbers).

You must specify which parser each of your IP Adapter instances will use. Review the types of parsers available.

BMC Software recommends that you create a brief planning sheet for each Adapter, listing the information that you want to include in the Adapter definition.

■ “Perl EventLog Adapter for Windows parameters” on page 204

■ “LogFile Adapter parameters” on page 205

■ “SNMP Adapter parameters” on page 209

■ “IP Adapter types” on page 491

■ “IP Adapter parsers” on page 507

Modify or add Adapter definitions.

The mcxa.conf file contains sample Adapter definitions for all supported parameters.

1. Copy these definitions below the Write your configuration below heading at the end of the mcxa.conf file.

Make a copy for each Adapter instance that you require.

2. Add or modify Adapter parameters as required for each Adapter instance.

not applicable




Configuration tasks

Configuring Adapters, continued

Define any required IP Adapter parsers.

The mcxa.conf file contains sample parser definitions for all supported parameters.

1. Copy these definitions below the Write your configuration below heading at the end of the mcxa.conf file.

Make a copy for each parser instance that you require.

2. Add or modify parser parameters as required for each unique parser instance.

“IP Adapter parsers” on page 507

(optional) Enable Adapters.

You can enable Adapters at any time after they have been configured. However, some Adapters may require additional preparatory work before they are enabled:

■ If you intend to use a custom mapping, review Appendix F, “BMC Impact Event Adapters MAP files,” on page 473 and do any required preparatory work before enabling any Adapters using custom mappings.

■ Before enabling an SNMP Adapter, perform any required configuration involving the mib2map utility.

Note: When enabling an IP Adapter, you must also enable the parser that it uses (if that parser is not already enabled).

■ “Custom maps and map-related files” on page 474

■ BMC Impact Solutions: Installation Guide

Save and close the mcxa.conf file.

not applicable not applicable




About the mcxa.conf file

About the mcxa.conf fileThe Adapters are configured in a single configuration file, MCELL_HOME\etc\mcxa.conf, by default. You can use other configuration files by starting the Perl process with the CLI -c option.

Configuration file structure

Figure 21 on page 197 shows the structure of the default Adapters configuration file, mcxa.conf.

Configuring the SNMP mib2map utility

Configure the mib2map utility (SNMP Adapter only).

The mib2map utility specifies how SNMP data is converted to BMC Impact Manager events. You must perform some configuration of this utility to ensure that SNMP data is presented correctly in the events.

Note: Perform this task before you enable any SNMP Adapter instances.

BMC Impact Solutions: Installation Guide

Enabling Adapters

Remove or comment out DISABLE in the Adapter definitions.

Removing or commenting out DISABLE in an Adapter definition enables it immediately. Do this only when you are ready to collect data.

Notes:

■ If you did not enable the Adapters when you first defined them, then you must re-open the mcxa.conf file, remove DISABLE from the required definition, and save and close the file.

■ When enabling an IP Adapter, you must also enable the parser that it uses (if that parser is not already enabled).

BMC Impact Solutions: Event Monitoring Operator’s Guide




Configuration file structure

Generally, global parameters either apply to the Adapter engine or serve as default parameters for all specific Adapters. Specific parameters for the specific Adapters are located after the [...] Adapter sections.

The Adapters are specified by the Engine parameter:

Engine = <engine_module>

<engine_module> is the name of the Perl module that is loaded by the Engine Manager Perl module. It must be located in the standard Perl library directory or in a subdirectory of MCELL_HOME\lib\perl. It usually can be user defined. The predefined default engines are as follows:

■ Engine = MA::ELogfile for any log file management, including UNIX syslog■ Engine = MA::ESnmpTrap for SNMP trap management■ Engine = MA::EEventLog for Perl EventLog for Windows management

The IP Adapter definitions vary slightly, with the inclusion of Adapter:: in the path.

■ Engine = MA::Adapter::TcpClient

■ Engine = MA::Adapter::TcpServer

■ Engine = MA::Adapter::Telnet

■ Engine = MA::Adapter::UdpClient

■ Engine = MA::Adapter::UdpServer

You can configure several identical Adapters in mcxa.conf to monitor several log files or to listen from several SNMP ports, for example.

Figure 21 mcxa.conf file structure

# Unnamed section is considered as [default]# [default] is optional<global_parameter1> = <gval1><global_parameter2> = <gval2># ...[1st Adapter]<ada1_param1> = <a1val1><ada1_param2> = <a1val2># ...[2nd Adapter]<ada1_param1> = <a1val1><ada1_param2> = <a1val2># ...


Configuration file definitions

The name of the destination cell is provided in the common parameter, ServerName. It can be identified in the specific section, so that two different Adapters can send events to different cells. In addition, ServerName can contain the name of several cells, separated by colons. In this case the Adapter tries to send events to one the cells in the list, always trying the first cell (the primary cell) in the list when any other cell goes down.

Other information about the configuration, the parameters list, and examples are located in the header of the mcxa.conf file.

Configuration file definitions

The mcxa.conf file contains comments, sections, and parameter definitions.

Comments

Anything that follows the # character on a line is ignored, including the # character, unless it is included inside single or double quotes.

Sections

The configuration file is divided into sections beginning with the default section at the beginning of the file. Each subsequent section represents an instance of a specific Adapter. An adapter section begins with a section name in square brackets “[]” and ends at the beginning of another section or at the end of the file.

Configuration file parameters

The configuration file primarily contains parameter definitions in the form of

<param> = <value>

WARNING BMC Software recommends that you do not put comments on lines that contain quoted values. In ambiguous cases, quotes take precedence, which may cause unintended results.


msend command configuration

The <param> and <value> variables are defined as follows:

Figure 22 shows examples of parameters and values. Section headers that indicate the type of entity being described with the parameters that follow are displayed in magenta text. Parameter names are displayed in red text. Parameter values are displayed in blue text.

msend command configuration

Events produced by the Adapters are sent to the cell with the BMC Impact Manager msend command. To set up non-default parameters, configure msend with MCELL_HOME\etc\msend.conf or MCELL_HOME\etc\mclient.conf. I DON’T KNOW WHAT THIS MEANS.

Parameter typesTable 52 on page 200 describes the parameters types available for use with the BMC Impact Event Adapters.

Variable Description

<param> The parameter name. It cannot contain blank spaces.

<value> The parameter value. The first character of <value> is the first character of the line that is not blank and not a pound sign (#). <value> can be enclosed within double or single quotes.

Figure 22 Parameter and value examples

[TcpClient] Engine = MA::Adapter::TCPClientParser = MySeparatorParserMapFile = mctcpclt.mapRemoteHost = localhostRemotePort = 13 # date/time service

[MyTcpServer]Engine = MA::Adapter::TcpServerMaxClients = 10RestartInterval = 30MapFile = mctcpsrv.mapLocalHost = 127.0.0.5LocalPort = 1999Parser = MyFixedWidthParser


Global parameters

Global parameters

Table 53 describes the global parameters that can be used with the Adapters and each parameter’s characteristics.

Table 52 Parameter types

Parameter type Description

Global Global parameters influence the global Perl process and must be defined in the default section of the configuration file.An example of a global parameter is ReadPerEngine.

Common Common parameters are common to all Adapters, but unlike global parameters, common parameters can be different for different Adapter instances. An example of a common parameter is MapFile.

These parameters are defined in the default section of the mcxa.conf file, in the specific Adapter sections, or both. If a common parameter is defined in the default section, it applies to all Adapters unless it is also defined in a specific Adapter section. If it is defined in a specific section, it applies only to that Adapter.

Specific Specific parameters apply only to one specific type of Adapter. They are generally defined in specific Adapter sections; however, by using the Engine parameter, you can define default specific parameters in the default section of the mcxa.conf file that apply to all relevant specific Adapters.

Table 53 Global parameters (part 1 of 3)

Parameter Type UnitDefault value Description

EventsPerPoll Integer > 0 events 5 used only if ReadsPerEngine = 1; defines the maximum number of events each Adapter generates per poll cycle.

If ReadsPerEngine = 1, records are read until the number of events created equals the value of the EventsPerPoll parameter. Otherwise, the maximum reads per engine per poll cycle is set by the value of the ReadsPerEngine parameter.

PollInterval Integer > 0 sec 5 sleep interval during which all Adapters are idle

ReadsPerEngine Integer > 0 reads 5 defines the maximum number of reads each Adapter performs per poll cycle.

If ReadsPerEngine = 1, records are read until the number of events created equals the value of the EventsPerPoll parameter. Otherwise, ReadsPerEngine equals the maximum reads per engine per poll cycle.


Global parameters

TraceFile File name none mcxa.trace name of the trace file

If the name does not contain a path, the trace file is saved to the default trace file directory, MCELL_HOME\tmp\Adapters.

TraceFileCount Integer > 0 none 10 maximum number of renamed trace files that are kept in the trace file directory

When the number of files exceeds the specified limit, the oldest trace file is deleted.

To expand the amount of saved trace information, increase the value of one of the following parameters:

■ TraceSizeMax (default = 1,000,000)■ TraceFileCount (default = 10)

TraceLevel Integer (0–6) none 3 trace level

Valid values:

■ 0 – disables all traces■ 1 – header messages■ 2 – fatal messages■ 3 – major errors■ 4 – minor errors■ 5 – normal output■ 6 – verbose output

Note: TraceLevel = 6 produces very large trace files and is recommended only for debugging.




Common parameters

Common parameters

Table 54 on page 203 describes the common parameters that can be used with the Adapters.

TraceSizeMax Integer >= 0 byte 1,000,000 maximum trace file size

When the Adapter detects that the maximum size is reached, the trace file is closed and renamed mcxa0.trace.

Notes:

■ Old trace files rotate as 0–>1, ..., n–>n+1.

■ The number of trace files to keep is managed with the TraceFileCount parameter.

TraceSizePeriod Integer > 0 none 10 frequency, in number of messages logged, at which the Adapter checks the size of the trace file

A trace file is archived when it exceeds the size specified with the TraceSizeMax parameter.




Common parameters

Table 54 Common parameters (part 1 of 2)

Parameter Type Description

Engine Perl module name

name of the Adapter

This parameter is required. Default values are as follows:

■ Engine = MA::ELogfile for any log file management, including UNIX syslog

■ Engine = MA::ESnmpTrap for SNMP trap management

■ Engine = MA::EEventLog for Perl EventLog for Windows management

The IP Adapter definitions vary slightly, with the inclusion of Adapter:: in the path:

■ Engine = MA::Adapter::TcpClient■ Engine = MA::Adapter::TcpServer■ Engine = MA::Adapter::Telnet■ Engine = MA::Adapter::UdpClient■ Engine = MA::Adapter::UdpServer

MapFile File name map file name

The map file must be located in the MCELL_HOME\etc directory. Full paths are not accepted.

Default map name values depend on the Adapter type. Default map names are listed in “Default MAP files” on page 474.

MapFunctionsName File name name of a Perl script or Perl module that contains user-defined functions to be used inside the .map file

The use of this parameter is now deprecated. Use the REQUIRE directive, described in “REQUIRE directive” on page 486, from inside the .map file.


Specific parameters

Specific parameters

Each Adapter definition includes specific parameters that are used to configure only the Adapter instance in which they are listed.

Each type of Adapter has a different set of specific parameters.

■ For Perl EventLog Adapter for Windows parameters, see “Perl EventLog Adapter for Windows parameters” on page 204.

■ For EventLog Adapter parameters, see “LogFile Adapter parameters” on page 205.

■ For SNMP Trap Adapter parameters, see “SNMP Adapter parameters” on page 209.

■ For IP Adapter parameters, see Appendix G, “IP Adapters,” on page 489.

Perl EventLog Adapter for Windows parameters

This section describes the specific parameters used by the Perl EventLog Adapter for Windows. For details about configuring the BMC Impact Event Log Adapter for Windows, see “BMC Impact Event Log Adapter for Windows configuration” on page 211.

MapUseDefaultClass Bool (0–1) indicates whether incoming events that do not match a CLASS described in the map file are mapped to the DEFAULT class

Valid values:

■ 0 – events are dropped (this is the default).■ 1 – events are mapped to the DEFAULT class.

ServerName Cell name name of the cell to which events processed by the Adapter are sent

The cell parameters must be found in MCELL_HOME\etc\mcell.dir.

ServerName can contain the names of several cells, separated by colons, such as Cell1:Cell2:Cell3:.... Events are sent to these cells according to their numerical order. For more information, see the mposter/msend documentation in the BMC Impact Manager System Configuration and Maintenance Guide.

If ServerName is not defined, events are formatted in BAROC and sent to the standard output.

Table 54 Common parameters (part 2 of 2)



Specific parameters

To use the Perl EventLog Adapter for Windows, set the Engine parameter in the mcxa.conf file as follows:

Engine = MA::EEventLog

The default map file is mceventlog.map.

Table 55 describes the Perl EventLog Adapter parameters.

LogFile Adapter parameters

To use the LogFile Adapter for Windows, set the Engine parameter in the mcxa.conf file as follows:

Engine = MA::ELogfile

The default map file is mclogfile.map.

Table 56 on page 206 describes the LogFile Adapter parameters.

Table 55 Perl EventLog Adapter for Windows parameters


ELResendAll enables restarting the reading of the EventLog

If this parameter is set to 1, all the events in the eventlog are resent one time.

Default: 0

WARNING: The BMC Impact Event Log Adapter for Windows EResendAll parameter is equivalent to the Perl ELResendAll parameter. The parameter names are similar but the values are different. For this reason, BMC Software recommends that you exercise caution when using them. Be sure to use a value of 0 or 1 for the Perl EventLog Adapter ELResendAll parameter and a value of Yes or No for the BMC Impact Event Log Adapter EResendAll parameter. For details about configuration the parameters for the BMC Impact Event Log Adapter for Windows, see “BMC Impact Event Log Adapter for Windows configuration” on page 211.

ELRecoveryIntervalMin recovery time interval, specified in minutes

Unless ELResendAll is set to 1, an Adapter processes events that arrived in the log since it was stopped. ELRecoveryIntervalMin prevents processing of old events if the Adapter has been stopped for some time. That is, the Adapter will process the events that are younger than ELRecoveryIntervalMin.

Default: 1440 minutes (1 day)

ELLogNotRead a string that contains the names, separated by a colons, of the event logs the user does not want to read, such as System, Application, or Security


Specific parameters

Table 56 LogFile Adapter parameters (part 1 of 4)


LogFile File name none standard input

full path to the monitored log file

LogFile supports a single file name. Use several Adapter instances to monitor several log files.

LogFieldSeparator Regex none \s+ a regular expression, often a character such as “,”, that delimits the attributes of an event when LogRegExpr is empty

Note: No syntactical analysis of the event occurs with this parameter, such as detecting a LogFieldSeparator inside quoted strings.

LogFlushPosPeriod Integer > 0 none 10 number of events after which the log position is saved to disk

The position file is flushed after the number of incoming log entries reaches the number specified with LogFlushPosPeriod.

Note: Setting LogFlushPosPeriod to a low value in an environment where many short events arrive at a high rate can degrade performance. See the LogRememberPos parameter on page 208 for more information.

LogKeepEmpty Bool (0–1) none 0 indicates whether to keep or drop empty events or events only constituted by blanks

Valid values:

■ 0 – drop events■ 1 – keep events

LogMaxCount Integer > 0 none 10 maximum number of log files when log rotation is enabled

For example, if LogMaxCount=5, <logfile>0—4 are saved. <logfile>i is always newer than <logfile>i+1. If LogMaxCount=–1, all log files are kept.

Note: Specify 0 if you do not want to keep log files.

LogMaxSize Integer > 0 byte 1,000,000 log file maximum size, in bytes

When the LogMaxSize value is reached, the log file is rotated. For more information, see the LogRotate parameter on page 208. If LogRotate=0, LogMaxSize is not used.


Specific parameters

LogProcessName String none empty (UNIX only) name of the process receiving the kill HUP command

LogProcessName is not used if LogSupportKillHUP=0. See LogSupportKillHUP on page 209.

LogReadAll Bool (0–1) none 0 indicates whether the whole log file is read the first time the Adapter starts

Valid values:

■ 0 – is not read■ 1 – is read

LogReadAllReopen Bool (0–1) none 1 indicates whether an Adapter that detects that a log file has changed opens a new log file from the beginning or the end

Valid values:

0 – opens from the end1 – opens from the beginning

LogRecordSeparator Regex none \n regular expression, often a simple character or string, that delimits two events

Note: If LogRecordSeparator is empty (LogRecordSeparator=“”), an event is found as soon as the regular expression encounters a match. The matching regular expression is consumed and the remainder of the file is used to detect the next event.

LogRegExpr Regex none empty contains a regular expression, in Perl 5 style, used to match an event

The pattern variables $1, $2, ... are saved in $<logVarPrefix>1, $<logvarPrefix>2, ..., and are declared in the INPUT_VARIABLES section of the .map file.

$<logVarPrefix>0 contains the whole pattern.

$complete contains the whole string between two LogRecordSeparator parameters.

If the regular expression matches the whole string between two LogRecordSeparator parameters, both $complete and $<logVarprefix>0, contain the whole event.

If LogRegExpr is empty (logRegExpr=""), LogFieldSeparator is used instead.




Specific parameters

LogRegExprGlobal Bool (0–1) none 1 indicates whether matching with the LogRegExpr parameter is performed globally

Matching is global when you use the /g modifier of a Perl regular expression. In this case, the pattern is applied as many times as possible to the string. Each time the pattern matches, it is stored in $<logvarPrefix><n> variables, as explained in LogRegExpr on page 207. For example, if LogRegExpr=“\w+” and LogRegExprGlobal=1, every word of the event is stored in $<logvarPrefix><n> variables (n>=1).

LogRememberPos Bool (0–1) none 0 indicates whether the Adapter persistently remembers the position of the last log entry

Valid values:

■ 0 – does not remember position■ 1 – remembers position

Note: This information is stored in MCELL_HOME\log\Adapters\perl\elogfile.pos.

LogRotate Bool (0–1) none 0 indicates whether a new logfile is created when the size of the logfile becomes greater than the value of the LogMaxSize parameter

If a new logfile is created, the old logfile is renamed or deleted, depending on the value of LogMaxCount. If the old log file is kept, it becomes <logfile>0[.<ext>], <logfile>0[.<ext>] becomes <logfile>1[.<ext>], ... and <logfile><logMaxCount>[.<ext>] is deleted if the value of LogMaxCount is different from –1.

LogSmartOpen Bool (0–1) none 1 indicates whether the part of the log file that has not been consumed is considered as being appended to the beginning of the newer log file, when the log file is replaced

Valid values:

■ 0 – not appended■ 1 – appended

LogStatPeriod Integer > 5 sec 15 indicates whether the Adapter regularly performs the stat command to check whether the logfile exists, to check its i-node on UNIX platforms, or to check whether its size has not decreased on Windows platforms




Specific parameters

SNMP Adapter parameters

To use the SNMP Adapter, set the Engine parameter in the mcxa.conf file as follows:

Engine = MA::ESnmpTrap

The default map file is mcsnmptrapd.map.

Table 57 on page 210 describes the SNMP Adapter parameters.

LogSupportKillHUP Bool (0—1) none 0 (UNIX only) If LogSupportKillHUP=1, a kill -HUP command is launched on LogProcessName at each rotation of the log file. Note that if LogSupportKillHUP=0 and LogRotate=1, it is important to ensure that the process that generates the events can detect the rotation.

LogVarPrefix String none “varlog” prefix of the input variables that corresponds to the matching of the event variables $<logVarPrefix>0 to $<logVarPrevix><n>, where <n> is the maximum number of matches.

The prefix must be defined in the INPUT_VARIABLES section of the .map file. Alternatively, the notation $<logVarPrefix>0-i can be used to match any arbitrarily long list of patterns.




Specific parameters

Table 57 SNMP Adapter parameters


SnmpDatFile File name name of the .dat file that contains information used to translate incoming traps

If the parameter value is a relative path, the file must be located in the MCELL_HOME\etc directory. The .dat file is an enhanced version of the old .oid file. It can contain additional information to map enumerations and to extract indexes.

This file contains the results of the output of the BMC Impact Manager mib2map tool. Do not attempt to create this file manually.

Default: mcsnmptrapd.dat

SnmpGetIndexes Bool (0—1) starts and stops index extraction, mainly for performance purposes

By default, the indexes, such as the suffixed dotted numbers of the object identifiers (OIDs), are extracted and stored in the special $idx input variable. $idx is a reference on a list of lists.

Valid values:

■ 0 – starts■ 1 – stops

SnmpLocalAddr IP address specifies which interface to use on a computer with two or more interface cards

SnmpOIDFile File name name of the file containing translations from SNMP OIDs to strings

If the parameter value is a relative path, the file must be located in the MCELL_HOME\etc directory. The use of SnmpOIDFile is now obsolete. Use the complete SnmpDatFile parameter instead.

Default: mcsnmptrapd.oid

SnmpPort Integer > 0 port of the UDP SNMP server

Default: 162

SnmpTrapLength Integer > 0 initial value of the buffer that receives SNMP traps

Default: 8192

Use the SnmpTrapLength parameter default setting. If you must modify it, be aware that an MC_ADAPTER_ERROR will occur if the SnmpTrapLength value is smaller than the actual size of the trap.

NOTE The BMC Impact Manager SNMP Adapter does not respond to INFORM messages that it may receive, but it does parse the SNMP message and generate an event.


Applying configuration changes during run-time

Applying configuration changes during run-time

You can modify the mcxa.conf configuration file during run-time. When the engine manager detects that the configuration file has changed, it stops the currently running affected Adapters, and then restarts them according to the new values in the configuration file.

BMC Impact Event Log Adapter for Windows configuration

The configuration parameters for the BMC Impact Event Log Adapter for Windows are stored in the following Windows registry key:

You can configure the BMC Impact Event Log Adapter for Windows Adapter by modifying the specified parameter values in the Windows registry. Table 55 describes the configuration parameters.

"HKEY_LOCAL_MACHINE\SOFTWARE\BMC Software\Eventlog Adapter"

NOTE For Microsoft Windows 2003 Server X64 (32-bit compatibility mode) only, the correct path to the registry key for the specific parameters for the BMC Impact Event Log Adapter for Windows is “HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\BMC Software\Eventlog Adapter”.


BMC Impact Event Log Adapter for Windows configuration

Table 58 Windows Event Log Adapter parameters


EResendAll enables restarting the reading of the EventLog

If this parameter is set to Yes, all the events in the eventlog are resent one time.

Default: No

WARNING: The BMC Impact Event Log Adapter for Windows EResendAll parameter is equivalent to the Perl ELResendAll parameter. The parameter names are similar but the values are different. For this reason, BMC Software recommends that you exercise caution when using them. Be sure to use a value of 0 or 1 for the Perl EventLog Adapter ELResendAll parameter and a value of Yes or No for the BMC Impact Event Log Adapter EResendAll parameter. For details about configuration the parameters for the Perl EventLog Adapter for Windows, see the BMC Impact Solutions: General Administration guide.

ERecoveryIntervalMin recovery time interval, specified in minutes

Unless EResendAll is set to Yes, an Adapter processes events that arrived in the log since it was stopped. ELRecoveryIntervalMin prevents processing of old events if the Adapter has been stopped for some time. That is, the Adapter will process the events that are younger than ELRecoveryIntervalMin.

Default: 1440 minutes (1 day)

PollInterval time interval, in seconds, at which the Adapter checks for new log entries

ELogNotRead A string that contains the names, separated by a colon ':', of the event logs the user does not want to read, such as System, Application, or Security.


C h a p t e r 8
8 Defining presentation names
This chapter describes how to add or modify user-friendly presentation names in the following BMC Impact Solutions interfaces: BMC Impact Explorer, BMC Impact Service Model Editor, and BMC Impact Portal.


Presentation names overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214Presentation name resource file locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214Default presentation name definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Creating a new presentation name resource file. . . . . . . . . . . . . . . . . . . . . . . . . . . 216Presentation name resource files search order . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Defining presentation names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218Creating or modifying presentation name keys . . . . . . . . . . . . . . . . . . . . . . . . . . . 218Digitally signing a .jar file with a digital test certificate . . . . . . . . . . . . . . . . . . . . 220

Enabling or disabling presentation names in BMC Impact Explorer tool tips . . . . . 221


Presentation names overview

Presentation names overview By default, BMC Impact Solution products use user-friendly data labels (presentation names) in the user interface instead of the internal object names. For example, the presentation name Occurred is used in the BMC Impact Explorer event list column title and the Summary tab instead of the internal slot name date_reception.

Table 59 describes the objects for which presentation names are defined.

Presentation name resource file locations

Presentation names are defined within a presentation name resource file. The default presentation name resource file is the kb_core_resource.properties file. The location of the kb_core_resource.properties file depends on which BMC Impact Solutions application you are using.

■ For BMC Impact Explorer, the default presentation names are defined in the following two files:

■ InstallDir\BMC Software\MasterCell\console\lib\lang\kbinfo\kb_core_resource.properties

Table 59 Presentation names for BMC Impact Solution interfaces

Interface Objects with presentation names

BMC Impact Explorer - Events View

■ event class names■ slot names■ enumeration class names and values■ collector names■ action names

BMC Impact Explorer - Services View

■ service model class names (component types) and slot names■ service model management class and slot names■ service model enumeration class names and values

BMC Impact Explorer - Administration View

■ policy type names■ event class names■ slot names - In the Event Selection Criteria column, the internal

slot names are shown because this is the actual text of the ECF.

BMC Impact Portal ■ event class names■ slot names■ enumeration class names and values■ service model class names (component types) and slot names■ service model management class and slot names■ service model enumeration class names and values

BMC Impact Service Model Editor

■ service model class names (component types) and slot names■ service model management class and slot names■ service model enumeration class names and values


Default presentation name definitions

■ InstallDir\BMC Software\MasterCell\console\lib\lang\kbinfo\kb_deprecated_resource.properties. (contains names for slots that appear on the Deprecated tab of the BMC Impact Explorer Events View)

■ For BMC Impact Portal, the kb_core_resource.properties file is located in the BMC_PORTAL_KIT_HOME/appserver/websdk/tools/jboss/server/all/conf/resources/en_US/smsConsoleServer directory.

■ For BMC Impact Service Model Editor, the kb_core_resource.properties file is located in the BMC_PORTAL_KIT_HOME/appserver/websdk/tools/jboss/server/all/conf/resources/en_US/smsConsoleServer directory.

Extracting the presentation name resource files for BMC Impact Explorer (Java Web Start)

The presentation name resource file for BMC Impact Explorer (Java Web Start) is provided in a .jar file and is digitally signed by BMC Software, Inc. with its digital certificate. To edit the presentation name resource file for BMC Impact Explorer (Java Web Start), you must uncompress the BMC_Portal_Kit_Home/appserver/websdk/tools/jboss/server/all/modules/smsIX.sar /smsIX.war/kbresource.jar into a temporary directory using the following command:

jar xvf kbresource.jar

This command extracts the kb_core_resource.properties and kb_deprecated_resource.properties files.

Default presentation name definitions

The kb_core_resource.properties file maps the internal names of all classes, slots, enumerations, and enumeration values to presentation names for the KB BAROC files that are loaded by default. The default BAROC files loaded are located in one of the following directories:

■ On UNIX: $MCELL_HOME/etc/default/SIM/kb/classes/.load or $MCELL_HOME/etc/default/EM/kb/classes/.load

■ On Windows: %MCELL_HOME%\etc\default\SIM\kb\classes\.load or %MCELL_HOME%\etc\default\EM\kb\classes\.load

NOTE The event slot names shown on the Deprecated tab in the BMC Impact Explorer Events View do not have presentation names by default. This tab shows in parenthesis the recommended internal slot to use in place of the deprecated internal slot.


Creating a new presentation name resource file

If you load a supplied BAROC file that is not loaded by default, you should define presentation names for the internal names. For instructions, see “Defining presentation names” on page 218.

Collector names and action presentation names are also defined in kb_core_resource.properties by default. However, these entries are used by BMC Impact Explorer only and are used primarily for localization.

Creating a new presentation name resource file

If you want to modify the exiting presentation names or create new ones, you can create a new presentation name resource file for any BMC Impact Solutions application by following these steps:

1 Create a file with a .properties extension.

2 Save the file.

3 (BMC Impact Explorer only.) Place the resource file in the InstallDir\BMC Software\MasterCell\console\lib\lang\kbinfo\ directory.

4 (BMC Impact Explorer only.) Add the base name of the resource file to the value of kb_info_resources parameter in the InstallDir\BMC Software\MasterCell\console\etc\ix.properties file using the following format:

5 Follow the procedure, “Creating or modifying presentation name keys” on page 218, to add presentation name entries for your classes and slots to the new .properties file that you have created.

NOTE When you change or replace the original presentation name resource file for BMC Impact Explorer (Java Web Start application), you must provide one that is signed with your organization’s digital certificate. For instructions on digitally signing a new presentation name resource .jar file, see “Digitally signing a .jar file with a digital test certificate” on page 220.

WARNING To preserve the .properties suffix, save as type All Files. Do not save the .properties file as a .txt file. The configuration changes may not be recognized.

kb_info_resources=ResourceFileName,kb_core_resource, kb_deprecated_resource


Presentation name resource files search order

Presentation name resource files search order

Each BMC Impact Solutions application searches the presentation name resource files differently.

Presentation name resource file search order for BMC Impact Explorer

BMC Impact Explorer searches a list of local resource files for presentation name keys. You specify the order in which resource files are searched by defining the search order in the kb_info_resource parameter located in the InstallDir\BMC Software\MasterCell\console\etc\ix.properties file.

Because BMC Impact Explorer searches a set of files in the order you specify, you can override the presentation names in the default file by creating a new .properties file, defining presentation names in this file and listing the new .properties file before the default file in the kb_info_resource parameter. (For instructions on creating a new .properties file, see “Creating a new presentation name resource file” on page 216.)

For example, if you created a new .properties file called my_ix_names.properties and you wanted BMC Impact Explorer to search this file first, you would modify the kb_info_resource parameter to look like this:

Presentation name resource file search order for BMC Impact Portal

The BMC Impact Portal searches for presentation name keys in the files located in the BMC_PORTAL_KIT_HOME/appserver/websdk/tools/jboss/server/all/conf/resources/en_US/smsConsoleServer and BMC_PORTAL_KIT_HOME/appserver/websdk/tools/jboss/server/all/conf/resources/en_US/smsIwc directories.

If you want to add custom classes or extend existing classes to add new attributes, you can add them to the kb_core_resource.properties file located in the BMC_PORTAL_KIT_HOME/appserver/websdk/tools/jboss/server/all/conf/resources/en_US/smsConsoleServer directory. For more information about modifying presentation name keys, see “Defining presentation names” on page 218.

# Specifies the set of files to load for kb specific resources (base names only, comma separated list)kb_info_resources=my_ix_names, kb_core_resource, kb_deprecated_resource


Defining presentation names

Presentation name resource file search order for BMC Impact Service Model Editor

The BMC Impact Service Model Editor looks for presentation name keys in the BMC_PORTAL_KIT_HOME/appserver/websdk/tools/jboss/server/all/conf/resources/en_US/smsConsoleServer/kb_core_resource.properties file.

If you want to add custom classes or extend existing classes to add new attributes, you can add them to the kb_core_resource.properties file. For more information about modifying presentation name keys, see “Defining presentation names” on page 218.

Defining presentation namesPerform these procedures to define user-friendly presentation names for new event classes, component types, slots, enumerations, or policy types.

Creating or modifying presentation name keys

The entries in kb_core_resource.properties have the form

where value is the presentation name. The value can contain space characters.

Table 59 lists the formats for the presentation name key.

NOTE If you customize presentation names in the default kb_core_resource.properties file, you will need to merge your customizations into a newer file when you upgrade.

key=value

Table 60 Presentation name key formats

Object Key format

Class CLASS.InternalClassName

Slot SLOT.InternalClassName.InternalSlotName

Note: Use the class name where the slot is originally defined (the superclass).

Enumeration ENUM.InternalEnumerationName

Enumeration Value ENUMVAL.InternalEnumerationName.InternalValueName


Creating or modifying presentation name keys

To create or modify presentation name keys

1 In a text editor, open either the kb_core_resource.properties file or the new .properties file that you have created. For instructions on creating a new .properties file, see “Creating a new presentation name resource file” on page 216.

2 To define the presentation name for an event class, add a line with the following format to the resource file:

3 To define the presentation name for an event slot, add a line with the following format to the resource file:

4 To define the presentation name for a new policy type, add a line with the following format to the resource file:

5 To define the presentation name for a policy slot, add a line with the following format to the resource file:

6 To define the presentation name for a service model component type, add a line with the following format to the resource file:

7 To define the presentation name for a service model component slot (attribute), add a line with the following format to the resource file:

8 When you have finished adding or modifying the presentation names in the .properties file, save and close the file.

CLASS.eventClassName=eventPresentationName Event

SLOT.eventClassName.slotName=slotPresentationName

CLASS.policyTypeName=policyTypePresentationName Policy

SLOT.policyTypeName.slotName=slotPresentationName

CLASS.BMC_ClassName=ComponentTypeName

SLOT.BMC_ClassName.slotName=slotPresentationName

WARNING To preserve the .properties suffix, save as type All Files. Do not save the .properties file as a .txt file. The configuration changes may not be recognized.


Digitally signing a .jar file with a digital test certificate

9 (BMC Impact Explorer only.) Deploy the revised files to all machines on which BMC Impact Explorer is installed.

10 (BMC Impact Explorer only.) If you are using BMC Impact Explorer (Java Web Start application), digitally sign the .jar file using the instructions in “Digitally signing a .jar file with a digital test certificate” on page 220.

11 Stop and start the BMC Impact Solutions application.

Digitally signing a .jar file with a digital test certificate

If you change or replace the original presentation name resource file for BMC Impact Explorer (Java Web Start application), you must provide one that is signed with your organization’s digital certificate. To accomplish this task, you must have a JDK 1.2 or JDK 1.3 keytool and jarsigner (located in the J2SE SDK bin directory) in your environment path.

1 Create a new key in a new keystore:

A Enter the following command.

keytool -genkey -keystore keystore_filename -alias my_alias

B Enter the requested information for each option.

For example: keytool -genkey -keystore myKeystore -alias myself. This command creates a new key in the keystore file named myKeystore on disk.

2 Create a self-signed test certificate by following these steps:


keytool -selfcert -alias <my_alias> -keystore <keystore_filename>

B Enter the password at the prompt.

Generating the certificate takes a few minutes.

3 Verify that the key and certificate creation were successful by following these steps:

A List the contents of the keystore by entering the following command:

keytool -list -keystore <keystore_filename>


Enabling or disabling presentation names in BMC Impact Explorer tool tips

The resulting listing should appear as follows:

4 Sign the .jar file with the test certificate by following these steps:


jarsigner -keystore keystore_filename jar_filename alias

B Repeat this step for all the .jar files that you have created or changed.

After you have defined presentation names, they are available for automatic download by users who are using the BMC Impact Explorer consoles that are Java Web Start applications.

Enabling or disabling presentation names inBMC Impact Explorer tool tips

A BMC Impact Explorer user can view the internal object names as tool tips when the mouse pointer is over

■ a presentation name in a column header■ a presentation name that labels a slot value (for example, in an Event Details tab) ■ the label of a drop-down list or field that shows a presentation name,■ a slot presentation name in a list box (as in the Edit Slot Order window)■ a class presentation name in the Class Chooser window■ a class presentation name in either of the Administration tab navigation trees

Figure 23 Listing of the contents of a keystore file

Keystore type: jks Keystore provider: SUN Your keystore contains 1 entry:myself, Tue Jan 23 19:29:32 PST 2001, keyEntry,Certificate fingerprint (MD5):C2:E9:BF:F9:D3:DF:4C:8F:3C:5F:22:9E:AF:0B:42:9D

NOTE A self-signed test certificate should only be used for internal testing, because it does not provide any guarantees about the identity of the user and, therefore, cannot be trusted. You can obtain a trust-worthy certificate from a certificate authority, such as VeriSign, use it to sign the .jar file when the application is put into production.


Enabling or disabling presentation names in BMC Impact Explorer tool tips

Tool tips are not shown for

■ classes in the Services tab Of type list■ classes or enumeration values in lists such as event and data lists or event selection

criteria lists

To enable the display of internal names in tool tips, select the Show Internal Names in Tool Tips on the Global tab of the Edit Configuration dialog.

To always display internal names instead of the presentation names in BMC Impact Explorer, set the value of the kb_disable_resources parameter in InstallDir\BMC Software\MasterCell\console\etc\ix.properties to true. There is no way to display presentation names in some BMC Impact Explorer views and internal names in others.


C h a p t e r 9
9 Configuring StateBuilder and gateways
This chapter describes how to configure the StateBuilder and gateways for exporting events and contains the following topics:

Understanding the StateBuilder and gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224StateBuilder configuration file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225statbld return codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225Gateway configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

Exporting events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231Modifying a statbld.conf file to export events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231Modifying a gateway.export file to export events . . . . . . . . . . . . . . . . . . . . . . . . . 232

Configuring tracing for StateBuilder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233


Understanding the StateBuilder and gateways

Understanding the StateBuilder and gateways The StateBuilder is an executable, statbld.exe, located in the MCELL_HOME\bin directory. It records saved states of the cell at regular intervals. When it starts, the cell loads its last saved state (mcdb). All transactions it performs are stored in a transaction file (xact). As soon as the transaction file reaches a certain size, or after a certain period, the StateBuilder is started. It produces a new saved state from the previous file and from the transaction file. When the cell terminates and restarts, any trailing transaction file is first processed by the StateBuilder to produce a new saved state. A history of saved states and corresponding transaction files can be kept. The mcdb and xact files of that history have their timestamp in the file name.

All mcdb and xact files are located in the MCELL_HOME\log\cellName directory. The StateBuilder runs as configured in the cell’s mcell.conf file, which is detailed in “StateBuilder configuration file” on page 225. The configuration of how the StateBuilder itself operates is in the statbld.conf file.

Table 61 on page 224 lists the file naming conventions for the StateBuilder.

There is also a statbld.trace file for the configuration of StateBuilder tracing. For further information, see “Configuring tracing for StateBuilder” on page 233.

The StateBuilder uses the gateway.export file in conjunction with its statbld.conf file to export event data. For more information, see the “StateBuilder configuration file”and “Exporting events” on page 231.

Table 61 StateBuilder file name conventions

File Description

mcdb state file the cell uses at startup

mcdb.0 new state file being generated

mcdb.t saved state history files, where t = timestamp

Timestamp t in the mcdb.t file corresponds to the time when the state is created.

mcdb.lock lock file indicating StateBuilder activity

xact transaction file generated by the cell

xact.n terminated transaction file, where n=1 is the oldest transaction file

xact.t.n terminated transaction history file corresponding to mcdb.t

Timestamp t in the xact.t.n file refers to the mcdb.t file to which the transactions lead.


StateBuilder configuration file

StateBuilder configuration file

The state configuration file, statbld.conf, is located in the MCELL_HOME\etc directory. Table 62 lists the statbld.conf parameters, which use the same syntax as all BMC Impact Solutions configuration files.

statbld return codes

Table 63 lists the return codes for statbld.

Table 62 statbld.conf Parameters

Parameter Description Default value

Export uses Boolean values to specify whether to export data No

ExportConfigFileName sets path to the gateway.export file %H/etc/%N/gateway.export

ExportDiscarded indicates whether discarded events are included in the export file

Discarded events are those that were dropped in the first four rule phases: Refine, Filter, Regulate, and New (Update).

No

ExportTriggerArguments sets the arguments to be passed to the executable serving as the export trigger program

Value is interpreted as a sequence of space-separated arguments, so spaces within each argument are not allowed.

blank; no arguments

ExportTriggerProgram sets the program to execute after exporting data

The value is interpreted as a path. See the mcell.conf file for special syntax for a path.

blank

StateHistoryCount sets the number of state files to retain in the history

Each time a new saved state is produced, the oldest state is removed.

3

Table 63 statbld return codes (part 1 of 2)

Return code Description

1 failed to build new mcdb

2 failed to update history files

10 early initialization failure

37 process handling module initialization failure

47 StateBuilder specific file access initialization failure


Gateway configuration


This section discusses general message formatting that applies both to StateBuilder export and to gateways.

Gateway specific message formats are described in a gateway configuration file. The location of this file for gateway of a particular type is determined from the GwTypeConfigFileName parameter of the cell. Its default value is %H/etc/gateway.Type where Type represents the type of gateway.

Example default parameter values for TEC and jServer gateways:

■ GwTECConfigFileName=%H/etc/gateway.TECwhich means: $MCELL_HOME/etc/gateway.TEC

■ GwjServerConfigFileName=%H/etc/gateway.jServerwhich means: $MCELL_HOME/etc/gateway.jServer

A gateway configuration file contains parameter settings in the form of parameter=setting.

Parameters can be specified differently for new events and for event modifications. The parameter name must be suffixed with

■ .new for new events■ .mod for event modifications

Without a suffix, the setting is assumed to be on both categories. Both the contents of a message and its format are specified using parameters.

Gateway predefined variables

Table 64 lists the parameters that can refer to predefined variables.

57 transaction file handling initialization failure

67 failed to load KB classes

77 server directory load failure

87 internal table initialization failure

97 detected running StateBuilder (mcdb.lock)

Table 63 statbld return codes (part 2 of 2)

Return code Description



Gateway text parameters

Text parameter values consist of literal text, possibly mixed with references to variables and with escape sequences, as shown in Table 65.

Table 64 Gateway configuration parameter predefined variables

Variable Description

$CLASS class name

$CONTEXT context name:■ Permanent—event permanently in DB (until out of date)■ Processed—discarded by rule processing■ Regulated—discarded by regulation■ Filtered—discarded by filter■ Refined—discarded by refine■ Received—discarded immediately

$DATE date stamp

$TIME time stamp

$MODNMS names of modified slots (empty for “new”)

$GHANDLE event ID in gateway

$CNAME cell name of cell connecting to gateway

$CHANDLE event ID in cell

$VALUE slot value of slot slot

$NAME selected slot name (only for body parameter)

$VALUE selected slot value (only for body parameter)

$MODS all modified slots (empty for “new”)

$ALL all slots (only for slots parameter)

$ALL cls all slots, but limited to class cls(only for slots parameter)

$MAP.map val mapped value of val using map

val can be a literal or a variable reference

Table 65 Gateway Configuration Parameter Text Values

Character Name

\\ backslash

\s space

\n new line

\r carriage return

\t tab

\0ddd character code in octal (0, 1, 2, or 3 digits d)



References to variables that are not followed by punctuation or space characters must be enclosed in curly brackets ( { } ). For example, $NAMEabc is invalid; ${NAME}abc is correct. Non-printable characters and hard spaces must be expressed with an escape sequence. String values for parameters are considered from the first non-white space character up to the first (non-escaped) white space character.

Table 66 on page 228 lists the gateway.export file parameters.

Table 66 gateway.export file parameters (part 1 of 2)


Communication parameters

protocol sets the communication protocol. Both categories, new event and modification, use the same protocol. The last one specified is used. The default value is MCELL.

Contents parameters

cond sets the condition for a slot to be included in the $ALL variable. Use always to always include the slot. Use propagate to include the slot if its value is different from the default value for the slot and it is able to be parsed. The default value is propagate for new, and always for mod.

drop lists slots that must be dropped from the $ALL and $MODS variable. List of comma separated slot names. Only real slot names can be used. The default value is [], so no slot is dropped.

add lists additional new slot definitions. List of comma separated settings in the format slotname=slotvalue. slotname represents the name for the new defined slot and slotvalue defines the value of the new slot. The default value is [], so no slot is added.

slots sets and orders the slot names to be included. Non-base class slots must be prefixed with ClassName: . The list can also contain variable references to include those values among regular slots.

The default value is [], so no slots are exported.

modify lists slots whose modifications result in a message. Modifications of slots that are not included in this list are ignored. The default value is [], which means that every slot modification is included.

map.name Defines the map table with the name name

List of comma separated settings in the format original_value=converted_value

original_value represents a value that has to be replaced and converted_value is the replacement value. Both values must be literal values.



Gateway configuration value mapping

For some destinations, it is necessary to map values from a cell domain to a gateway domain. You can implement value mapping by defining a map table and using the value mapping function.

You define a value map table using the parameter map suffixed with the name of the map table.

map.name=[original_value=converted value,original_value=converted value, etc.]

name represents the name you give the map table; original_value is the value to be replaced and converted_value is the replacement value.

You convert a value applying a map table, by using the variable $MAP.

$MAP.name(value)

If the specified value cannot be found in the map table, it is not replaced.

Format parameters

init text or value to be printed at the beginning of each export message. The default value is blank. At least one of the init, body, or term parameters must be specified to populate the export file.

body text or value to be printed for every slot to be included; can use the variable, $NAME (name of the slot) and $VALUE (value of the slot). The default value is blank. At least one of the init, body, or term parameters must be specified to populate the export file.

term text or value to be printed at the end of each event. The default value is blank. At least one of the init, body, or term parameters must be specified to populate the export file.

separator sets the separator character or string to use between slot values. The default value is nothing.

quotable sets the characters leading to quotation when appearing in a slot value. If the parameter value is empty, slot values are never quoted. The default value is standard MRL quotation rules.

openquote sets the opening quotation character to use for values that must be quoted. The default value is a single quote (‘).

closequote sets the closing quotation character to use for values that must be quoted. The default value is a single quote (‘).

escapequote determines how to escape a quotation mark inside a quoted value. The default value is a single quote (‘).

Table 66 gateway.export file parameters (part 2 of 2)




For example: You want to modify the value of the enumeration SEVERITY when it is sent to a certain gateway. Value WARNING will be replaced with LOW, and value CRITICAL with URGENT.

To do this, create a map table to define the required mapping:

All other values of SEVERITY are passed unchanged.

To actually replace the values of slot severity, the slot has to be dropped and a new slot, with the same name, has to be added, mapping the value:

Example of printed events

To print events in BAROC format, set the parameters as shown in Figure 24.

The BAROC format produces output similar to the example shown in Figure 25.

The slots are displayed, one per line, indented by a tab (\t). For every slot, the slot name and value are printed, separated by an equals sign (=) and terminated with semicolon and a new line (\n). To terminate, END is printed on a line at the end of the data.

EXAMPLE map.GW1severity=[WARNING=LOW,CRITICAL=URGENT]

EXAMPLE drop=[severity]add=[severity=$MAP.GW1severity($VALUE(severity))]

Figure 24 Parameters used to print event in BAROC format

init=$CLASS;\nbody=\t$NAME=$VALUE;\nterm=END\n

Figure 25 Example of printed events

MC_CELL_TICK;server_handle=0;date_reception=1010183001;event_handle=2;source=;sub_source=;...END


Exporting events

In the example shown in Figure 26, the first two lines configure the export file so that it exports new events and modified events differently. Specifically, slots.new=[$ALL] exports all slots of new events to the database and slots.mod=[event_handle,$NAME,$VALUE] exports event_handle, slot name, and value of events that are modified to the export file.

Exporting eventsEvents received in the cell can be exported to a flat file that resides on the same computer as the cell. The exported events then can be used in third-party products for archiving and data mining. Also, they can be exported to a program on another computer by using the BMC Impact Solutions Gateway.

To export events, you configure the statbld.conf and gateway.export files.

Modifying a statbld.conf file to export events

To modify the statbld.conf file to generate an export file, set Export=Yes and remove the # sign that precedes it. If you retain the default value ExportDiscarded=No, events that were discarded in the first four rule phases—Refine, Filter, Regulate, and New/Update—are not included in the export file. Set ExportDiscarded=Yes to include these events in the export file.

Use the ExportConfigFileName parameter in the statbld.conf file to set the location of the export configuration file. By default, the location is the gateway.export file in the cell-specific subdirectory of MCELL_HOME\etc.

When the data files are generated, the cell can trigger a program, which can be used to import the data automatically into another product, such as a database. This can be controlled using the ExportTriggerArguments and the ExportTriggerProgram parameters, which are set also in the statbld.conf file. The arguments specified in ExportTriggerArguments are passed as arguments to the program, if any. These are always followed by the paths to the new event and modification export files, in that order.

Figure 26 Command to configure the export file

slots.new=[$ALL]slots.mod=[event_handle, $NAME, $VALUE]


Modifying a gateway.export file to export events

The export process produces two separate files that are located in the MCELL_HOME\log\cellName directory. These two files are exp.TimeStamp.new, which contains all new events since the previous export, and exp.TimeStamp.mod, which contains all modifications of events after they have first passed through all rule phases. The TimeStamp part of the file name corresponds to the timestamp part used in the mcdb and xact file names and enables archiving of multiple export files.

Because the primary goal of exporting events is to import the data into another format for other use, BMC Software recommends that you remove the export files as soon as their contents have been archived. The easiest way to do this is to have them removed by the program that is triggered at the end of the export.

Modifying a gateway.export file to export events

In a gateway.export file, you can configure what data goes into the export file and how that data is formatted. A default gateway.export file exists in the MCELL_HOME\etc directory. Copy the gateway.export file to the MCELL_HOME\etc\cellName directory and edit the copy.

By default, the gateway.export file has the format shown in Figure 27.

Using the default values in the gateway.export file for new events produces output in the format shown in Figure 28.

Figure 27 gateway.export file format

# Export Gateway Configuration#cond=alwaysslots.new=[$ALL]slots.mod=[$MODS]body=$VALUEterm=\nseparator=,quotable=,"openquote="closequote="escapequote="

Figure 28 gateway.explore file output for new events

0,1010183001,1,,,,,,,,OPEN,,[admin],1,OK,,,0,0,0,0,mc.exp.000000001,0,['exp:1'],[],[],[],[],[],0,[],exp,10.0.9.10:1981,28698

0,1010183001,2,,,,,,,,OPEN,,[admin],1,OK,,,0,0,0,0,mc.exp.000000002,0,['exp:2'],[],[],[],[],[],0,[],exp,10.0.9.10:1981,600


Configuring tracing for StateBuilder

Using the default values in the gateway.export file for modified events produces output in the format shown in Figure 29.

Configuring tracing for StateBuilderYou configure StateBuilder tracing in the MCELL_HOME\etc\statbld.trace file. The statbld.trace file uses the same parameters as the mcell.trace configuration file. For details on the cell tracing configuration, see the BMC Impact Solutions: Event Monitoring Operator’s Guide.

Figure 29 gateway.explore file output for modified events

mc.exp.000000001exp10.0.9.10:198128698mc.exp.000000002exp10.0.9.10:1981600ACK1010183062mc.exp.000000003exp10.0.9.10:198128698


Configuring tracing for StateBuilder


2Part

Part 2Event management administration

This part presents the following topics:

Chapter 10Event management overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Chapter 11Working with the Dynamic Data Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

Chapter 12Implementing event management policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

Chapter 13Creating and implementing user-defined policies . . . . . . . . . . . . . . . . . . . . . . . . . . 351

Chapter 14Building event groups and image views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359

Part 2 Event management administration 235

C h a p t e r 10
10 Event management overview
BMC Event Manager allows you to detect IT-related problems and to plan the fastest resolution before there is an impact on critical IT services.


Event management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237Event collection sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238Event management in BMC Impact Explorer console . . . . . . . . . . . . . . . . . . . . . . 239Event flow for service impact management and event management . . . . . . . . . 241

BMC Impact Explorer Administration View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242Event management policy definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243Dynamic data definition using the Dynamic Data Editor. . . . . . . . . . . . . . . . . . . 243BMC Impact Manager cell management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Event managementEvent management is the collection, correlation, enrichment, and manipulation of events across the enterprise to enable IT operations staff to focus the proper resources on the most critical events. Event management is required to implement service impact management because events are associated with service model components and contribute to the computation of status of those components.

The BMC Event Manager solution formulate

■ collects events from IT components and other event management systems through its event adapters and other BMC Software application-specific integration products

■ processes events to enable faster problem detection and resolution in BMC Impact Manager cells


Event collection sources

■ automates management and corrective actions in the BMC Impact Explorer console

■ displays events in logical groups and graphical image views in the BMC Impact Explorer console

■ integrates with help desk and notification applications

Event collection sources

BMC Impact Manager collects source event data through event adapters or collects existing events from other event management products through various integration products. Event adapters and integrations prepare the source event data and convert the events into Basic Recorder of Objects in C (BAROC) language format for processing by the BMC Impact Manager event processor.

Using BMC Impact Event Adapters or BMC Impact Event Log Adapter for Windows, source event data can be collected from

■ operating system and application log files ■ SNMP type 1 and type 2 traps■ a Telnet, UDP, or TCP data source

For more information on event adapters, see the BMC Impact Solutions: Event Adapters Installation and Configuration.

Using the out-of-the-box integrations with PATROL or PATROL Enterprise Manager, BMC Impact Manager can accept events (or alerts) that have already been processed by those systems.

With the BMC Impact Integration Developer’s Kit, you can develop a custom solution to obtain source event data from an IT application or infrastructure monitoring solution.


Event management in BMC Impact Explorer console


BMC Impact Explorer is the console used by IT operations staff to manage and monitor events. BMC Impact Explorer consists of the following views:

Events view in BMC Impact Explorer

In the Events view, event instances are displayed in an event list. From the event list, IT operators can perform event operations (such as closing or escalating an event), view event relationships (such as correlation), perform actions on an event, or view the business services related to an event.

The Events view contains the following hierarchical navigation trees for viewing events and their severity:

■ event collectors—an event list, a meaningful grouping of events or events grouped by their relationships

■ MetaCollectors—a grouping of events from several different event lists (collectors), showing their combined status

■ event groups—a hierarchy of event lists

■ image views—a graphical representation of the collectors in an event group

For more information on event groupings, see Chapter 10, “Event management overview.”

Table 67 BMC Impact Explorer Views

View Description

Events Operators use the Events view to monitor and manage events received from IT components.

Administration Service administrators and service managers use this view to define event management policies and to define dynamic data instances for use in event management rules.

Services IT operations staff and service managers monitor service models in this view.



Administration view in BMC Impact Explorer

The Administration view provides interfaces for editing

■ event management policies

In the Event Management Policies tab, service administrators and service managers can define how an event should be processed by the cell after it has been received.

■ dynamic data (in the Dynamic Data Editor)

A service administrator or service manager uses the Dynamic Data Editor to define data classes for use in event management rules or service models. To define the data instances, the service administrator or service manager must first define a data class. A service administrator or service manager can also use the Dynamic Data Editor to define alias formulas and grant access to components and relationships.

In addition, a service administrator or service manager can also perform commands to stop, pause, restart, or reconfigure a cell from the Administration view.

Services view in BMC Impact Explorer

Service managers can view service models that represent a company’s business services in the BMC Impact Explorer Services view. The service model components are organized into hierarchical relationships that can then be navigated by operators and service managers from the Services view.

In the Services view, the service manager or IT operations staff can determine whether a service model component consumes the services of another service model component (consumer) or whether it provides service to another component (provider). The status of the provider component has an impact on the status of the consumer component by means of its impact relationship.

Service managers and IT operations staff can determine the root cause of a problem or the impact that a service model component has on a business service in the Related Components tab of the Services view.

For more information, see BMC Impact Solutions: Event Monitoring and BMC Impact Solutions: Service Monitoring.


Event flow for service impact management and event management

Event flow for service impact management and event management

Service impact management begins with the organization analyzing how various IT assets form the infrastructure that delivers a critical business service. First, the organization decomposes its key business processes and identifies the IT services that support those processes. Next, the service manager catalogs the IT assets or obtains the information from a configuration or asset management system. With this information gathered, the service manager can design a service model and the service model components, or data classes, that represent a business process, its users, and the related IT services.

Service model development in BSM

In the BMC Impact Service Model Editor component of the BMC Impact Portal, a service manager defines the service model components that symbolize the real IT assets that underlie the delivery of services, such as applications, servers, and databases; and the logical assets, such as user groups, business processes, and geographic locations. The default BMC Atrium CMDB Common Data Model (CDM) provides the default component types used by the BMC Impact Service Model Editor.

The service manager defines the interdependencies of these components and maps the event flow to the components into the model. A service model component can consume the services of another component (consumer relationship), provide services to another component (provider relationship), or both.

If an appropriate subclass does not exist or is too generic, a service manager or service administrator can extend the CMDB class hierarchy by adding a new subclass definition. Or, you can extend an existing class definition by adding one or more attributes to store component-specific information. You must make these changes to the CMDB Common Data Model (CDM) by using the BMC CMDB Class Manager console. For more information, see the BMC Atrium CMDB Installation and Configuration Guide.

All service model component instances and related data in the service model are stored and managed in the BMC Atrium CMDB. The service manager publishes the service model to the associated BMC Impact Manager cells, which use it in service impact management.

Service impact management in BSM

Each BMC Impact Manager cell running a SIM Knowledge Base processes the events from the various contributing IT assets, associates the events with the service model components that represent those assets, and analyzes the relationships among the components to determine the consolidated status of services to provide real-time, adaptive service management information.


BMC Impact Explorer Administration View

With the service model published to BMC Impact Manager cells, when a business service experiences problems, service managers and IT operations staff, monitoring the BMC Impact Portal or the BMC Impact Explorer consoles, can determine the cause of a problem or the impact that a service model component has on a business service.

Figure 30 on page 242 shows the service impact and event management process flow.

Figure 30 Service impact and event management process flow

BMC Impact Explorer Administration ViewAdministrators use the Administration View interfaces to

■ define event management policies with the Event Management Policies Editor■ define dynamic data with the Dynamic Data Editor■ stop, pause, restart, or reconfigure a cell


Event management policy definition

Event management policy definition

An event management policy is one of several generic rule types that perform actions against events that meet selection criteria specified in an associated event selector. An event management policy selects the events that you want to process, defines the processes needed to manage those events, and schedules when the events are processed.

Event management policies can be created from a pre-defined policy type in the Administration View or the Event Management Policy Editor.

A policy consists of

■ an event selectorIn the Event Selection Criteria Editor, the administrator defines the filtering criteria used in selecting the events to be processed.

■ a scheduleUsing the Time Frame Editor, the administrator defines the processing schedule for the selected events.

■ an event management policy typeFor a list of predefined event management policy types, see Table 69 on page 262.

You can also create new user-defined policy types to add new event processing actions. See Chapter 13, “Creating and implementing user-defined policies,” for information about creating user-defined policy types.

Dynamic data definition using the Dynamic Data Editor

Dynamic data is contextual reference data that is stored in the event repository and updated whenever the context changes while the cell is running. Its function is similar to a global variable. An administrator uses the Dynamic Data Editor to define data class instances for use in event management rules or service models. To define the data instances, the administrator must first define a data class. See Chapter 11, “Working with the Dynamic Data Editor” and BMC Impact Solutions: Knowledge Base Development Reference Guide for information about dynamic data.

BMC Impact Manager cell management

For information about managing cells, see Chapter 2, “Managing BMC Impact Manager cells.”.


BMC Impact Manager cell management


C h a p t e r 11
11 Working with the Dynamic Data Editor
This chapter describes the Dynamic Data Editor. It contains the following topics:

About data classes and dynamic data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246Navigating the Dynamic Data Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Navigation pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247Toolbar functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

Filtering and sorting the Data List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248Filtering slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248Sorting data fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

Working with data instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252Extended Details tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253Internals tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253Data instance context menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253Adding a new data instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253Editing slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255Exporting data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256


About data classes and dynamic data

About data classes and dynamic dataA data class is the type of class used to define dynamic data. Dynamic data function as contextual variables that can provide data values to rules and policies during event processing. By using dynamic data, you can create generic event management rules and policies that apply broadly. Using dynamic data greatly simplifies the creation and maintenance of the event management rules.

For example, without using dynamic data, if you want to create a rule that changes the severity of an event based on the host name of a device, you must create a rule for each host name. Using dynamic data, you can define the host names and corresponding severity as data instances and reference them from one generic rule, rather than writing one rule for each possible host name. To define a data instance, the service administrator or service manager must first define a new data class.

As new hosts are added to the environment, the service administrator or service manager adds new data instances dynamically through the BMC Impact Explorer Administration View, using the CLI or an API, or by means the rules themselves. Event management rules do not need to be recompiled to use new data instances.

Dynamic data definition using the Dynamic Data Editor

Dynamic data is contextual reference data that is stored in the event repository and updated whenever the context changes while the cell is running. Its function is similar to a global variable. An administrator uses the Dynamic Data Editor to define data class instances for use in event management rules or service models. To define the data instances, the administrator must first define a data class. See Chapter 11, “Working with the Dynamic Data Editor” and BMC Impact Solutions: Knowledge Base Development Reference Guide for information about dynamic data.

Navigating the Dynamic Data EditorYou can use the Dynamic Data Editor to add a dynamic data instance to use as a contextual variable in MRL rules and policies (“Adding a new data instance” on page 253).

This section discusses the basics of how to navigate the Dynamic Data Editor.


Navigation pane

Navigation pane

In the Dynamic Data Editor tab on the Administration view you can view the data classes for a cell in a hierarchical tree, as illustrated in Figure 31.

Figure 31 Dynamic Data Editor Navigation Pane

Table 68 lists the parts on the Administration Tab Navigation pane.

Table 68 Administration tab navigation pane (part 1 of 2)

# Name Description

1 Dynamic Data Editor tab identifies the dynamic data editor

2 cell group icon identifies a cell group

3 cell icon identifies a cell

4 DATA class root class to which all data classes belong

1

23

45

6


Toolbar functions

Toolbar functions

Figure 32 describes the toolbar buttons available in the Dynamic Data Editor.

Figure 32 Dynamic Data Editor toolbar

Filtering and sorting the Data ListThe Data List of the Administration view in BMC Impact Explorer provides GUI elements to assist you in working with a cell’s dynamic data. From the Data List, you can

■ filter slots■ sort data

Filtering slots

The Slot Quick Filter allows you to filter the displayed data list according to specified slot criteria.

5 DATA subclass data class defined as a subclass of the root class DATA

Data subclasses comprise the dynamic data tables in the current cell.

6 view selection tabs access to the events, services, or administration portions of the console

Table 68 Administration tab navigation pane (part 2 of 2)

# Name Description

Hide Navigation

Hide Data List

Hide Details

Refresh Current Data

List

Add data instances

Copy and add data instances

Update data instance

Delete data instances

Copy data instances

Paste data instances

Export data instances

Print data instances


Filtering slots

1 Click on the Slot Quick Filter button or the down arrow to its right to display the Slot Quick Filter dialog box, shown in Figure 33, in which you set the filter criteria.

Figure 33 Slot Quick Filter dialog box

2 From the Slot list, select the slot name.

3 From the Operator list, select the specific operator with which the filter acts.

4 In the Value box, enter the value with which you want to filter the Data List.

5 Click OK.

The filter you specified appears in place of the Slot Quick Filter button and the data instances that meet the criteria are displayed in the Data List, as shown in Figure 34.

For illustration purposes, the Data List is filtered by Slot name equals Brussels.


Filtering slots

Figure 34 Unfiltered data list

To toggle the quick filter on and off, click on the Slot Quick Filter button or on the filter specifications currently displayed in place of the icon.

Unfiltered Data List:


Sorting data fields

Sorting data fields

You can sort fields in the Data List using two methods: a multiple column sort order or single-click on a column to sort immediately by that column.

To sort using multiple column sorting

Designating multiple columns for a sorting order is useful in resolving sort order conflicts in the data list. Multiple column sorting functions as the following illustrates. Set a multiple column sort order for a maximum of three columns with these steps.

1 Right-click on a column head to display the Slot Order Indicator.

2 Select the order position desired for that column.

The Slot Order Indicator permits you to select a column as having no influence on the sort order, or as first, second or third in the order.

3 Right-click next on the column you want to include in the sort order.

4 Select the order position desired for that column.

5 Repeat if you want to establish a third column in the sort order.

An alternative method of multiple-column sorting is to press the Ctrl key and single-click on a header to add that column as the next column in the sort order. That is, pressing Ctrl and single-clicking on a column sets it as the first in the sort order, pressing Ctrl and single-clicking on the next column sets it as the second in the sort order, and the third column is set as the third in the sort order by again pressing the Ctrl key and single-clicking on the column header.

Currently only three columns can be included in the sort order. Pressing the Ctrl key and single-clicking on a fourth column will designate it as third in the sort order in place of the column previously designated as third. Also, pressing the Ctrl key and single-clicking on a column that is part of a sort order will remove it from the sort order. The remaining columns in the designated sort order will reposition in the sort

NOTE When you select the first column to include in your sort order the only options available in the Slot Order Indicator are None and First. After you designate a column as first in the sort order, the option Second is available in the Slot Order Indicator when you right-click on the second column. The Third option is available when you have designated a column as Second in the sort order.


Working with data instances

order to replace the one that has been removed. For example, if you press the Ctrl key and single-click on the column previously designated as first in the sort order, it will be removed from the order and the two remaining will move from second to first and from third to second in the new sort order.

Remember the following facts about sorting:

■ Only if there is a sorting conflict in the First sort column will the sorting be resolved by use of the Second sort column.

■ The sorting will extend to the Third sort column only if there is a sorting conflict in the Second sort column.

■ Establishing a multiple column sort simply ensures that any sorting conflicts that may arise can be resolved to the third column level.

If you have established a multiple sort order in the Data List, clicking on one of the sort order columns toggles that column’s display between ascending and descending order, as indicated by the small arrow next to the sort order number in the column head.

To sort using single-click sorting

Sorting also can be done by single-clicking on the column you want to use as the basis of your Data List sort. Even if a multiple sort order has been established, as in the preceding section, you can click on any column that is not part of the designated multiple sort order to reset sorting. This action establishes single column sorting and the column on which you clicked is designated as the First, and only, column in the new sort order.

Working with data instancesFrom the Administration view, you can edit and manipulate a cell’s dynamic data instances. All classes that are visible in the Administration View are subclasses of the base data class DATA and MC_SM_DATA. Subclasses of MC_SM_DATA are shown in the navigation pane, but data instances are not shown for these classes. Each cell’s data class definitions reside in its Knowledge Base.

To define data instances in the Administration view for a custom data class, you must first define that data class in the KB of the cell. For further information, see the BMC Impact Solutions: Knowledge Base Development Reference Guide.


Extended Details tab

Extended Details tab

The Extended Details tab displays extended details of a selected data instance.

Internals tab

The Internals tab displays the internal data as defined on the base DATA class.

Data instance context menu

The Data List of the Administration view in BMC Impact Explorer provides GUI elements to assist you in working with a cell’s dynamic data. Right-click on a data instance in this pane to display the pop-up context menu. Discussion here focuses on the New, New Copy, Edit, and Delete pop-up context menu options.

Adding a new data instance

This section describes how to create a new data instance.

To create a new data instance

1 Right-click on a data instance.

2 Select the New pop-up menu option to display the New tab in the Details pane of the Administration View.

The fields on the New tab are the slots for which data information can be entered for this new data instance. The fields with a white background can be edited; fields with an asterisk are required.

The unique data identifier slot (mc_udid) has a white background and is empty.

NOTE The mc_udid slot information is assigned by the cell and BMC Software recommends that you allow the cell to assign this value rather than entering one of your own.


Adding a new data instance

The cell assigns a valid value for this slot. The slot fields that are dimmed will be completed automatically by the cell. The only exception to this is the list associated with the Type field that permits you to select from specified options, as shown in Figure 35.

Figure 35 Type field list

3 Click OK to complete the new data instance and close the New tab.

The success or failure of your attempt to create a new data instance will be reflected in the message bar at the bottom of BMC Impact Explorer window. Figure 36 illustrates a notification of a failed attempt to create a new data instance.

Figure 36 Message bar

To create a new data instance with the New Copy option

Unlike the New menu option, the New Copy option requires you to right-click on a selected data instance in the Data List of the Administration View to display a New tab in the Details pane of the Administration View in BMC Impact Explorer window, as shown in Figure 37. Note that certain of the editable fields contain slot information that is copied from the selected data instance in the Data List.


Editing slots

Figure 37 New data instance created with the New Copy option

The New Copy menu option provides the same selection in the type field list as the New menu option, as shown in Figure 38.

Figure 38 Type field List

When you have entered or edited the appropriate slot information, click OK to create the new data instance and close the New tab. The success or failure of your attempt to create a new data instance is reflected in the message bar of BMC Impact Explorer window.

Editing slots

A class definition consists of one or more slots. Each slot has a data type and can have specific attributes called facets that can control the values that the slot can have or control aspects of a class instance’s processing. A class that is a subclass to another class inherits all the slots of the parent class.

The Edit pop-up menu option allows you to update the selected data instance of the current data list in the Data List display pane.


Exporting data

1 Select and right-click on the data instance to display the Edit tab in the Details pane of BMC Impact Explorer window.

The Edit tab contains the slot value information of the selected data instance. Fields that can be changed have a white background.

2 To save the edited information and close the Edit tab, click OK.

Exporting data

From the Data List in the Administration view, you can export a data instance as a file with a specified file name, in a format selected from a list, and containing all or only the visible slot information available for the data instance. Multiple data instances can be exported to the same file at the same time. Do this by selecting all the data instances your want included to begin the export process.

1 Select a data instance and select the File => Export menu option or click on the Export toolbar button to display the Export Policies dialog box, as shown in Figure 39.

Figure 39 Export Data dialog box

2 In the Format list, select the format for the export file, as shown in Figure 40.

Figure 40 Export Data dialog box—Selecting the data format

3 With the Visible Slots and All Slots option buttons, select whether you want to include only the visible slots or all slots in the file.

If you select All Slots, the Filter for Importing check box is available.


Exporting data

4 In the To File box, accept the default or specify the file name and location for the export file.

5 Click OK to create the export file and close the Export Data dialog box.

For illustration purposes, in Figure 41, the export file mcdata.csv containing information on all the slots for the selected data instance is created in C:\Documents and Settings\zane\My Documents.

Figure 41 Contents of mcdata.csv

Figure 42 illustrates an export file containing four data instances.

Figure 42 Export file containing four data instances


Exporting data


C h a p t e r 12
12 Implementing event management policies
This chapter describes event management policy types, event management policies and their components, and explains how to implement them. This chapter presents the following topics:

What is an event management policy? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260How an event management policy differs from a rule . . . . . . . . . . . . . . . . . . . . . 261When to use an event management policy rather than a rule . . . . . . . . . . . . . . . 261Event management policy types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261How standard event management policies differ from dynamic data enrichment

policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263Out-of-the-box event management policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264How event management policies work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

Event management policy workflow overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 265Event selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266Event selector groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266Event selection criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267Timeframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268Evaluation order of event policy types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269Compiling event policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

How dynamic data enrichment event management policies work . . . . . . . . . . . . . . 270External enrichment data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

How to create a new local timeframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274How to add a notification service (notification policies only). . . . . . . . . . . . . . . . . . . 276How to create and edit a dynamic data enrichment source file . . . . . . . . . . . . . . . . . 277

Using the sample PATROL messaging text translation dynamic data enrichment source file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

How to create an event selector and specify event selection criteria . . . . . . . . . . . . . 281Creating new standard event management policies. . . . . . . . . . . . . . . . . . . . . . . . . . . 285

Creating a new standard blackout policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285Creating a new closure policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288Creating a new correlation policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291Creating a new enrichment policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294Creating a new escalation policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297


What is an event management policy?

Creating a new notification policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302Creating a new propagation policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306Creating a new recurrence policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308Creating a new suppression policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311Creating a new threshold policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313Creating a new timeout policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

Enabling and disabling out-of-the-box standard event management policies . . . . . 320Creating a new dynamic data enrichment event management policy . . . . . . . . . . . . 321Enabling out-of-the-box dynamic data enrichment event management policies . . . 332

Enabling a dynamic data enrichment blackout policy . . . . . . . . . . . . . . . . . . . . . . 333Enabling a dynamic data enrichment location policy . . . . . . . . . . . . . . . . . . . . . . 336Enabling a dynamic data enrichment service contact policy . . . . . . . . . . . . . . . . 340Enabling a dynamic enrichment PATROL message text translation policy . . . . 343

Importing dynamic data enrichment source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347Verifying that the policy is running. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348Editing event selection criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348Deleting an event selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

What is an event management policy?An event management policy is one of several generic rule types that perform actions against events that meet selection criteria specified in an associated event selector. An event management policy selects the events that you want to process, defines the processes needed to manage those events, and schedules when the events are processed.

Event management policies can be created from a pre-defined policy type in the Administration View or the Event Management Policy Editor.

A policy consists of

■ an event selectorIn the Event Selection Criteria Editor, the administrator defines the filtering criteria used in selecting the events to be processed.

■ a scheduleUsing the Time Frame Editor, the administrator defines the processing schedule for the selected events.

■ an event management policy typeFor a list of predefined event management policy types, see Table 69 on page 262.

You can also create new user-defined policy types to add new event processing actions. See Chapter 13, “Creating and implementing user-defined policies,” for information about creating user-defined policy types.


How an event management policy differs from a rule

How an event management policy differs from a rule

Like a rule, an event management policy processes events and performs event management.

However, unlike rules, an event management policy

■ is easily defined interactively through the BMC Impact Explorer Administrator interface of the BMC Impact Explorer console rather than being manually written in MRL.

■ uses an event selector by which you specify the criteria used to select events for processing by the policy. The event selector allows you to specify a number of events that meet selection criteria. This gives the event policy greater flexibility than a rule.

■ does not require compilation because it is implemented using predefined data classes and precompiled rules.

When to use an event management policy rather than a rule

Use a policy if there is a fairly simple, routine action that you would like to apply to many events.

If some complex event manipulation is required that is specific to a small subset of events, a rule written in MRL may be more appropriate

In some cases, a rule can provide better performance than its event management policy equivalent. If an event management policy gives problematic performance, substituting an equivalent rule might rectify the performance issue.

Event management policy types

Event management policy types provide a base policy definition that allows you to quickly create certain types of policies. Policy types allow you to quickly set up routine event management processes.

Table 69 describes the standard event management policy types.


Event management policy types

Table 69 Standard event management policy types

Policy name Definition

Blackout specifies which events the receiving cell should classify as unimportant and process no further but log for reporting purposes

A blackout event management policy might specify that the cell ignore events generated from a successful logon to an internal system.

Closure closes a specified event in response to receipt of a separate event

Correlation relates one or more cause events to an effect event, and can close the effect event

The cell maintains the association between these cause-and-effect events.

Enrichment adds values for specific event slots if those slots are empty as received from the event source

An enrichment event management policy can also reformat slots or normalize slot values.

Escalation raises or lowers the priority level of an event after a specified period of time

A specified number of event recurrences can also trigger escalation of an event. For example, if the abnormally high temperature of a storage device goes unchecked for 10 minutes or if a cell receives more than five high-temperature warning events in 25 minutes, an escalation event management policy might increase the priority level of the event to critical.

Notification sends a request to an external service to notify a user or group of users of the event

A notification event management policy might notify a system administrator by means of a pager about the imminent unavailability of mission-critical piece of storage hardware.

Propagation forwards events to other cells or to integrations to other products

Recurrence combines duplicate events into one event that maintains a counter of the number of duplicates

Suppression specifies which events that the receiving cell should delete

Unlike a blackout event management policy, the suppression event management policy maintains no record of the deleted event.

Threshold specifies a minimum number of duplicate events that must occur within a specific period of time before the cell accepts the event

For events allowed to pass through to the cell, the event severity can be escalated or de-escalated a relative number of levels or set to a specific level. If the event occurrence rate falls below a specified level, the cell can take action against the event, such as changing the event to closed or acknowledged status.

Timeout changes an event status to closed after a specified period of time elapses


How standard event management policies differ from dynamic data enrichment policies

It is also possible to define custom policy types that allow you to do specialized event processing not supported by the out-of-the-box policy types.

For more information about creating user-defined policy types, see Chapter 13, “Creating and implementing user-defined policies” on page 351.

How standard event management policies differ from dynamic data enrichment policies

A standard event management policy requires you to use the BMC Impact Explorer to input data into a policy. This type of policy works well if you only want to apply the policy to a small number of events or hosts. Examples of standard event management policies that are provided out-of-the-box with the product include:

■ PATROL_Portal_Closure■ Apache_Login_Failed_Repeats■ Blackout_Suppression

A dynamic data enrichment policy provides additional context to an event by extracting data from an external source and appending it to the event so it is accessible to IT operations. For example, it may be useful for IT operators to know the location of a particular piece of equipment. This type of information is not normally included in a standard technical event; however, you can use dynamic data enrichment to add this information to the event by accessing data stored external to the product (for example, an asset store). If you want to apply a policy to a large number of hosts or events, you should use a dynamic data enrichment policy.

Examples dynamic data enrichment policies that are provided out-of-the-box with the product include:

■ Location_Enrichment■ Service_Contact_Enrichment■ PATROL_Message_Translation■ Dynamic_Blackout

To use these out-of-the-box dynamic data enrichment policies, you must enable the policy, import useful data into the sample .csv files and then import the data into the cell using the policy mechanism. For instructions on creating dynamic data enrichment policies, see “Creating a new dynamic data enrichment event management policy” on page 321.


Out-of-the-box event management policies

Out-of-the-box event management policiesSeveral event management policies are included with the product that enable you to interactively set up routine event processing quickly. Table 70 lists the out-of-the-box policies and indicates whether or not each out-of-the-box policy is enabled by default.

For instructions on using these out-of-the-box policies, see “Creating new standard event management policies” on page 285 and “Creating a new dynamic data enrichment event management policy” on page 321.

Table 70 Out-of-the-box policies

Policy type Policy name Description Enabled?

Closure PATROL_Portal_Closure closes previous Portal events for the same managed object

Yes

Adapter_Start_Stop_Closure closes previous events for the same adapter instance

Yes

Client_Stop_Closes_Start Client Stop events close Client Start events and then close themselves

Yes

Dynamic Blackout Dynamic_Blackout suppresses events that meet a specified criteria during a specified time period.

No

Dynamic Enrichment Location_Enrichment appends the location of a server to an event

No

Service_Contact_Enrichment appends contact information for a server administrator to an event. For example, contact information may include the name of the administrator for that server and his or her telephone number.

No

PATROL_Message_Translation replaces the text of existing PATROL event messages with messages that can be more easily understood by operators in your enterprise.

No

Recurrence Apache_Login_Failed_Repeats handles repeating Apache Login Failed events

No

Suppression Blackout_Suppression suppresses Blackout events No

Timeout PATROL_Portal_Timeout times out OK Portal events Yes


How event management policies work

How event management policies workAll event management policies must include the following components:

■ event selector■ process(es)■ timeframe(s)■ evaluation order

Each event management policy defines selection criteria that is applied to incoming events to determine which events are processed. A timeframe determines when the policy is active or inactive. The evaluation order determines which policies are implemented first if there is a conflict.

In addition to these components, dynamic data enrichment policies also require a dynamic data enrichment source file, for more information on how dynamic data enrichment policies interact with dynamic data enrichment source files, see “How dynamic data enrichment event management policies work” on page 270.

Event management policy workflow overview

Figure 43 illustrates the workflow for creating and implementing an event management policy.

Figure 43 Event management policy definition workflow


Event selectors

Event selectors

An event selector is the component of an event management policy that selects one or more events to which an event management policy applies. Rather than specifying a particular event to process, as a rule does, a selector specifies a list of event selection criteria (also called an Event Condition Formula (ECF)). When an incoming event meets any of the specified event selection criteria, the cell applies the associated event management policy to the event. See “Event selection criteria” on page 267 for more information.

Table 71 lists the out-of-the-box event selectors.

You can create custom event selectors. For information about creating event selectors, see “How to create an event selector and specify event selection criteria” on page 281.

Event selector groups

An event selector group, created when an event selector is defined, allows you to organize event selectors. For example, you could create event selector groups that classify event selectors by the severity of events. You could create one event selector group for major severity events and one for minor severity events.

Event selector groups appear as folders in the By Selector subtree in the Event Management Policies navigation pane. The names of event selectors which belong to a group are displayed as group.event_selector_name in the selectors lists in the list pane and in the By Event Class subtree. The name also is displayed in a separate field in the Selector Details tab.

Table 71 Out-of-the-box event selectors

Event selector Group Event selector Events selected

Default Adapter_Start_Stop Adapter starting and stopping events

Default Apache_Login_Failed Apache web server login failed events

Default Client Stop client stop events

Default PATROL_Portal_OK_Events OK severity events coming from PATROL Portal

Default PATROL_Portal_Events events coming from PATROL Portal

None All_Events all events

None Blackout_Events all blacked-out events

None PATROL_Events events coming from PATROL agents


Event selection criteria

Figure 44 shows an event selector group called Default that has the Adapter Start Stop event selector highlighted. Notice that details about the highlighted event selector appear in the Selector list in the right pane of the Administration view.

Figure 44 Event selector group name

Event selectors do not have to belong to a group. Event selectors that do not belong to a group are displayed directly under the By Selector subtree.

Event selection criteria

Event selection criteria tells a cell to which incoming events to apply the associated event policies. By using selection criteria to choose events rather than creating a single event management policy for each event type, event selection criteria perform the event management policy equivalent of dynamic data for rules. One event management policy using event selection criteria that spans a range of event types can be easier to maintain than a separate rule for each of many event types.

The BMC Impact Explorer interface allows you to interactively create syntactically accurate event selection criteria expressions without the need for specific syntax knowledge because the editor verifies that the expression has the correct syntax.

For more information see, “How to create an event selector and specify event selection criteria” on page 281.

event selector group name


Timeframes

Timeframes

Timeframes allow you to specify when the event management policy is active. For example, during scheduled database maintenance periods, you might want to activate an event suppression policy for maintenance-related events to reduce unnecessary event accumulation.

For events to be impacted by a timeframe setting, the timeframe must be active for the entire time that is specified in the policy.

Table 72 describes the types of timeframes you can use in an event management policy.

The following timeframe definitions are provided out-of-the-box:

■ US_Holidays_2004■ US_Holidays_2005■ Weekdays■ Weekend

EXAMPLE An escalation policy is defined to escalate an event to priority level 1 (escalated one level) after 10 minutes. Events are generated. No event will be escalated for at least 10 minutes. Five minutes after the policy is enabled, the policy is disabled. Even though the policy was active at the beginning of the 10 minute period, no event is impacted by the policy because it is not active at the end of the 10 minutes.

An escalation policy is defined to escalate an event priority after 30 minutes with an active timeframe from 4:00 P.M. to 5:00 P.M. At 4:45 P.M. events are generated. The active time period expires at 5:00 P.M. Events generated at 4:45 P.M. are not impacted by the policy because the timeframe is not active at 5:15 P.M.

Table 72 Timeframe types and descriptions

Type Icon Description

local timeframe Local timeframes are used for event policies only. They are maintained in the cell and are only visible to a single cell.

You create local timeframes from the Administration view of the BMC Impact Explorer, as described in “How to create a new local timeframe” on page 274.

global timeframe Global timeframes are used for event policies and service model components. They are maintained in the CMDB and are visible to all cells in an environment.

You create global timeframes in the Service Model Editor. For instructions, see the BMC Impact Solutions: Service Model Administrator’s Guide.


Evaluation order of event policy types

Evaluation order of event policy types

BMC Impact Managers evaluate event policies of different types based on the order of the rule phase in which the event management policy executes. The standard rule phases and their associated event policy types are shown in Table 73.

1Unlike other event policies, cells evaluate threshold event policies in two distinct phases—the first phase for the hold threshold and the second phase for the pass through threshold.

Table 73 Evaluation order of event policy types

Evaluation order Rule phase Event policy type

1 refine blackoutenrichmentdynamic blackoutdynamic enrichmenttimeout (initialization)

2 filter NOPASS suppression

3 regulate threshold1

4 threshold threshold1

escalation

5 new closurerecurrence

6 abstract no related event management policy

7 correlate correlation

8 execute timeout (arm)notification

9 propagate propagation

10 delete no related event management policy

11 timer timeout (execute)escalation

WARNING Although event policies of different types are evaluated according to their associated rule phase, event policies of the same type do not have an evaluation order. For example, if event selectors for two event policies of the same type select the same event, the cell evaluates the event according to one event management policy and ignores the other event management policy.

To prevent omission of event management policy evaluation, you must create mutually exclusive event selection criteria for two event policies of the same type. With the exception of dynamic blackout, dynamic enrichment, notification and propagation event policies, two or more policies of the same type should not execute against the same event. In the case of exceptional event policies, the cell evaluates all event policies of those four types, even if their selectors reference the same event.


Compiling event policies

Compiling event policies

Event policies are validated during compilation. Event policies are compiled when a BMC Impact Manager (cell) starts. As soon as compilation successfully completes, event processing begins. If, during cell startup, the compilation of any policy fails, the BMC Impact Manager issues an error message that lists the causes of the failure and stops. If, while the BMC Impact Manager is running, an event management policy is defined or is changed, it compiles dynamically.

How dynamic data enrichment event management policies work

Dynamic data enrichment policies require the same components as standard event management policies. However, dynamic enrichment policies allow you to import external enrichment data into the policy, rather than having to enter it manually.

First, you must either export data from a data source (such as an asset database) or manually enter information into the enrichment file (.csv).

Once the data enrichment source file contains the data required, you can use the policy to import the data into BMC Event Manager for use in the enrichment process. Figure 45 illustrates the dynamic data enrichment flow.

Figure 45 Flow of data required to implement a dynamic data enrichment policy

External enrichment data sources

An external enrichment data source can provide additional information about an event that is not available from the technology from which the event originates. An example of an external enrichment data source is a database such as an asset data store. Information from the database must be manually exported into a flat delimited file, so that BMC Event Manager can access the information. The recommended format to export the data to is a .csv file.

BMC provides some sample policies and associated enrichment data sources in the %HOME%\Mastercell\console\etc\samples directory.



Dynamic data enrichment policies can also use data included in BMC PATROL Enterprise Manager (PMEP) files if you are migrating from BMC PATROL Enterprise Manager to the BMC Event Manager solution.

Dynamic data enrichment source files

A dynamic data enrichment source file must contain at least one match field and at least one output field.

A match field is the lookup or key field which the dynamic data enrichment policy uses to identify the incoming event. You may use multiple match fields to identify an incoming event.

An output field identifies the type of enrichment information that is to be added to the event.

Once the policy has matched the event data of the match field(s) with the data in the enrichment file, it will add the associated enrichment data from the enrichment file into the output field identified in the policy.

Wildcards are supported for pattern matching which allows for more generic policy rules to be written.

Sample dynamic data enrichment source files

Table 74 lists the product-supplied dynamic data enrichment source files that are located in the %HOME%\Mastercell\console\etc\samples directory. These sample files provide commonly needed enrichment information.

WARNING It is critical that the policy definition and the data enrichment source file contain the exact same number of match fields and output fields in the same order. If the match fields and output fields in the enrichment file and the policy do not match, the policy will not run.

For example, if you are using the contact.csv file that is included with the product, you must select the Host Class, Host, Object Class, and Object slots as the Match Fields and the Service and Owner slots as the Output Fields to correspond to the slots in the contact.csv file.



You can use these files as a guide to create your own dynamic data enrichment source files or you can modify and use these sample files.

For information on creating and using dynamic data enrichment source files, see “How to create and edit a dynamic data enrichment source file” on page 277.

PMEP files

PMEP files are BMC PATROL Enterprise Manager (PATROL Message Enhancement Processor) enrichment configuration files. In BMC PATROL Enterprise Manager, PMEP provided a similar dynamic data enrichment capability. If you are migrating from BMC PATROL Enterprise Manager to BMC Event Manager (BEM), you can continue to use the PMEP files in the BEM environment.

Depending on your requirements, you can use one or more of the following configuration files shown in Table 75.

Table 74 Dynamic data enrichment source files

Data source file Policy name Description

location.csv Location_Enrichment appends the location of a server to an event

contact.csv Service_Contact_Enrichment appends contact information for a server administrator to an event. For example, contact information may include the name of the administrator for that server and his or her telephone number.

TextTranslation.csv PATROL_Message_Translation replaces the text of existing PATROL event messages with messages that can be more easily understood by operators in your enterprise. This file includes predefined message translations that will be immediately useful in your enterprise. For more information, see “Using the sample PATROL messaging text translation dynamic data enrichment source file” on page 279.

blackout.csv Dynamic_Blackout suppresses events that meet a specified criteria during a specified time period.

Table 75 Enrichment configuration files (part 1 of 2)

File Description

Blackout.cfg Provides event suppression for specified time periods when matching criteria are met

Location.cfg Provides a name that identifies the location (or server) from which the PATROL Agent events are being sent to Agent Connection. The name is added to the ObjectLocation field when matching criteria is met



In data event policies, your PMEP file selection will populate the event class and match fields with predefined values.

Figure 46 lists the default PMEP event classes and slot values.

Figure 46 Default PMEP event classes and slots

ServiceContact.cfg Provides the Business Service Views or Application Groups to which the events belong. The support staff that are responsible for correcting the problem are identified by an event and any trouble ticket information will be included in an event when matching criteria is met. Service information is added to the Service field; contact information is added to the ObjectStaff field and concatenated into the ObjectLocation field and trouble ticket information is concatenated into the ObjectLocation field

TextTranslation.cfg Provides modifications to text in the FreeText field when matching criteria is met

# PMEP Text Transaclationpmep.text.eventclass=PATROL_EVpmep.text.match_fields=mc_object_class,mc_parameter,p_classpmep.text.output_fields=msg

# PMEP Service Contactpmep.service.eventclass=EVENTpmep.service.match_fields=mc_host_class,mc_host,mc_object_class,mc_objectpmep.service.output_fields=mc_service,administrator,mc_notes

# PMEP Locationpmep.location.eventclass=EVENTpmep.location.match_fields=mc_hostpmep.location.output_fields=mc_location

# PMEP Blackoutpmep.blackout.eventclass=EVENTpmep.blackout.match_fields=mc_host_class,mc_host,mc_object_class,mc_object,mc_paramemter

Table 75 Enrichment configuration files (part 2 of 2)

File Description


How to create a new local timeframe


Local timeframes allow you to specify periods of time that determine when an event management policy will or will not run. You can set up a single timeframe that can apply to multiple policies.

For example, if you have several policies that you do not want to run on weekends, you can set up a timeframe from 12:00AM to 12:00 AM on both Saturday and Sunday and call that timeframe Weekend. You can then apply the timeframe Weekend to all policies that you do not want to run on weekends.

If you do not specify a timeframe for a policy, the policy will run continuously. For a list of timeframes that are included out-of-the-box, see “Timeframes” on page 268.

To define an event management policy timeframe

1 From the toolbar of the Administration view, click the View/Update Timeframes button .

The Timeframes window is displayed, as shown in Figure 47.

Figure 47 Timeframes

2 From the Timeframes toolbar, click the New Timeframe button.

The Timeframe Edit dialog is displayed, as shown in Figure 48 on page 275.

NOTE Global timeframes are created in the Service Model Editor. For instructions, see the BMC Impact Solutions: Service Model Administrator's Guide.

NOTE Timeframes are required for blackout policies.



Figure 48 Timeframe Edit

3 Enter or modify the appropriate information in the fields available in the Timeframe Edit dialog as described in Table 76.

Table 76 Timeframe Edit dialog options (part 1 of 2)

Field Description

Name Name of the timeframe

Description Description of the timeframe

Start, End, and Duration

Period when the timeframe begins and ends, and the duration of the timeframe. Changing the duration will change the value in the End field, and vice-versa.

The individual time zone of cell will be used in timeframe calculations.


How to add a notification service (notification policies only)

4 To create additional timeframes, click Save and repeat this procedure starting with step 2.

5 To close the editor, click Close.

How to add a notification service (notification policies only)

Before you can create or enable a standard notification event management policy (as described in “Creating a new notification policy” on page 302), you must add a notification service.

To add a notification service

1 On the Administration view, choose the Dynamic Data Editor tab.

2 In the Dynamic Data Editor tree, expand the server for which you want to add notification.

3 Expand the Data section, and then expand the Cell Data section.

4 Select Notification Service.

The available notification services are listed in the Notification Service tab in the right pane of the Administration view.

5 In the Notification Service tab, right-click one of the available notification services and choose New.

Recurrence pattern Schedules how often the timeframe will recur. Changing the selection in the left side list will change the options available on the right side.

Besides the Daily, Weekly, Monthly, and Yearly timeframe options, you can select individual dates that are part of the timeframe by selecting Date List and choosing dates from the displayed calendar.

Range of recurrence When you have selected a Daily, Weekly, Monthly, or Yearly timeframe option, you can choose the starting and ending date range for the recurrence.

Optionally, instead of choosing an end date, you can enter the number of recurrences for the timeframe.

Table 76 Timeframe Edit dialog options (part 2 of 2)

Field Description


How to create and edit a dynamic data enrichment source file

6 On the New tab, in the Name field, enter a unique name for the service.

7 In the Type field, choose one of the notification service types.

8 In the Service field, enter the command to initiate notification.

9 In the available_targets field, enter the individual or group recipients of the notification.

10 Click OK.


Before you enable a dynamic enrichment policy, you must import or enter the data that you want to use for enrichment into a data file. You can import the enrichment data into any delimited flat file; however, BMC Software recommends importing the data into a .csv file and using Microsoft Excel to view and manipulate the contents of the file. The spreadsheet format of Microsoft Excel makes it easier to view and manipulate the information in the file.

You can use the sample data enrichment files provided with the product as a guide to set up your own data enrichment source files. The sample files are located in the %HOME%\Mastercell\console\etc\samples directory. For a list of sample files provided with the product, see “Sample dynamic data enrichment source files” on page 271.

Before you begin

If you will be referencing a timeframe in your dynamic data enrichment source file, you must ensure that the timeframe that you will be referencing already exists. If the timeframe you want to reference does not exist, you must define it as described in “How to create a new local timeframe” on page 274.

NOTE Dynamic data enrichment source files are not required for standard event management policies. You only need a dynamic data enrichment source file if you are creating a dynamic data enrichment policy.



To create a dynamic data enrichment source file

1 In Microsoft Excel, create a new file and save it as type .csv.

2 In each column of the spreadsheet, enter information that corresponds to each match value and output value that will be included in your dynamic data enrichment policy.

3 Save and close the file.

To edit a sample dynamic data enrichment source file

1 Open one of the sample data source files included with the product located in the %HOME%\Mastercell\console\etc\samples directory.

2 Import or enter information specific to your enterprise.

Figure 49 shows an example of an edited location.csv file.

The location for hosts Texan1 and Texan2 is listed as Houston. The location for all hosts beginning with Cowboy (for example, Cowboy1, CowboySmith, CowboyAikman) is listed as Dallas.

3 Save and close the file.

4 The data enrichment source must be imported into the policy each time you modify the .csv file. For instructions on importing dynamic data enrichment data source, see


For example, if you are using the location.csv file that is included as a sample with the product, this file has two columns—mc_host and mc_location. If you are creating a dynamic data enrichment location policy that uses the location.csv file as the data enrichment source file, you must select the Host slot as the Match Field and the Location slot as the Output Field to correspond to the columns in the location.csv file.

Figure 49 Example edited location.csv file

# This enrichment file is used to add an extra field "mc_location" to an event.# This can be useful to group together or understand the physical location of IT components to help with event assignment and resolution.# mc_host, mc_locationTexan1, HoustonTexan2, HoustonCowboy*, Dallas


Using the sample PATROL messaging text translation dynamic data enrichment source file


The sample PATROL messaging text translation data enrichment source file, TextTranslation.csv, provided in the %HOME%\Mastercell\console\etc\samples directory is prepopulated with over two hundred translations for messages from the following Knowledge Modules:

■ BMC SQL-BackTrack NetWorker OBSI Module■ PATROL KM for CONTROL-M■ PATROL KM for UNIX and Linux■ PATROL KM for Microsoft Windows Servers■ PATROL KM for Netware■ PATROL KM for Sybase■ PATROL KM for Internet Server Manager■ PATROL KM for Oracle■ BMC Performance Manager for Microsoft Windows Terminal Services

If you are integrated with PATROL, you can gain instant value by enabling this policy and importing the data from TextTranslation.csv into the cell as described in “Enabling a dynamic enrichment PATROL message text translation policy” on page 343. This policy allows you to reword ambiguous event messages into messages more easily understood by the IT operators handling the events in Impact Explorer.

The sample policy, TextTranslation.csv, will translate PATROL event messages coming from either BMC Impact Integration for PATROL 3.0 or BMC Impact Integration for PATROL 7.0.

Overview of the PATROL messaging text translation dynamic data enrichment source file

Figure 50 shows some sample rows included in the TextTranslation.csv file.



Figure 50 Sample rows in the TextTranslation.csv file

The first three columns are match fields for incoming events. The first column contains the object class or application class of the KM. The second column contains the parameter. The third column contains the origin class.

The last column is the output field or the message that should be displayed when an event matching the criteria in the first three columns is received.

For example, in the first row, the cell will look for an event coming from the CPUCpuUtil parameter of the CPU application class. When the cell receives that event, it will display the message:

CPU Utilisation is at 97%

or whatever number the CPU utilization percentage is at that time.

Many of the messages in the sample file contain slots that will be populated with values from the parameter. For information on the syntax for using slots in a text message see, “Editing the PATROL messaging text translation dynamic data enrichment source file.”

Editing the PATROL messaging text translation dynamic data enrichment source file

You can also add to and edit the TextTranslation.csv file, if required. For example, you might want to translate the messages included in the file into your native language. Or, you might want to include messages related to a KM that is not already included in the file.

One of the most powerful features of the text translation file is the ability to include CORE_EVENT base event class slots that will allow you to dynamically populate the message with information from parameters or other BMC Impact Manager components. This feature allows you to create messages that are very meaningful.


How to create an event selector and specify event selection criteria

Figure 50 shows some actual messages in the TranslationText.csv file that include variables. For example,

This message includes the %mc_object% and %mc_parameter_value% variables. This syntax in the enrichment source file allows you to substitute the value of the slot you have referenced into the event message.

To insert a slot value into a message, use the following syntax:

Message text %<slot_name>% message text

If you need to include a % sign in the actual message text, you must precede the % character with a back slash (\). For example, in Figure 51 the desired text message includes a % character. The syntax for the message is %mc_parameter_value%\% full.

If the value of mc_object is D: and the value of mc_parameter is 97 the reworded message would be:

Filesystem D: is 97% full.

For a list of CORE_EVENT base event class slots that you can use in text messages, see BMC Impact Solutions: Knowledge Base Development.


An event selector is the component of an event management policy that selects one or more events to which an event management policy applies using specified event selection criteria. When an incoming event matches any of the specified event selection criteria, the cell applies the associated event management policy to the event.

Before you begin

■ Unless you want the event management policy to run continuously, you must define a timeframe as described in “How to create a new local timeframe” on page 274.

Figure 51 Variable syntax example

FILESYSTEM FSCapacity Filesystem %mc_object% is %mc_parameter_value%\% full



■ [For dynamic data enrichment policies only.] Create a data enrichment source file as described in “How to create and edit a dynamic data enrichment source file” on page 277.

To create an event selector and specify event selection criteria

1 From the Administration view, select the Event Management Polices tab.

2 Select a valid node (non-cell group) from the navigation pane.

Valid nodes for event selector creation are all visible nodes except the top-level cell group node. When the Add Event Selector button in the toolbar becomes active, this is an indication that valid node is selected.

3 On the Administration view toolbar, click the Add Event Selector button .

The Selector Details tab, shown in Figure 52, is displayed.

Figure 52 Selector Details tab

4 In the Selector Name field, type the event selector name.

5 In the Group field, type an event selector group name.

The event selector that you create in the next step will belong to the event selector group that you enter. If you enter a name of an event selector group that does not exist, that group will be created.

6 To the right of the Base Event Class field, click the button to display an event class chooser dialog box (shown in Figure 53) from which to choose the event class.



Figure 53 Class Chooser dialog box

7 Select an event class from the tree and click OK to accept the class.

For more information about event classes, see the BMC Impact Solutions: Knowledge Base Development Reference Guide.

8 In the Description field, type an optional description for the event selector.

9 Click Add to add event selection criteria to this event selector.

The Add Event Criteria editor is displayed.

10 From the Add Event Criteria editor, type a description for the event selection criteria in the Description slot.

11 In the Event Class field, use one of the following methods to select an event class on which to base the event selection criteria:

■ Accept the default event class in the Event Class field.

■ Change the class by clicking the browse button. The Class Chooser dialog box is displayed, select a class and click OK.

NOTE You cannot change the event class specified in an ECF to any class that is not at the same level or below the event class already specified in the ECF. If the ECF contains slots in the current class that are not in the new class, you cannot change to the new class, even when it occurs in the hierarchy rooted in the base event class.



12 In the Selection Definition section, shown in Figure 54, create an expression that is used to determine whether an event of the selected class is processed by the policy by choosing a Slot, Operation, and Value.

Figure 54 Selection Definition section of the Add Event Criteria editor

The example expression in Figure 55 tests events for Windows security messages containing logon and logoff messages. You might use this expression as part of an event selector for implementation in an event blackout policy that hides these security events from display but maintains their history.

Figure 55 Example event selection criteria expression

For a list and definitions of EVENT slots available for selection, see the event and data classes appendix of the BMC Impact Solutions: Knowledge Base Development Reference Guide. For a list and definitions of the operators available for each slot, see the section on operators in the Master Rule Language (MRL) appendix of the BMC Impact Solutions: Knowledge Base Development Reference Guide.

13 Click OK to save the expression and close the Add Event Criteria editor.

The event selection criteria is displayed in the Event Selection Criteria section of the Selector Details tab, as shown in Figure 56.

Figure 56 Completed event selection criteria in Selector Details tab

14 To add more event selection criteria, click Add and repeat step 10 through step 13.

15 Click OK to save the event selector and its event selector group.


Creating new standard event management policies

Creating new standard event management policies

This section provides instructions for creating new standard event policies based on default event management policy types.

If you want to create an event management policy based on a custom policy type, see Chapter 13, “Creating and implementing user-defined policies.”

Before you begin

■ Unless you want the event management policy to run continuously, you must define a timeframe as described in “How to create a new local timeframe” on page 274.

■ Define an event selector and specify event selection criteria as described in “How to create an event selector and specify event selection criteria” on page 281.

Table 77 lists each standard event management policy type and the page number of the procedure for each type.

Creating a new standard blackout policy

A blackout policy specifies a period of time during which incoming events that match the event specification criteria will be ignored. All ignored events are logged.

Table 77 Standard event management policy types and procedures

To create this event policy... See...

Blackout “To create new a standard blackout policy” on page 286

Closure “To create a new closure policy” on page 288

Correlation “To create a new correlation policy” on page 291

Enrichment “To create an enrichment policy” on page 294

Escalation “To create an escalation policy” on page 298

Notification “To create a new notification policy” on page 303

Propagation “To create a new propagation policy” on page 306

Recurrence “To create a new recurrence policy” on page 309

Suppression “To create a new suppression policy” on page 311

Threshold “To create a new threshold policy” on page 314

Timeout “To create a new timeout policy” on page 317



An example of a blackout event management policy might have the cell ignore events generated from a successful log on to an external system.

To create new a standard blackout policy

1 From the Event Management Policies tab of the Administration view, expand the Policy Type folder.

2 Under the Policy Type folder, select Blackout Policy.

3 Click the Add Policy button .

A Selector Chooser dialog box is displayed.

4 From the Selector Chooser dialog box, choose the event selector that you want to use for this policy and click OK.

The Blackout Policy Details tab is displayed in the details pane of the Administration view as shown in Figure 57.



Figure 57 Blackout Policy Details tab

5 In the Policy Name field, type a unique alphanumeric name for the event management policy. The name must contain no spaces.

6 In the Description field, type a description of the event management policy.

7 To enable the event management policy, select the Enabled check box. If you do not want to enable the policy at this time, you can return to this dialog box and enable the policy later.

8 In the Policy Activation Timeframes section, define the periods of time the event management policy should be active (when enabled) by performing the following actions:

A Select one of the following choices:

■ To make the event management policy active continuously, select Always Active.

■ To specify when the policy is active or inactive, select Define Activation Timeframes.

The Active Timeframes and Not Active Timeframes check boxes are enabled.

B If you selected Define Activation Timeframes, depending on how you want to define the timeframe for your policy do one or both of the following:


Creating a new closure policy

■ To specify the periods of time when the policy should be active, select the Active Timeframes check box and one or more timeframes from its scrollable list.

■ To specify the periods of time when the policy should be inactive, select the Not Active Timeframes check box and one or more timeframes from its scrollable list.

9 Click OK.

BMC Impact Explorer saves the defined event management policy, and it is displayed in the list of event policies for the selected event selector.


An closure policy closes a specified event when a separate specified event is received.

To create a new closure policy


2 Under the Policy Type folder, select Closure Policy.


NOTE You can select both check boxes to create active and inactive time periods. However, the inactive time period takes precedence over the active time period.





The Closure Policy Details tab is displayed in the details pane of the Administration view as shown in Figure 58.

Figure 58 Closure Policy Details tab














9 Click Edit Event Criteria.

The Add Event Criteria window is displayed.

10 In the Add Event Criteria window, specify event selection criteria for the event type that you want to close and click OK.

11 To close only matching events that occur within a certain timeframe, check the Close Events with Age Less Than check box and specify an amount of time. If the Close Events with Age Less Than check box is not checked, there is no limit on the time between the closed event and the closing event.



Creating a new correlation policy

12 To suppress the closing event, check the Suppress the Closing Event check box.

13 To save the completed event closure policy, click OK.

BMC Impact Explorer saves the defined event management policy, and it is displayed in the list of event policies for the specified event selector.


A correlation policy relates one or more cause events to an effect event. If desired, this policy can close the effect event. The cell maintains the association between these cause-and-effect events.

To create a new correlation policy


2 Under the Policy Type folder, select Correlation Policy.




The Correlation Policy Details tab is displayed in the details pane of the Administration view, as shown in Figure 59.



Figure 59 Correlation Policy Details tab


6 To enable the event management policy immediately, select the Enabled check box. If you do not want to enable the policy at this time, you can return to this dialog box and enable the policy later.








The Active Timeframes and Not Active Timeframes lists are enabled.




9 Complete a separate Cause Event tab as appropriate for each cause event that you want to define.

Table 78 describes each of the controls in the Cause Event tabs.


Table 78 Cause Event tab controls

Field name Description

Enable check box Select this check box to relate the cause events to the effect events; this information is stored in the cell.

Edit Event Criteria button Click this button to specify the selection criteria for the cause event.

Correlation Timespan check box

Select this check box and enter a time limit within which the cause event must occur to produce the effect event.


Creating a new enrichment policy

10 To save the completed event correlation policy, click OK.



An enrichment policy adds values for specific event slots if those slots are empty when the event is received from the event source. An enrichment policy can also reformat slots or normalize slot values.

To create an enrichment policy


2 Under the Policy Type folder, select Enrichment Policy.




Close Effect Event radio buttons

Choose one of the following radio buttons to specify the circumstances under which the effect event will be closed:

■ Upon Correlation—as soon as events are associated (cause and effect), the effect event is closed

■ On Cause Event Closure—when the cause event closes, the effect event is closed also

■ On Its Own—closing the cause event has no consequence to the effect event

Escalate Cause Event check box

select this check box to escalate the cause event to the specified priority level

De-escalate Effect Event check box

select this check box to de-escalate the effect event

Table 78 Cause Event tab controls

Field name Description



The Enrichment Policy Details tab is displayed in the details pane of the Administration view, as shown in Figure 60.

Figure 60 Enrichment Policy Details tab





7 In the Policy Activation Timeframes section, define the periods of time that the event management policy should be active (when enabled) by performing the following actions:








8 Enable the following check boxes as necessary to assign appropriate settings:

■ Event Priority—the relative priority to assign to the event (1 is a high priority)■ Event Category—the classification to assign to the event; categories include

— availability— capacity— configuration— operational— performance— recovery— security— SLM (service level management)— message text format

■ Object Type—the object type against which the event applies, such as a server■ Location to Set—the physical location of the object, such as a city■ Services to Set—the service that the event is associated with



Creating a new escalation policy

9 In the Message Text Format box, define the message slot enrichment for the event:

A From the list of available event slots in the Event Slot box, select an event slot to which to add enrichment information and click Insert.

B To insert a a slot value into the message, either type the slot name surrounded by % characters or select the slot name from the Event Slot list and click Insert.

The box is a standard text box. You can position the cursor and type or insert text and slot refeences in any order. The Event Slot list and Insert button are provided as a convenience so you do not have to remember the valid slot names. The resulting string of characters in the Message Text Format box, %<slot name>%, whether typed or inserted, is used as a template to create the message (msg slot) for the event.

Repeat steps A and B to add more enrichment information to the event slot, if necessary.

10 To save the completed event enrichment policy, click OK.



An escalation policy raises or lowers the priority level of an event after a specified period of time. A specified number of event recurrences can also trigger escalation of an event.

For example, if the abnormally high temperature of a storage device goes unchecked for 10 minutes or if a cell receives more than five high-temperature warning events in 25 minutes, an escalation event management policy could increase the priority level of the event to critical.

NOTE The hidden and list of slots are not available for message enrichment.

To avoid unpredictable results when adding a text message, use no more than one set of quotation marks.



To create an escalation policy


2 Under the Policy Type folder, select Escalation Policy and click OK.




The Escalation Policy Details tab is displayed in the details pane of the Administration view, as shown in Figure 61.



Figure 61 Escalation Policy Details tab














9 In the Time Escalation section, shown in Figure 62, use the Timespan Before Priority is Escalated selectors to enter the number of a specified period of time that must elapse before an event is escalated. The default time period is seconds, but this time period can be changed to minutes, hours, or days by selecting one of these time periods from the drop list.


NOTE You can set Time Escalation or Rate of Event Arrival (step 13 through step 15 on page 302), or both. To set only one, leave the fields of the other set to zero.



Figure 62 Time Escalation Controls

10 Choose one of the following radio buttons to determine how the priority of the event will be escalated after the specified time has elapsed:

■ Levels to Escalate/De-escalate Priority By—Choose this radio button to escalate or de-escalate the event by a specified number of levels after the time period specified by the Timespan Before Priority is Escalated selector has elapsed. Enter the number of levels that the event is to be escalated.

■ Set Priority to This Value—Choose this radio button to set the event to a specified priority level after the time period specified by the Timespan Before Priority is Escalated selector has elapsed. Choose the priority level from the drop list.

11 (optional) To prevent the event from being escalated after it has been acknowledged, select the Do not Escalate if Acknowledged check box.

12 (optional) To prevent the event from being escalated after it has been assigned, select the Do not Escalate if Assigned check box.

13 In the Rate of Event Arrival section, shown in Figure 62, in the Number of Events Needed for Escalation selector, enter the number of events that must occur before the event is escalated.

NOTE You can set Time Escalation (step 9 through step 12) or Rate of Event Arrival, or both. To set only one, leave the fields of the other set to zero.


Creating a new notification policy

Figure 63 Rate of Event Arrival Controls

14 In the Timespan in which Events Must Arrive selector, enter the time in which the events must arrive before the event is escalated or the event priority is changed.

15 Choose one of the following radio buttons to determine how the priority of the event will be escalated after the number of events have arrived within the specified timespan:

■ Levels to Escalate Causal Event Priority—Choose this radio button to escalate the causal event by a specified number of levels after the number of events specified Number of Events Needed for Escalation selector have occurred within the time period specified by the Timespan in which Events Must Arrive selector. Enter the number of levels that the event is to be escalated.

■ Set Priority to This Value—Choose this radio button to set the event to a specified priority level after the number of events specified Number of Events Needed for Escalation selector have occurred within the time period specified by the Timespan in which Events Must Arrive selector. Choose the priority level from the drop list.

16 To save the completed event escalation policy, click OK.



A notification policy sends a request to an external service to notify a user or group of users that the event has occurred.

For example, a notification event management policy might notify a system administrator by means of a pager about the imminent unavailability of a mission-critical piece of storage hardware.



Before you begin

You must add a notification service as described in “How to add a notification service (notification policies only)” on page 276.

To create a new notification policy


2 Under the Policy Type folder, select Notification Policy and click OK.




The Notification Policy Details tab is displayed in the details pane of the Administration view, as show in Figure 64.



Figure 64 Notification Policy Details tab














9 From the Notification Service drop list, select the service to use as the notification mechanism. The default service is email.

10 In the Add field, type the name of a person or group to notify. Click Add to add the name to the Notify slot. Add more names or groups if necessary.

11 From the Event Status that will Notify Users list, choose the event status that you want to trigger the notification.

12 In the Notification Text field, enter the notification message. If desired, you can use the Event Slot drop list to choose event slots to add to the notification message. Click the Insert button to insert the slots into the message. Enter a space before and after each slot that you add.

13 (optional) Select the Auto Acknowledge check box to automatically acknowledge the event.



Creating a new propagation policy

14 (optional) Select the Auto Assign check box to automatically assign the event to the user you select from the list.

15 To save the completed event notification policy, click OK.



A propagation policy forwards events to other cells or to integrations to other products.

To create a new propagation policy


2 Under the Policy Type folder, select Propagation Policy and click OK.




The Propagation Policy Details tab is displayed in the details pane of the Administration view, as shown in Figure 65.



Figure 65 Propagation Policy Details tab


6 In the Description box, type a description of the event management policy.









Creating a new recurrence policy



9 In the Propagate to all of list, choose one or more cells (Impact Managers).

Figure 66 Propagation cell list

10 In the Propagate to one of list, select one or more cells (Impact Managers).

11 To save the completed event propagation policy, click OK.



A recurrence policy combines duplicate events into one event that maintains a counter of the number of duplicates.


NOTE All of the dup_detect slots on the incoming event must be the same for all events that match the selector or the recurrence policy will not function.

Because PATROL integration has dup_detect set on the mc_origin_key and these keys are unique, recurrence policies will not operate as expected for PATROL integration events.



To create a new recurrence policy


2 Under the Policy Type folder, select Recurrence Policy and click OK.




The Recurrence Policy Details tab is displayed in the details pane of the Administration view, as shown in Figure 67.



Figure 67 Recurrence Policy Details tab

5 In the Policy Name box, type a unique alphanumeric name (with no spaces) for the event management policy.










Creating a new suppression policy



9 If you want to define a time window for events that are considered to be recurring, check the Recurring Events Must Arrive Within this Timespan check box and set the maximum time after the initial event within which an event must arrive to count toward recurrence. If the box is not checked, there is no limit on the time between duplicate events that are counted as recurring.

10 In the Slot Updates section, select any original event values that you want updated by the latest recurrent event values.

11 To save the completed event recurrence policy, click OK.



A suppression policy specifies the events that the receiving cell should delete. Unlike a blackout event management policy, the suppression event management policy maintains no record of the deleted event.

To create a new suppression policy


2 Under the Policy Type folder, select Suppression Policy.





The Selector Chooser dialog box is displayed.


The Suppression Policy Details tab is displayed in the details pane of the Administration view, as shown in Figure 68.

Figure 68 Suppression Policy Details tab





Creating a new threshold policy









9 Click OK.



A threshold policy specifies a minimum number of duplicate events that must occur within a specific period of time before the cell accepts the event. For events allowed to pass through to the cell, the event severity can be escalated or de-escalated a relative number of levels or set to a specified level. If the event occurrence rate falls below a specified level, the cell can take action against the event, such as changing the event to closed or acknowledged status.




To create a new threshold policy


2 Under the Policy Type folder, select Threshold Policy.




The Threshold Policy Details tab is displayed in the details pane of the Administration view as shown in Figure 69.



Figure 69 Threshold Policy Details tab














9 For the Number of Duplicate Events Received slot, supply a numeric value and an associated time measurement to specify the threshold above which an event is accepted.

10 Select one of the following radio buttons (The threshold-specific options displayed on the tab change depending on which button you select.):

■ Hold Events Until Threshold is Met—Select this option to prevent creation of any specified event until the number of events exceeds the threshold within the specified time period.

If you select Hold Events Until Threshold is Met, the options shown in Figure 70 are displayed. Specify whether to include allowing the last, first, highest, or lowest severity event to pass and whether to acknowledge or close the passed event when incoming (new) events fall below a specified low threshold rate.

Figure 70 Hold Events options

■ Pass Events through—select this option to create all events when they meet the required threshold rate.

If you select Pass Events through, the options shown in Figure 71 are displayed.



Creating a new timeout policy

Figure 71 Pass Events Through options

Choose one of the following radio buttons to determine how the severity of the event will be escalated or de-escalated:

■ Levels to Escalate/De-Escalate Event Severity By—Choose this radio button to escalate or de-escalate the severity of the event by a specified number of levels after the number of events specified Number of Duplicated Events Received selector have occurred within the time period specified by the Timespan in which Events the Must Arrive selector. Enter the number of severity levels that the event is to be escalated.

■ Set Severity to This Value—Choose this radio button to set the event to a specified severity level after the number of events specified Number of Duplicated Events Received selector have occurred within the time period specified by the Timespan in which Events the Must Arrive selector. Choose the severity level from the drop list.

11 To save the completed event threshold policy, click OK.



A timeout policy changes an event status to closed after a specified period of time elapses.

To create a new timeout policy


2 Under the Policy Type folder, select Timeout Policy.

NOTE From the Set Severity to This Value drop list, choose Critical, Non-critical, Minor, Warning, or OK. Do not choose Unknown, as it is considered a status rather than a severity.






The Timeout Policy Details tab is displayed in the details pane of the Administration view as shown in Figure 72.

Figure 72 Timeout Policy Details tab














9 In the Timeout Event After field, enter a number of time periods that must elapse before an event will time out. The default time period is seconds, but this time period can be changed to minutes, hours, or days by selecting one of these time periods from the drop list.

10 To save the completed event timeout policy, click OK.




Enabling and disabling out-of-the-box standard event management policies

Enabling and disabling out-of-the-box standard event management policies

This section provides instructions for enabling and disabling out-of-the-box standard event management policies.

For a list of out-of-the-box event management policies, see “Out-of-the-box event management policies” on page 264.

For instructions on enabling out-of-the-box dynamic data enrichment policies, see “Enabling out-of-the-box dynamic data enrichment event management policies” on page 332.

To enable or disable a standard event management policy


1 From the Event Management Policies tab of the Administration view, expand the By Policy Type folder.

2 Under the By Policy Type folder, select the policy type for the out-of-the-box standard event policy that you want to enable.

Out-of-the-box standard event policies are included under the following policy types:

■ Closure Policy■ Recurrence Policy■ Suppression Policy■ Timeout Policy

A list of out-of-the-box standard event management policies of that policy type are displayed in the right pane of the Administration view as shown in Figure 80.

Figure 73 List of event management policies

3 From the list of event management policies, select the policy that you want to enable.

The Details tab for that policy is displayed in the details pane of the Administration view.


Creating a new dynamic data enrichment event management policy

4 On the BMC Impact Manager toolbar, click the Update Policy button to enable the Details tab to be edited.

5 Enable or disable the policy by selecting or deselecting the Enabled check box.

6 Click OK.



This section provides instructions for creating a new dynamic data enrichment event management policy (page 321) and for creating a new dynamic enrichment blackout policy (page 327).

Before you begin

■ Ensure that the timeframe referenced in your dynamic data enrichment source file exists. If it does not exist, you must define the timeframe as described in “How to create a new local timeframe” on page 274.

■ Determine which event selector you want to apply to your dynamic data enrichment policy. If none of the out-of-the-box event selectors are appropriate for your policy, define an event selector and specify event selection criteria as described in “How to create an event selector and specify event selection criteria” on page 281.

■ Create a data enrichment source file as described in “How to create and edit a dynamic data enrichment source file” on page 277.

To create a new dynamic data enrichment policy


2 Under the By Policy Type folder, select Dynamic Enrichment Policy.






The Dynamic Enrichment Policy Details tab, shown in Figure 74, is displayed in the details pane of the Administration view.



Figure 74 Dynamic Enrichment Policy Details tab



7 To enable the policy immediately, select the Enabled check box. If you do not want to enable the policy at this time, you can return to this dialog box and enable the policy later.



8 In the Execution Order field, if more than one policy exists, specify the order of execution.





The Active Timeframes and Not Active Timeframes lists are displayed.




10 If you do not want to accept the default event class, you can select an event class by clicking in the Event Class field of the Match Fields section, selecting a new event class, and clicking OK.

The Event Class determines what slots are available in the Available Event Fields column.

11 In the Class Chooser dialog box, select an event class and click OK.

NOTE When a new policy is created, the number shown in the Execution Order field should be one greater the largest current execution order.

If two policies have the same execution order, they will run in indeterminate order.




12 In Available Event Fields column, select the slots that correspond to the match fields in your dynamic data enrichment source file. Use the left arrow button to move those slots into the Match Fields column. You may select and move multiple slots at the same time.

13 In Available Event Fields column, select the slots that correspond to the output fields in your dynamic data enrichment source file. Use the right arrow button to move those slots into the Output Fields column. You may select and move multiple slots at the same time.

14 (optional) In the Match Fields section, activate the Match Tracing check box to add diagnostic notes to the event, if necessary.

15 In the Match Table section, in the Type field, accept the default.

16 In the Match Table section, in the Tag field, accept the default.

17 In the Match Table section, in the Data File field, do one of the following actions:

■ Type the path to the enrichment data source.■ To browse for the enrichment data source, click, .


For example, if you were creating a file similar to the location.csv file that is included with the product, you must select the Host slot as the Match Field and the Location slot as the Output Field to correspond to the slots in the location.csv file.

NOTE Typically, you do not need to the change the value of the Type field. You can override the default; however, you must use a unique tag within the given match table.

NOTE The Tag field uniquely identifies the match table that will be used by the policy instance.

You do not need to the change the value of this field. You can override the default; however, you must use a unique tag within the given match table.



1. In the File Chooser dialog box, select the dynamic data enrichment source file appropriate for your policy. For more information, see “External enrichment data sources” on page 270.

2. Click OK.

18 In the Match Table section, in the File Format field, select one of the following radio buttons to specify the type of data enrichment file to import:

■ Data file with this separator—Choose this radio button to import a flat, delimited file, such as a .csv file. Enter a separator to delimit the data column in the file.

For example, if you are using a .csv file, enter a comma (,) as the separator.

■ PMEP file—Choose this radio button to import a PMEP table and select the appropriate PMEP format for your policy from the drop list:

— Blackout— Blackout CSV— Location— Location CSV— Service— Service CSV— Text— Text CSV

19 Click OK.

If this is the first time a policy is saved, the following confirmation dialog box is displayed:

Figure 75 Import confirmation

20 Click Yes.

NOTE If you select the PMEP file button, the Event Class, Match Fields, and Output Fields are autopopulated with predefined values and become read-only.



A green check mark should be displayed in the Enable column next to the policy in the event management policies list. (You may need to scroll the window to the right to see the Enable column.) The policy also should show up in the tree in the left pane of the BMC Impact Explorer window.

21 Import the data from the dynamic data enrichment source enrichment file as described in “Importing dynamic data enrichment source” on page 347.

To create a new dynamic data enrichment blackout policy


2 Under the By Policy Type folder, select Dynamic Blackout Policy.




The Dynamic Blackout Policy Details tab is displayed in the details pane of the Administration view, as shown in Figure 76.



Figure 76 Dynamic Blackout Policy Details tab





7 To enable the policy immediately, select the Enabled check box. If you do not want to enable the policy at this time, you can return to this dialog box and enable the policy later.















10 If you do not want to accept the default event class, you can select an event class by clicking in the Event Class field of the Match Fields section, selecting a new event class, and clicking OK.

The event class determines what slots are available in the Available Event Fields column.

11 In the Class Chooser dialog box, select an event class and click OK.

12 In Available Event Fields column, select the slots that correspond to the match fields in your dynamic data enrichment source file. Use the left arrow button to move those slots into the Match Fields column. You may select and move multiple slots at the same time.

13 In Available Event Fields column, select the slots that correspond to the output fields in your dynamic data enrichment source file. Use the right arrow button to move those slots into the Output Fields column. You may select and move multiple slots at the same time.


15 In the Match Table section, in the Type field, accept the default.

16 In the Match Table section, in the Tag field, accept the default.


For example, if you were creating a file similar to the location.csv file that is included with the product, you must select the Host slot as the Match Field and the Location slot as the Output Field to correspond to the slots in the location.csv file.

NOTE Typically, you do not need to the change the value of the Type field. You can override the default; however, you must use a unique tag within the given match table.

NOTE The Tag field uniquely identifies the match table that will be used by the policy instance.

You do not need to the change the value of this field. You can override the default; however, you must use a unique tag within the given match table.



17 In the Match Table section, in the Data File field, do one of the following actions:

■ Type the path to the enrichment data source.■ To browse for the enrichment data source, click, .

1. In the File Chooser dialog box, select the dynamic data enrichment source file appropriate for your policy. For more information, see “External enrichment data sources” on page 270.

2. Click OK.

18 In the Match Table section, in the File Format field, select one of the following radio buttons to specify the type of data enrichment file to import:

■ Data file with this separator—Choose this radio button to import a flat, delimited file, such as a .csv file. Enter a separator to delimit the data column in the file.

For example, if you are using a .csv file, enter a comma (,) as the separator.

■ PMEP file—Choose this radio button to import a PMEP table and select the appropriate PMEP format for your policy from the drop list:

— Blackout— Blackout CSV— Location— Location CSV— Service— Service CSV— Text— Text CSV

19 Click OK.



NOTE If you select the PMEP file button, the Event Class, Match Fields, and Output Fields are autopopulated with predefined values and become read-only.


Enabling out-of-the-box dynamic data enrichment event management policies

20 Click Yes.



Enabling out-of-the-box dynamic data enrichment event management policies

This section provides instructions for enabling out-of-the-box dynamic data enrichment event management policies.

Before you begin

You must export data from an external enrichment data source into the dynamic data enrichment source files provided with the product before you can enable any of the out-of-the-box dynamic data enrichment policies. For more information see, “How to create and edit a dynamic data enrichment source file” on page 277.

The dynamic data enrichment source file for the PATROL Message Text Translation policy (TextTrans.csv) is the only out-of-the-box dynamic data enrichment source file that includes valid data. You can enable PATROL Message Text Translation policy without exporting data into TextTrans.csv. For more information about TextTrans.csv, see “Using the sample PATROL messaging text translation dynamic data enrichment source file” on page 279.

Table 79 lists each out-of-the-box dynamic data enrichment event management policy type and the page number of the procedure for each type.

Table 79 Out-of-the-box dynamic data enrichment event policy types and procedures

To enable this event policy... See...

Dynamic blackout “Enabling a dynamic data enrichment blackout policy” on page 333

Dynamic location enrichment “Enabling a dynamic data enrichment location policy” on page 336


Enabling a dynamic data enrichment blackout policy


A dynamic data enrichment blackout policy specifies external schedules that initiate event blackout.

Before you begin

For the dynamic blackout policy to work, you must define the timeframes referenced in the enrichment source file (blackout.csv). If any of the timeframes referenced in the enrichment source file have not been created in BEM, then the policy will not run.

For instructions on defining timeframes, see “How to create a new local timeframe” on page 274.

To enable a dynamic data enrichment blackout policy


2 Under the By Policy Type folder, select Dynamic Blackout Policy.

The Dynamic Blackout Policy Details tab is displayed in the details pane of the Administration view, as shown in Figure 78.

Dynamic service contact enrichment

“Enabling a dynamic data enrichment service contact policy” on page 340

Dynamic PATROL message translation

“Enabling a dynamic enrichment PATROL message text translation policy” on page 343

Table 79 Out-of-the-box dynamic data enrichment event policy types and procedures

To enable this event policy... See...



Figure 78 Dynamic Blackout Policy Details tab

3 On the BMC Impact Explorer toolbar, click the Update Policy button to make the Dynamic Blackout Policy Details tab editable.

4 On the Dynamic Blackout Policy Details tab, select the Enabled check box.



5 In the Execution Order field, if more than one policy of this type exists, specify the order of execution.

6 In the Policy Activation Timeframes section, define the periods of time the event management policy should be active and/or inactive (when enabled) by performing the following actions:




The Active Timeframes and Not Active Timeframes timeframe lists are displayed.




7 (optional) In the Match Fields section, activate the Match Tracing check box to add diagnostic notes to the event to assist with trouble-shooting an event.

8 Click OK.

A confirmation dialog box is displayed, asking if you want to import data now, as shown in Figure 79.





Enabling a dynamic data enrichment location policy

Figure 79 Import Data Confirmation dialog box

9 Click Yes.




The dynamic enrichment location policy adds location information to an event.

Some examples of uses for a dynamic enrichment location policy include:

■ Provides information to IT Operations so that they know which area/datacenter the problematic technology is located in and can direct engineers more quickly to the problem.

■ Allows IT Operations to build views in Impact Explorer of specific areas/data centers and understand at a glance where the problems are.

■ Allows IT Operations to view reports in BMC Impact Reporting based on location. For example, they can identify which locations which are generating the most events.

■ If you are integrating with a service desk the location identifier can be passed along with the rest of event, providing more useful information to the engineer that will be assigned to handle the incident.

To enable a dynamic data enrichment location policy





A list of out-of-the-box dynamic data enrichment policies are displayed in the right pane of the Administration view as shown in Figure 80.

Figure 80 List of out-of-the-box dynamic data enrichment policies

3 From the list of out-of-the-box dynamic enrichment policies, select Location_Enrichment.





4 On the BMC Impact Explorer toolbar, click the Update Policy button to make the Dynamic Enrichment Policy Details tab editable.

5 To enable the policy, select the Enabled check box.



6 In the Execution Order field, if more than one of this type of policy exists, specify the order of execution.










9 Click OK.






Enabling a dynamic data enrichment service contact policy


10 Click Yes.




The dynamic enrichment location policy adds contact information related to the originating technology to an event.

For example, you can add a server administrator’s name and telephone number to all events originating from a particular server

To enable a dynamic data enrichment service contact policy





3 From the list of out-of-the-box dynamic enrichment policies, select Service_Contact_Enrichment.





4 On the BMC Impact Explorer toolbar, click the Update Policy button to make the Dynamic Enrichment Policy Details tab editable.



5 To enable the policy, select the Enabled check box.

6 In the Execution Order field, if more than one type of this policy exists, specify the order of execution.










9 Click OK.





Enabling a dynamic enrichment PATROL message text translation policy



10 Click Yes.




If you are integrated with PATROL, the dynamic data enrichment PATROL message translation policy allows you to substitute existing PATROL messages with messages that are meaningful to your enterprise.

For example, you can use the PATROL message translation policy to change this message:

NT_CPU.CPU_0.CPUprcrUserTimePercent parameter CPUCputil triggered on 90 <= 97 <= 100

to the following, more comprehensible message:

CPU Utilization is at 97%

NOTE A sample dynamic data enrichment service contact policy data source file, TextTranslation.csv, is provided in the %HOME%\Mastercell\console\etc\samples directory. The TextTranslation.csv file includes translations for many common messages that will be useful in your enterprise. If you are integrated with PATROL, BMC Software recommends that you take advantage of the data that is already included in this sample file. For information about using the TextTranslation.csv file, see “Using the sample PATROL messaging text translation dynamic data enrichment source file” on page 279.



To enable a dynamic data enrichment PATROL message translation policy





3 From the list of out-of-the-box dynamic enrichment policies, select PATROL_Message_Translation.

4 Click the Update Policy button .





5 To enable the event management policy, select the Enabled check box. If you do not want to enable the event management policy at this time, it can be enabled later.















9 Click OK.



10 Click Yes.





Importing dynamic data enrichment source

Importing dynamic data enrichment sourceBefore a dynamic data enrichment policy can take effect, the data in the dynamic data enrichment source file must be imported.

1 Ensure that the policy is enabled.

2 Select Import tab.

The Import tab is displayed as shown in Figure 89.

Figure 89 Import tab

Table 80 describes the uneditable fields of the Import tab. These fields are for your information only.

3 In the field opposite the Import button, select whether you want to Replace the existing data in the cell or Merge new data with existing data in the cell.

4 Click Import.

The data is imported from the file into the cell.

5 Verify that the information has been uploaded by ensuring that the Last Action information in the Import tab shows a completed upload message.

Table 80 Import tab uneditable fields

Field Description

Data File Path to the enrichment data source

File Format Type of file used by the policy

Last Action Last time an import (replace or merge) was completed.


Verifying that the policy is running

Verifying that the policy is runningTo verify that the policy is running,

1 Send an event that should trigger the policy

2 Access the History tab, scroll down to the Operations Log and verify that your policy has executed.

Figure 90 shows the History tab for a successfully executed dynamic data enrichment policy.

Figure 90 History tab showing executed dynamic data enrichment policy

Editing event selection criteriaIf you need to edit event selection criteria that you have already defined, follow these steps:

1 From the event management policy tab navigation tree, select an event selector.

2 Click the Update Event Selector button .

3 From the Event Selection Criteria section of the Selector Details tab, select an event selection criteria in the list and click Edit.

The Edit button remains inactive until you select an event selection criteria.

4 Use the Edit Event Criteria editor to make the necessary changes to the description, event class, or expression.

5 To save the edited event selection criteria, click OK.


Deleting an event selector

6 From the Selector Details tab, click OK to save the edited event selection criteria and the event selector.

Deleting an event selectorIf you need to delete an event selector that you have defined, follow these steps:

1 From the event management policy navigation tree, select the appropriate event selector.

2 Click the Delete Event Selector button .

The Delete Confirmation dialog box is displayed.

3 Click Yes.

The event selector is deleted.


Deleting an event selector


C h a p t e r 13
13 Creating and implementing user-defined policies
This chapter describes how to create and how to implement user-defined policy types. This chapter presents the following topics:

Understanding user-defined event policy types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352Understanding event processing rules (MRL) for policy types . . . . . . . . . . . . . . . . . 352

Format of event processing rules for policy types . . . . . . . . . . . . . . . . . . . . . . . . . 352How a rule for a policy type is processed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353Sources of information about rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

User-defined event policy type creation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354Creating user-defined policy types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354Defining the policy data class for a new policy type . . . . . . . . . . . . . . . . . . . . . . . 354Defining presentation names for a new policy type . . . . . . . . . . . . . . . . . . . . . . . 356Creating the event processing rule(s) for a new policy type. . . . . . . . . . . . . . . . . 357


Understanding user-defined event policy types

Understanding user-defined event policy types

Predefined policy types cannot cover all requirements of different BMC Impact Solution implementations. To support specialized event processing, you can also define and implement custom event policy types to do specialized event processing not supported by the predefined policy types. For instructions on creating event policy types, see “User-defined event policy type creation” on page 354.

Understanding event processing rules (MRL) for policy types

This section describes the form of policy type rules and discusses how they work.

Format of event processing rules for policy types

A typical event processing rule for a user-defined policy type has this form:

<rule-phase> rule-name: using_policy { <POLICY_TYPE> ($POL) where [ ($POL.enabled == 1) AND (($POL.active_timeframes == [] ORtf_active($POL.active_timeframes)) AND NOT tf_active($POL.except_timeframes)) ] } $POL.selector_ecf ($EV) where [ <other conditions> ]{ <actions>; opadd($EV, $POL.name, "action name", ""); } END


How a rule for a policy type is processed

How a rule for a policy type is processed

The processing of a rule for a policy type is a follows:

1. The using_policy clause finds the applicable policy, that is, the instance of the user-defined policy class (derived from IM_POLICY).

These class definitions describe the slots available in a policy class:

2. The tf_active calls evaluates timeframes for the policy.

3. The selector ECF selects the event to process.

4. The actions implement the policy and the opadd call adds an entry to the operations log of the event.

Sources of information about rules

You can get more information about rules for policy types and how to create them from these sources

MC_DATA_CLASS : POLICY ISA CORE_DATA DEFINES { name : STRING, key = yes, read_only = yes; description : STRING; enabled : INTEGER, default = 1; }; ENDMC_DATA_CLASS: IM_POLICY ISA POLICY DEFINES { active_timeframes : LIST_OF STRING; except_timeframes : LIST_OF STRING; selector_name : STRING; selector_class : STRING; selector_ecf : ECF EVENT; ordinal : INTEGER, default=0; }; END

For... See...

examples of rules for policy types the pre-defined policies in .../kb/rules/im_internal.mrl.

definitions of the MRL constructs and primitives for policy rules

BMC Impact Solutions: Knowledge Base Development Reference Guide


User-defined event policy type creation

User-defined event policy type creationIf you want to create a new user-defined event policy to perform specialized event processing, first, you must define a new event policy type. An event policy type is a data class, derived from that defines the distinct type of event processing to be performed.

Creating user-defined policy types

To define a new user-defined policy type, you must do the following things.

Defining the policy data class for a new policy type

To create a new policy type, first you must define a data class derived directly from the IM_BASE_CUSTOM_POLICY base class. This policy data class describes the policy type’s data. It also provides the template of data fields (slots) used by BMC IM to generate the BMC IX Custom Policy Details panel in which users specify the processing details for a policy of that type.

To define a new policy data class

1 Using a text editor, open the appropriate BAROC language file in the Knowledge Base.

Because the IM_BASE_CUSTOM_POLICY base class is defined in .../kb/class/im_policies.baroc file, you must define the new policy type in a separate file that is loaded for compilation after .../kb/class/im_policies.baroc file (it is listed after the im_policies.baroc in the .../kb/class/.load file list).

Table 81 Policy Type Creation process

Step Task Topic

1 Define a new policy data class that describes the policy type and copy it to the Knowledge Base of each BMC IM instance to use the user-defined policy.

“Defining the policy data class for a new policy type” on page 354

2 Define the presentation names that you want to appear in user interfaces for the policy type in a BMCIX.properties configuration file.

“Defining presentation names for a new policy type” on page 356

3 Create a new rule that defines the event processing done by the policy type and copy it to the Knowledge Base of each BMC IM instance to use the policy.

“Creating the event processing rule(s) for a new policy type” on page 357


Defining the policy data class for a new policy type

2 Define the new policy data class derived directly from the IM_BASE_CUSTOM_POLICY base class.

A Create the new class slots. You can create slots of these types:

■ ENUMERATION■ INTEGER■ STRING■ LIST OF

No other slot types are supported in custom event policies.

B Define the class slots in the order that you want them to appear in the BMC IX Custom Policy Type panel.

The BMC IX Custom Policy Details panel created from the policy type will have a field for each slot added to the IM_BASE_CUSTOM_POLICY class. The interface fields appear in the same order as the slots are defined in the class definition.

See the BMC Impact Solutions: Knowledge Base Development Reference Guide for detailed information on creating new classes.

3 Save the edited file after defining the new policy type (data class).

4 Add and entry for the new file that you created to the compiler load list in the .../kb/class/.load file after the entry for the ../kb/class/im_policies.baroc file.which contains the base policy data class that the new policy type references.

5 Recompile the BMC Impact Manager instance’s Knowledge Base (KB) after defining the new policy data class.

For more information on compiling a KB, see “Compiling a Knowledge Base” in the BMC Impact Solutions: Knowledge Base Development Reference Guide.

6 Finally, you must copy the changed KB to every BMC Impact Manager instance (cell) that will use the new policy.

Verifying that you created the class successfully

If you created the class successfully, you should be able to see it in the “By Policy” list and the “Custom Policy Details” panel.

Where to go from here

Next, define user-friendly presentation names to appear in the user interface for the policy type and its slots.


Defining presentation names for a new policy type

Defining presentation names for a new policy type

If you want user-friendly presentation names to appear in the user interface for the policy type and its slots instead of the internal names, you must:

■ define presentation names for the policy type in a resource file■ list the resource file for the policy type in the BMC IX.properties file

To define presentation names for a policy type

1 Create a resource file for the policy type to list the policy type and each slot with its assigned presentation name. The resource file name must have the .properties file extension.

2 Edit the resource file to add an entry for each presentation name assignment.

A To define the presentation name (label) for the policy type, add a line with the following format to the resource file:

B To define the presentation name (label) used for a slot, add a line with the following format to the resource file.:

3 Place the resource file in the .../console/lib/lang/kbinfo directory.

A Add the base name of the resource file to the value of kb_info_resources parameter in the BMC Impact Explorer .../console/etc/ix.properties file using this format:

The defined presentation names will display in the BMC Impact Manager Event Management Policies tree, the Policy Type picker window, and in the Policy List panel. Any slot or policy type for which a presentation name is not defined displays its internal name.

The event policy details tab for all user-defined policy types is Custom Policy Details.

CLASS.<policy type name>=<policy type presentation name> Policy

SLOT.<policy type name>.<slot name>=<slot presentation name>

kb_info_resources=<resource file name>,kb_core_resource, kb_deprecated_resource


Creating the event processing rule(s) for a new policy type


Before you can define an event policy based on the user-defined policy type that you created, you must:

■ create a new Knowledge Base rule or rules to define the event processing done by the policy type

■ copy the rule or rules to the Knowledge Base of each BMC IM instance on which the user-defined policy will run

Event Processing Rule Requirements

The event processing rule or rules that you define for the new user-defined policy type must:

■ do dynamic selection (use the using_policy clause)■ reference the policy data class that describes the new policy type

To create the event processing rule for a new policy type

1 , Add a new file in the .../kb/rules directory, for example, my_policies.mrl, for the new event processing rule or rules for the new policy type.

2 Edit the policy MRL file and write the event processing rule for the appropriate rule phase.

For more information, see

■ “Evaluation order of event policy types” on page 269 ■ “Understanding event processing rules (MRL) for policy types” on page 352■ See the MRL for the pre-defined policy types in ...\kb\rules\im_internal.mrl file.

3 Add the file name for the new rule or rules to the compiler load list in the .../kb/rules/.load file.

4 Compile the BMC Impact Manager instance’s Knowledge Base (KB) after defining the rule for the policy type.

For more information on compiling a KB, see BMC Impact Solutions: Knowledge Base Development Reference Guide.

5 Copy this KB change to every BMC Impact Manager instance (cell) that will use a policy based on the new policy type.



The definition of the policy type is complete and users can now create policies based on it in the Custom Policy Type panel.


C h a p t e r 14
14 Building event groups and image views
This chapter describes event groups and image views and explains how administrators create them for use by operators. This chapter presents the following topics:

Understanding event groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360Types of event groupings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360Event group configuration files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361Event tree hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362Event tree objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

Understanding image views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363Planning event groups and image views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364Working with event groups and image views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365

Creating an event group (event tree top-level) node . . . . . . . . . . . . . . . . . . . . . . . 365Creating an event group subnode (event tree node) . . . . . . . . . . . . . . . . . . . . . . . 366Deleting an event group subnode (event tree top-level node) . . . . . . . . . . . . . . . 367Hiding a collector in an event group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367Showing a hidden collector in an event group . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368Putting an event group into production or development . . . . . . . . . . . . . . . . . . . 368Adding a custom image view to an event group . . . . . . . . . . . . . . . . . . . . . . . . . . 369

Granting user access to event groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371


Understanding event groups

Understanding event groupsThe Event Groups tab on the Events view of BMC Impact Explorer allows you to create and control access to the event groups and their image views that IT operators use to monitor and manage events.

Event groups allow the organization of cells and collectors to make event displays meaningful for operators. For example, you might create an event group for collectors that gather database warning events and allow only operators that are database administrators access to that event group. Event groups are displayed in a hierarchical navigation tree. Although some of the objects displayed in the tree are unique to event groups, other objects are common across all three event management tabs on the Events tab of the BMC Impact Explorer. The remainder of this section provides more detail about the navigation tree and its objects.

Types of event groupings

In BMC Impact Explorer, events can be grouped or organized in these ways:

■ event collectors--an event list, a meaningful grouping of events or events grouped by their relationships

■ MetaCollectors--a grouping of events from several different event lists (collectors), showing their combined status

■ event groups--a hierarchy of event lists

■ image views--a graphical representation of the collectors in an event group

Event collectors

Event collectors group events for display in an event list to provide operators with meaningful groups of events and to show relationship through the hierarchy of the nodes in the tree. To access the event list for a collector, operators click the collector node in the navigation tree.

NOTE Unlike metacollectors, which operators can define themselves in BMC Impact Explorer, only administrators create event groups and image views.



Event collectors are dynamic or static. Nodes for dynamic collectors appear or disappear from the navigation tree based on whether or not events are present that meet the collectors’ criteria. Nodes for static collectors remain in the navigation tree whether events are present or not.

MetaCollectors

A MetaCollector is a grouping of collectors. Operators create MetaCollectors to view events from several event lists. Each event list is shown as a tab in the event list pane. The MetaCollector node represents the state of the combined events. MetaCollectors are often used to view collectors from multiple cells in the network.

Event groups

An event group is another way for showing the relationship of events through the hierarchy of the navigation tree. Service administrators and managers define event groups and associate them with one or more collectors. Each level of the collector is shown as a node under the event group. An event list is associated with the lowest level nodes of an event group. The parent level of an event group represents all of the events associated with the collectors and it is associated with an image view.

Image views

An image view is a graphical representation of the collectors in an event group. The collectors are represented by objects that can be placed on a background image. The objects can be graphics, such as icons; statistical information, such as the number of events by priority or by severity; or text, such as a label.


The event group configuration file structure is listed in Table 82:

Table 82 Event group configuration files (part 1 of 2)

Folder Contains

\Images Backgrounds and Icons directories

\Images\Backgrounds background image files that are shared by all Map definitions

\Images\Icons image files which are shared by all Map definitions

\Map event group tree node template MapObjectTemplate.xml

\Map event group default image view configuration DefaultMapPage.xsl

\Map Map tree definition Maps.xml


Event tree hierarchy

Event tree hierarchy

Event groups are displayed in a hierarchical tree, the event tree, in the navigation pane of the Event Groups tab, as shown in Figure 91. Although administrators see all the event groups they create in the event tree, operators viewing the event tree see only those event groups to which they are granted access.

Figure 91 Event tree hierarchy

Event groups appear as event tree top-level nodes. Beneath event tree top-level nodes you can add event tree nodes (child nodes of event groups) to further organize event tree display. To event tree top-level nodes and event tree nodes you can add collectors and subcollectors which represent, cells, collectors, and subcollectors. Use the Event Group Editor to create and modify the event group hierarchy to organize the display of these objects.

Event tree objects

Table 83 shows the icons and descriptions of the objects represented in the event tree.

\Map\Map_xxx Map.xml for Map_xxx as well as its MapPages directory

\Map\Map_xxx\MapPages all map page definitions for Map Map_xxx

Table 82 Event group configuration files (part 2 of 2)

Folder Contains


Understanding image views

Additionally, each object icon in the event tree has an associated status, shown as an icon to the right of the object icon. For information about the statuses represented by each icon, see the BMC Impact Solutions: Event Monitoring.

Understanding image viewsImage views provide operators with a graphical representation of the aggregated state of the event groups they represent. Administrators create image views by dragging and dropping an image view object, called a widget (shown in Figure 92 on page 363), onto a background image. Each widget represents a group node, collector, or child collector from the event tree.

Figure 92 Image view widgets

Table 83 Event tree objects and definitions

Objecticon Name and definition

event tree top-level node in production status; the top-level node of an event group that is in production status, making the Event Group Editor and Image View Editor unavailable for the event group

event tree top-level node in development status; the top-level node of an event group that is in development status, making the Event Group Editor available for the event group

event group node; an event group subnode of an event tree top-level node or another event group node

child collector node; displays information from a collector or subcollector of a cell or collector added as a collector node

subcollector node; child node of a collector node

image view widgets


Planning event groups and image views

All event tree nodes with children (event tree top-level nodes, event group nodes, and collector nodes with child collectors) have either a default image view or a custom image view. All such nodes initially display a default image view that contains a blank background and a widget for each child node, as shown in Figure 92. Administrators create custom image views by adding an imported image (for example, a map of a geographical region or a diagram of the IT system of an enterprise) to replace the blank background of a default image view and by arranging widgets representing some or all of the child odes on the background, as shown in Figure 93.

Figure 93 Custom image view

Planning event groups and image viewsPlanning is essential to creating event groups and image views that logically and efficiently depict IT assets of your enterprise. Before creating event groups and image views, consider these guidelines:

■ Event groups and image views organize and represent the contents of collectors Consequently, you should carefully plan and create the collectors for your enterprise. Event groups and image views can provide no more information than that gathered by collectors. (Collectors must be created before the event groups that use them. For more information about collectors, see the BMC Impact Solutions: Knowledge Base Development Reference Guide.)

■ Creating event groups by using static collectors allows you to create the event groups before you run the event management system in a test or production environment. However, this practice can require a significant amount of manual work depending on the number of event groups you create.


Working with event groups and image views

■ Creating event groups by using dynamic collectors requires less manual work than using static collectors, but the event groups do not exist until cells receive events to populate the dynamic collectors.

Working with event groups and image viewsThis section provides instructions for creating event groups and adding associated nodes that make up an event tree. This section also provides instructions for defining custom image views for event groups.

Creating an event group (event tree top-level) node

Use the Event Groups tab to create an event group.

To create an event group (event tree top-level node)

1 On the menu bar of the Event Groups tab of the Events tab view, choose Edit => Add Event Group.

The Event Group Editor, shown in Figure 94, is displayed.

Figure 94 Event Group editor

NOTE Event groups are a prerequisite for image views. You must first create an event group to which you then add an image view.


Creating an event group subnode (event tree node)

2 On the Available Collectors pane, select a cell, collector, or subcollector to add to the new event group.

3 On the Event Group pane, select NewEventsGroup.

4 To add the selected collector in the Available Collectors pane to the new event group in the Event Group pane, click the right arrow.

The selected collector appears beneath the new event group in the Event Group pane.

5 To add another collector (or cell or subcollector) to the new event group, select the additional collector from the Available Collectors pane and click the right arrow.

Repeat this step as necessary to add more cells, collectors, or subcollectors to the new event group.

6 To save the event group, click OK.

Creating an event group subnode (event tree node)

Use the Event Groups tab to create an event group subnode.

To create an event group subnode (event tree node)


The Event Group Editor is displayed.

2 On the Event Group pane, select NewEventsGroup and click Insert Group.

An event group subnode, NewGroup, is inserted beneath the NewEventsGroup node, as shown in Figure 95.

Figure 95 Event tree node addition

3 On the Available Collectors pane, select a cell, collector, or subcollector to add to the new event group subnode.


Deleting an event group subnode (event tree top-level node)

4 To add the selected collector in the Available Collectors pane to the new event group subnode in the Event Group pane, click the right arrow.

5 To add another collector (or cell or subcollector) to the new event group subnode, select the additional collector from the Available Collectors pane and click the right arrow.

Repeat this step as necessary to add more cells, collectors, or subcollectors to the new event group subnode.

6 To save the event group subnode, click OK.

Deleting an event group subnode (event tree top-level node)

Use the Event Groups tab to delete an event group subnode.

To delete an event group (Event tree top-level node)

1 On the event tree of the Event Groups tab, select an event group or any of its descendant nodes.

2 From the menu bar, choose Edit => Delete Event Group.

An action confirmation dialog box appears.

3 To delete the event group and its descendants, click OK.

Hiding a collector in an event group

Use the Event Group pane to hide a collector in an event group.

NOTE To delete an event group, it must be in development status. If the event group is in production status you must change the status before deleting it.

WARNING Deleting an event group deletes the entire event group and all its descendants, regardless of what node you select in the event group.


Showing a hidden collector in an event group

To hide a collector in an event group

1 In the Event Group pane, select a collector node.

2 Click Hide.

A lock icon is displayed with the node to show that the collector will not appear in the production event group. Event information from the collector and any subcollectors are still aggregated by the event group it appears in.

Showing a hidden collector in an event group

Use the Event Group pane to show a hidden event group.

To show a hidden collector in an event group

1 In the Event Group pane, select a hidden collector node.

2 Click Show.

The collector now appears in the production event group.

Putting an event group into production or development

Use the Image Group Editor to put an event group into production or development.

To put an event group into production or development


The Event Group Editor is displayed.

2 In the Event Group navigation pane, select an event group.

3 Click the appropriate Status radio button.

4 Click OK to save your change.


Adding a custom image view to an event group


Use the Image View Editor to add a custom image view to an event group.

Before you begin

Custom image views require files in .jpg or .gif format for use as background images and icon images. To make these images available to the Image View Editor, copy the files to the Backgrounds directory and the Icons directory in the $BMCPORTAL_HOME/appserver/websdk/tools/jboss/server/all/data/smsConsoleServer/ Image/Background directory on the system running BMC Impact Portal.

To add a custom image view to an event group

1 From the event tree of the Event Groups tab, select the event group (an event tree top-level node).

2 From the menu bar, choose Edit => Edit Image View.

The Image View Editor is displayed. The Image View Editor shows the current, default image view.

3 To create a custom image view, click Use Custom.

4 To add a custom image view background, from the View tab click the Filename list and select an image file.

NOTE If two administrators have the same event group open and one administrator changes the status of the event group from development to production, the properties of the event group will not be protected and the other administrator will be able to edit the properties of the event group.

Image view objects become disabled after editing the event group.

NOTE An event group must be in development status to add a custom image view. If the event group is in production status you must change the status before adding the image view.

Custom image view still displays an event group or collector object that was deleted using the Event Group Editor.



The selected image file appears in the image pane of the Image View Editor, as shown in Figure 96. If no image file is available from the list, see “Before you begin” on page 369 before the start of this procedure.

Figure 96 Image View editor

5 To place the widgets representing collectors for the event group, drag and drop the widgets onto the image view background.

When you drag and drop a widget, the Selected Object tab is enabled for the widget. Use the controls on this tab to modify the appearance of the widget on the image view background.

6 To save the custom image view and close the Image View Editor, click Save Custom Image & Close.

NOTE You should choose contrasting widget fill colors and custom image canvas colors. Some color combinations can result in text that cannot be seen. For example, if the widget fill color is set to transparent and the custom image canvas color is set to white, white letters that appear on the widget cannot be seen against the white canvas.

image view widgets


Granting user access to event groups

The saved image view is displayed in the Event Groups tab.

Granting user access to event groupsAdministrators grant operators access privileges for event groups using the Event Group Properties editor. The Event Group Properties editor controls access to and the status of each event tree top-level node.

To grant user access to event groups

1 From the event tree of the Event Groups tab, select an event group (an event tree top-level node).

2 From the menu bar, choose Edit => Edit Event Group Properties.

The Event Group Properties editor, shown is displayed.

3 (optional) Add a text description of the event group.

4 Modify the Read and Write permissions to grant or deny access for each group as necessary. When complete, click OK.

BMC Impact Explorer saves the access settings for the selected event group.

TIP To modify the appearance of widgets that appear on a default image view, edit the object appearance attributes in the file defaultmappage.xsl located in the BMCPORTAL_HOME\appserver\websdk\tools\jboss\server\all\data\smsConsole Server directory on the system running BMC Impact Portal. The file contains comments that identify the appearance attributes.


Granting user access to event groups


3Part

Part 3AppendixesThis part presents the following topics:

Appendix ATrouble-shooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375

Appendix BBMC SIM and EM CLI Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381

Appendix Cmcell.conf file parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443

Appendix DEnvironment variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465

Appendix EBMC Microsoft Windows services and UNIX processes. . . . . . . . . . . . . . . . . . . . . 469

Appendix FBMC Impact Event Adapters MAP files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473

Appendix GIP Adapters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489

Appendix HBMC Impact Event Adapters parsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505

Appendix IBackend processes for publishing and unpublishing MIB files . . . . . . . . . . . . . . . 517

Part 3 Appendixes 373

A p p e n d i x A
A Trouble-shooting
This appendix presents the following topics:

Trouble-shooting BMC Impact Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375Problem: The cell will not start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375Problem: The primary and secondary servers for my high availability cell are in

active mode simultaneously or are unsynchronized. . . . . . . . . . . . . . . . . . . . . 376Trouble-shooting event management policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

Problem: The policy is not running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377Problem: The notification policy is configured to generate a notification email,

but no email is being sent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378Problem: I receive an invalid data error when running a dynamic data

enrichment policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378Problem: I receive an error message when running a dynamic data enrichment

blackout policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379Trouble-shooting tools for dynamic data enrichment policies . . . . . . . . . . . . . . . 380

Trouble-shooting BMC Impact Manager

Problem: The cell will not start

If there is nothing in the log trace files to help you diagnose the problem, try running the cell in the foreground. This will frequently provide the information needed to correct the problem or enough information for BMC Support to diagnose the problem. To run the cell in the foreground, enter:

mcell –n {cell_name} –d


Problem: The primary and secondary servers for my high availability cell are in active mode simultaneously or are

Possible solution: Delete the mcdb file

If the cell has been running previously, it is likely that the mcdb file is corrupted. To correct this problem, follow these steps:

1 Back up the current mcdb file (located at MCELL_HOME\log\cellName).

2 Delete the original mcdb file from MCELL_HOME\log\cellName.

3 Restart the cell.

The cell will create a new mcdb file when it is restarted.

Problem: The primary and secondary servers for my high availability cell are in active mode simultaneously or are unsynchronized.

This problem can occur when the primary and secondary servers are running on a network that does not have a reliable connection, if you have started a high availability cell using any of the -i initialization options (for example, -ia, -id or other variants), or if the primary server was started first and terminates before the secondary server is started.

Possible solution: Synchronize the mcdb and xact files of the primary and secondary servers

Follow these steps to correct the incompatible states between the primary and secondary servers:

1 If the problem was caused by an unreliable network, resolve the network issue.

2 Shut down both cell servers

3 Copy the mcdb and xact files of the preferred server to the other server. (The preferred server can be either primary or secondary.)

4 Restart both servers.

NOTE Transactions can be lost when the mcdb is deleted. The new mcdb will only hold the transactions in the xact file at the time the cell is started.


Problem: There are two notification objects from the Impact Portal in the cell.

Problem: There are two notification objects from the Impact Portal in the cell.

There should only be one notification object from the Impact Portal per cell. Perform the following steps to clean up the objects:

1 Edit the mcell.conf file to uncomment the ServiceModelPublish parameter and set its value to No.

2 Obtain a list of all of the notification objects for the cell by entering the following command:

mquery -n <cellname> -d -f baroc -a SIM_NOTIFICATION_REGISTRY

A list of notification objects is displayed.

3 Note the data_handles for each notification object.

4 To delete each notification object, follow these steps for each notification object:

A From a command line, enter: mposter -n cell_name -d

B Then enter: ddelete notification_data_handle ; END

C Then enter Ctrl C: ^C

Trouble-shooting event management policiesThis section lists some common problems encountered with event management policies and some tools to assist you trouble-shoot problems not listed here.

Problem: The policy is not running

If the policy is not running, try the following:

■ Access the Policy Details tab for the policy and ensure that the Enabled check box is selected.

■ (Dynamic data enrichment policies only) Access the Policy Details tab for the policy and ensure that the Match Fields and Output Fields contain the exact same number of match fields in the same order as the associated data enrichment source file.


Problem: The notification policy is configured to generate a notification email, but no email is being sent

■ (Dynamic data enrichment policies only) Ensure that you have imported the data from the data enrichment source file into the cell using the Import tab.

Problem: The notification policy is configured to generate a notification email, but no email is being sent

When the product is installed, part of the installation process locates the SMTP server. If an SMTP server is not installed before the product installed, the email notification will not be able to send an email. If you installed an SMTP server after the product was installed, follow these steps to allow the product to recognize the SMTP server:

1 Download and install the blat utility. (This utility is public domain.)

2 From a command line, run mc_setup_mail.cmd.

3 Run blat and specify the name of the mail server and the name that you want to appear in the From line of the notification email.

Problem: I receive an invalid data error when running a dynamic data enrichment policy

Access the Policy Details tab for the policy and ensure that the Match Fields and Output Fields contain the exact same number of match fields in the same order as the associated data enrichment source file.

Figure 97 shows an example error message generated by dynamic data enrichment policy that has a mismatch between the match and output fields defined in the policy and the number of columns included in the enrichment data source file.


Problem: I receive an error message when running a dynamic data enrichment blackout policy

Figure 97 Invalid data error: dynamic enrichment policy

Problem: I receive an error message when running a dynamic data enrichment blackout policy

Ensure that the timeframe defined in the data source enrichment file actually exists. For information on creating valid timeframes, see “How to create a new local timeframe” on page 274.

Figure 98 shows an example error message generated by dynamic blackout policy that has an invalid timeframes.

Figure 98 Invalid timeframe error: dynamic blackout policy


Trouble-shooting tools for dynamic data enrichment policies

Trouble-shooting tools for dynamic data enrichment policies

You can use the following methods to trouble-shoot the dynamic data enrichment policies that you have defined:

■ Enable the Match Tracing check box in the Dynamic Enrichment Policy Details tab to to add diagnostic notes to the event.

■ Access the History tab and check the Operations Log to determine which dynamic data enrichment policy added the information into the event.


A p p e n d i x B
B BMC SIM and EM CLI Reference
This appendix provides reference information on the BMC Impact Solutions and BMC Impact Portal command line interfaces (CLI) and their configuration. It contains the following topics:

BMC Impact Manager CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382BMC Impact Manager CLI common command options . . . . . . . . . . . . . . . . . . . . 383BMC Impact Manager CLI common return codes . . . . . . . . . . . . . . . . . . . . . . . . . 384mccomp—Compiling rules in the Knowledge Base. . . . . . . . . . . . . . . . . . . . . . . . 385mcell—Starting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386mcfgtrace—Configuring tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389mclassinfo—Requesting class information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390mcollinfo—Getting information about a specific collector . . . . . . . . . . . . . . . . . . 396mcontrol—Performing cell control operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398mcrtcell—Creating a new cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401mcstat—Returning cell status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405mdelcell—Deleting a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406mgetinfo—Retrieving information about a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . 408mgetrec—Obtaining a global record value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412mkb—Updating the Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414mkill—Stopping a cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417mlogchk—Performing consistency checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418mpkill—Stopping mposter and msend server processes . . . . . . . . . . . . . . . . . . . 420mposter and msend—Managing data, global records, and events . . . . . . . . . . . 422mquery—Retrieving objects from a cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427mrecover—Recovering from a catastrophic data loss . . . . . . . . . . . . . . . . . . . . . . 432mrextract—Extracting cell state files to create new state files . . . . . . . . . . . . . . . 434mrmerge—Merging event objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436msetmsg—Modifying an event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437msetrec—Setting the value of a global record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439BMC Impact Manager CLI configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440Configuring tracing for BMC Impact Manager CLI commands . . . . . . . . . . . . . 442BMC Impact Manager CLI trace configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 442


BMC Impact Manager CLI commands

BMC Impact Manager CLI commandsUse the commands from the command line interface (CLI). All of the cell-related CLI commands are located in MCELL_HOME/bin. You can invoke the commands from a command prompt on Microsoft Windows, from a UNIX prompt, or from a script. A command can affect the cell, the Knowledge Base, or other files.

Table 84 lists all of the available BMC Impact Manager commands along with a brief description of the purpose for each command.

Table 84 BMC Impact Manager CLI command descriptions

Command Description Page

mccomp compiles rules in the Knowledge Base 385

mcell starts a cell 386

mcfgtrace modifies tracing configuration of a running cell 389

mclassinfo obtains class information from a cell 390

mcollinfo obtains collector information from a cell 396

mcontrol performs control operations on a running cell 398

mcrtcell creates a new cell 401

mcstat returns the status of a cell 405

mdelcell deletes a cell 406

mgetinfo retrieves information about a running cell 408

mgetrec retrieves the content of a global record 412

mkb views/updates the Knowledge Base 414

mkill stops a cell 417

mlogchk performs consistency checks 418

mposter sends or manipulates data, records, and events 422

mrecover recovers catastrophic loss of data 432

mrextract extracts cell state files to create new state files 434

mrmerge merges extracted cell state files 436

mquery retrieves objects from a cell 437

msend sends an event to a cell 437

msetmsg modifies an event in a cell 437

msetrec sets the value of a global record 439


BMC Impact Manager CLI common command options

BMC Impact Manager CLI common command options

Many commands use the same options that perform the same functions in each command. Additional options that are specific to the command are listed in the section of this appendix that is dedicated to that command.

Table 85 describes the common command options that apply to all commands.

Using the -n option

To interact with another cell, a cell uses the mcell.dir file, which maps cell names to a host name or to an IP address and port. With CLI commands, you can use the -n option to specify a cell by using either of the following formats that are used in the mcell.dir file:

■ Designate a cell name by specifying -n cellName.

This format maps the cellName to the host, port, and encryption key in the mcell.dir file.

NOTE A few commands have command-specific options that override the common CLI command options listed inTable 85. For example, the -p option for the mkb command prints the contents of the designated manifest.kb file, rather than assigning the specified value (Value) to the option Var. If a command has an option that overrides the common option, the command-specific option is noted in the section of this appendix dedicated to that command.

Table 85 Common options for CLI commands

Option Description

-c ConfigFile specifies a configuration file to use instead of the default MCELL_HOME\etc\mclient.conf file

-hor-?

displays help information, including syntax and options

-l HomeLocation specifies home directory (HomeLocation) for the command if it is not specified with MCELL_HOME

-n cellName or-n @Host[/Port[#Key]]

starts the cell named cellName (as defined in mcell.dir). For more information, see “Using the -n option”.

-p Var=Value assigns the specified value (Value) to the option Var

-q invokes quiet execution (no banner appears)

-v activates verbose mode to display more information

-z displays version information


BMC Impact Manager CLI common return codes

■ Designate the host, port, and encryption key by using -n @Host[/Port[#Key]], where

— Host is either a host name or an IP address— Port is the port number— Key is the encryption key

The importance of setting a valid encryption key when using the -n option

If you do not specify Key or Key and Port, the default values are applied. The default value for Key is 0, and the default value for Port is 1828.

Accepting the default value for Port means that your cell has to listen on port 1828, which is normally the case with the default installation procedure.

When BMC Impact Manager is installed, the default installation procedure sets Key to mc, instead of 0. Unless you change the encryption key to 0 during installation or afterwards by manually editing the $MCELL_HOME/etc/mcell.dir file, you need to specify the Key explicitly. Otherwise, if you do not specify the Key, the CLI will not be able to connect to the cell.

For security purposes, you should set Key to a valid value other than the default.

BMC Impact Manager CLI common return codes

Table 86 describes the return codes common to all CLI commands. Some CLI commands have return codes that are specific to that command. If a CLI command has command-specific return codes, those codes are listed in the section of this appendix dedicated to that command.

Table 86 Common return codes for CLI commands

Code Description

0 success

1 bad usage (command includes nonexistent options or an invalid combination of options and arguments)

10 initialization failure

11 trace initialization failed

12 configuration initialization failed

13 outbound communication setup failed

14 inbound communication setup failed

15 message handling initialization failed

16 persistency setup failed


mccomp—Compiling rules in the Knowledge Base

mccomp—Compiling rules in the Knowledge Base

The mccomp command is the executable that calls the Knowledge Base compiler. The only required command option is the path to the manifest.kb file.

mccomp syntax

Figure 99 shows the syntax for mccomp.

Table 87 lists the command-specific options for mccomp. For a list of common command options that apply to all CLI commands, see “ BMC Impact Manager CLI common command options” on page 383.

17 port range limitation failed

20 connection to cell failed

25 memory fault

26 command failed

27 syntax error

28 invalid answer received

Figure 99 mccomp syntax

mccomp [-h|?] [-z] [-t] [-v [VERBOSE|INFORM|WARNING|ERROR|FATAL]] [-e ErrorLogFile] [-p prefix] [-n CellName | ManifestKBFilePath]

Table 87 mccomp options

Option Description

-e ErrorLogFile redirects error messages to a user-specified file; used primarily in scripts

-n CellName | ManifestKBFilePath

specifies to use $MCELL_HOME/etc/CellName/kb/manifest.kb as the KB manifest file.

This option is ignored if ManifestKBFilePath is specified explicitly.

-p prefix Creates a package named prefix.pkg

-t generates tracing calls in the resulting compiled files for debugging purposes. For more information, see “ mccomp example” on page 386.

- v [VERBOSE|INFORM|WARNING|ERROR|FATAL]

sets the verbosity level of messages. Only messages of the specified level or higher are printed. If -v is not used, the default level is INFORM. If -v is used without specifying a level, the default level is VERBOSE.

Table 86 Common return codes for CLI commands

Code Description


mcell—Starting a cell

The -t option enables extra cell runtime tracing by the rules engine if the cell configuration parameter TraceRuleLevel=2. The trace output goes to the standard cell trace in the RULES module. You can include the output in the transaction file by setting TraceRuleToXact=Yes.

mccomp example

Figure 100 shows an example of mccomp.

This command produces output similar to the example shown in Figure 101.

mccomp return codes

There are no command-specific return codes for mccomp. For a list of common return codes that apply to all CLI commands, see “ BMC Impact Manager CLI common return codes” on page 384.


The mcell command starts a specified cell.

mcell syntax

Figure 102 shows the syntax for mcell.

WARNING A Knowledge Base compiled for runtime rule tracing using -t can experience considerable runtime performance degradation.

Figure 100 mccomp example

mccomp -n cell1

Figure 101 Example output for mccomp

Parsing BAROC file classes/root.barocParsing BAROC file classes/intevt.barocCompilation ended successfully

Figure 102 mcell syntax

mcell [-h|-?] [-z] [-q] [-d] [-i [a][c][d][e]] [-r] [-n cellName] [-l HomeLocation] [-c ConfigFile] {-p "Var=Value"}



Table 88 lists the command-specific options for mcell. For a list of common command options that apply to all CLI commands, see “ BMC Impact Manager CLI common command options” on page 383.

mcell example

On UNIX, mcell can be started from a command prompt as a daemon (running in background) or as a terminal program (running in foreground).

On Microsoft Windows, mcell can be started from a command prompt as a service or as a terminal program.

You can start the cell using any of the following methods:

■ To start the cell in the foreground rather than as a service or daemon on UNIX and Microsoft Windows platforms, type the command shown in Figure 103.

Table 88 mcell options

Option Description

-c specifies a configuration file other than the default. If -c is used, all configuration files are assumed to be in the directory in which the specified configuration file is located.

-d runs in foreground instead of as a service or daemon

-i initializes the cell repository; can combine with suboptions:

■ -i—-ied■ -ie—events■ -id—data--initializes all data■ -ic—EventCounter■ -ia—-iedc—initializes all data

Warning: Unexpected cell states can occur if you initialize only events or only data, because events and data may be correlated.

-r runs in cell recovery mode

Figure 103 Starting a cell

mcell -n cellName -d

NOTE When starting BMC Impact Solutions software as a daemon process on UNIX platforms, use the method described in “ Stopping or starting a cell on UNIX computers” on page 40.



■ To start the cell as a service on a Microsoft Windows platform, type the command shown in Figure 104.

When started from command prompt without the -d option, mcell contacts the Service Control Manager to start itself as a service. It uses mcell_cellName as the service name, with the cell name as specified with the -n option. Without the -n option, the host name is taken as cellName.

■ To start the BMC Impact Solutions service on Microsoft Windows and initialize the dynamic data in the cell, type the following command shown in Figure 105.

mcell return codes

Table 89 lists the command-specific return codes for mcell. For a list of common return codes that apply to all CLI commands, see “ BMC Impact Manager CLI common return codes” on page 384.

Figure 104 Starting a cell as a service on windows

: net start mcell_cellName

Figure 105 Starting the BMC Impact Manager service on Microsoft Windows

net start mcell_cellName -ia

WARNING If you start a cell with the mcell -ia or mcell -id commands, you must re-register the cell with the BMC Portal.

Table 89 mcell return codes (part 1 of 2)

Code Description

2 bad home directory option usage

3 no home directory specified

4 invalid home directory specification

5 application system initialization failed

19 logging facility initialization failed

29 Knowledge Base load failed

37 message handling module initialization failed

39 internal object initialization failed

47 event processing module initialization failed

49 save state reload failed

57 query handling module initialization failed

59 service activation failed


mcfgtrace—Configuring tracing

mcfgtrace—Configuring tracing

The mcfgtrace command modifies the tracing configuration of a running cell and takes the same argument format as a line in the mcell.trace file.

See “ BMC Impact Manager CLI trace configuration” on page 442 for instructions on setting up CLI trace configuration files.

mcfgtrace syntax

Figure 106 shows the syntax for mcfgtrace.

The -n option is required if the cell is remote or if cellName differs from HostName. See “ Using the -n option” on page 383 for more information.

Table 90 lists the command-specific option for mcfgtrace. For a list of common command options that apply to all CLI commands, see “ BMC Impact Manager CLI common command options” on page 383.

mcfgtrace parameters

Table 91 lists the parameters for mcfgtrace.

67 internal event module initialization failed

69 metrics initialization failed

77 data processing module initialization failed

79 metrics activation failed

97 service setup failed

Figure 106 mcfgtrace syntax

mcfgtrace [-h|-?] [-z] [-q] [-c ConfigFile] {-p "Var=Value"} [-n cellName|-n @Host[/Port[#Key]]] [-l HomeLocation] [-v] (Module Level Destination| Module SWITCH Switch Destination)

Table 90 mcfgtrace option

Option Description

Module Level Destination See “ mcfgtrace parameters” on page 389.

Table 89 mcell return codes (part 2 of 2)

Code Description


mclassinfo—Requesting class information

mcfgtrace example

To activate maximum tracing for all modules and send the output to the file all.trace in the temporary directory for Cell1, which is by default MCELL_HOME\tmp\Cell1, type the command shown in Figure 107.

mcfgtrace return codes

There are no specific return codes for mcfgtrace. See “ BMC Impact Manager CLI common return codes” on page 384 for a list of common return codes that apply to all CLI commands.


The mclassinfo command retrieves class information about both event and data classes that are loaded in the cell. Information consists of class name, slot descriptions, and subclasses.

You can retrieve the complete class tree in a hierarchical form, or you can retrieve only selected classes, instead of the whole hierarchy.

You can retrieve associated definitions of enumerations used in the classes. These definitions are reported before the class tree.

Table 91 mcfgtrace parameters

Parameter Available values

Module ALL | Module

Level ALL | VERBOSE | INFORM | WARNING | ERROR | FATAL

SWITCH SwitchName

Destination no | stderr | console | DestinationFileName

Figure 107 mcfgtrace example

mcfgtrace -n Cell1 ALL ALL '%T/all.trace'



mclassinfo syntax

Figure 108 shows the syntax for mclassinfo.

Table 92 lists the command-specific options for mclassinfo. For a list of common command options that apply to all CLI commands, see “ BMC Impact Manager CLI common command options” on page 383.

mclassinfo output

You can request output in raw format for parsing by a program. You can also request standard output formatted for users, including verbose output that provides additional information. See Table 92 for the available options.

Raw output format

The output consists of the class tree, optionally preceded by the enumeration definitions, as shown in Figure 109. The enumeration definitions are reported as EnumInfo.

Figure 108 mclassinfo syntax

mclassinfo [-h|-?] [-z] [-q] [-c ConfigFile] {-p "Var=Value"} [-n cellName | -n @Host[/Port[#Key]]] [-1 HomeLocation] [-v][-a Amount] [-d] [-e] [-x] [-u] [-r][-o OutputFile] [{Class}]

Table 92 mclassinfo options

Option Description

-a Amount specifies the amount of information: 0, 1, 2, 3 (See “ Information amount” on page 393); default is 2

-d reports data class definitions instead of event class

-e reports enumeration definitions used in the classes

-o OutputFile produces the output in a file called OutputFile, instead of using standard output

-r produces raw output for programs

-u reports unique slots only, excluding redefined slots in subclasses

-x reports enumeration definitions only (exclude classes)

Class names of selected classes

Figure 109 Raw output format for mclassinfo

EnumInfo = EnumTypeCount (EnumTypeInfo)*EnumTypeCountEnumTypeInfo = EnumTypeName EnumValCount (EnumValName)*EnumValCount



The class tree is reported depth-first, left-to-right, as ClassInfo, as shown in Figure 110.

Slot value types (ClassSlotValType) are encoded by two characters. The first one indicates whether it is a simple slot (S) or a list (L). List slots are defined in BAROC as LIST_OF. The second character determines the type of the slot value. It corresponds to the BAROC definition as listed in Table 93.

A slot representation type (ClassSlotRepType) corresponds to the representation facet of the slot. If that facet is not specified, it is reported as an asterisk (*).

Flags contain Boolean facets of the slot. For every facet, one character is reported. An uppercase character means the facet is TRUE; a lowercase character means it is FALSE. Table 94 lists the facets that are reported.

Figure 110 Class tree for mclassinfo

ClassInfo = ClassCompCount(ClassCompInfo)*ClassCompCountClassCompInfo = ClassName ClassFlags ClassSlotCount

(ClassSlotInfo)*ClassSlotCount ClassInfoClassSlotInfo = ClassSlotName ClassSlotValType ClassSlotRepType

ClassSlotFlags ClassSlotDefaultValueLength ClassSlotDefaultValueText

ClassSlotValType = ClassSlotStructCode ClassSlotTypeCodeClassSlotStructCode = S | LClassSlotTypeCode = i | r | p | s | e:EnumerationTypeName

| c | c:BaseClass| q | q:BaseClass

ClassSlotFlags = (r|R) (k|K) (p|P) (d|D) (h|H)

Table 93 Type of slot value for mclassinfo

Slot Type Definition

i INTEGER

r REAL

p POINTER

s STRING

e;EnumerationTypeName Enumeration

c:BaseClass ECF of BaseClass

q:BaseClass QUERY of BaseClass

Table 94 Reported facets

Facet Function

r|R read_only

k|K key

p|P parse



Standard output format

Standard output format is formatted for end-users but does not report the counts and represents the tree structure through indentation.

Information amount

The amount of reported information is limited as shown in Table 96.

mclassinfo examples

mclassinfo can be used as shown in the following examples.

Obtaining a list of classes

To obtain a list of classes used by a cell named grace, type the command shown in Figure 111.

d|D dup_detect

h|H hidden

Table 95 Class flags

Flag Function

p|P publishable class

Table 96 Information amount limitation options for mclassinfo

Option Description

-a 0 reports only class names; no slot information is reported

-a 1 reports slot names

-a 2 adds slot names and representation type (default)

-a 3 adds slot flags and default value

Figure 111 Example of mclassinfo command for a list of classes

mclassinfo -n grace -a 0

Figure 112 Example output of mclassinfo command for a list of classes (part 1 of 2)

Class: CORE_EVENTClass: MC_CELL_CONTROL

Table 94 Reported facets

Facet Function



Obtaining a List of Slot Names

To obtain a list of slot names used by a cell named grace, type the command shown in Figure 113.

Figure 114 shows an example of the output.

Adding Slot names and representation types

To add slots names and representation types for use by a cell named grace, type the command shown in Figure 115 on page 394.

Class: MC_CELL_STARTClass: MC_CELL_STOPClass: MC_CELL_TICKClass: MC_CELL_STATBLD_STARTClass: MC_CELL_STATBLD_STOPClass: MC_CELL_DB_CLEANUPClass: MC_CELL_CONNECT

Class: MC_CELL_CONNECT_RESOURCES_EXPANDEDClass: MC_CELL_CONNECT_SUSPENDEDClass: MC_CELL_CONNECT_RESUMED

Class: MC_CELL_CLIENT.

Figure 113 Example of mclassinfo command for list of classes


Figure 114 Example of mclassinfo command output for list of classes

Class: CORE_EVENTSlot: event_handleSlot: mc_ueidSlot: sourceSlot: sub_sourceSlot: hostnameSlot: origin...

Figure 115 Example of mclassinfo command for adding slot names


Figure 112 Example output of mclassinfo command for a list of classes (part 2 of 2)




Adding slot flags and default values

To add slot flags and default values for use by a cell named grace, type the command shown in Figure 117.


mclassinfo return codes

Table 97 lists the command-specific return codes for mclassinfo. For a list of common return codes that apply to all CLI commands, see “ BMC Impact Manager CLI common return codes” on page 384.

Figure 116 Example of mclassinfo command output for adding slot names

Class: CORE_EVENT -Flags: pSlot: event_handle - Type: INTEGERSlot: mc_ueid - Type: STRINGSlot: source - Type: STRINGSlot: sub_source - Type: STRINGSlot: hostname - Type: STRINGSlot: origin - Type: STRING

.

.

.

Figure 117 Example of mclassinfo command for adding slot flags


Figure 118 Example of mclassinfo command output for adding slot flags

Class: CORE_EVENT -Flags: pSlot: event_handle - Type: INTEGER - Flags: rkpd - Def: 0Slot: mc_ueid - Type: STRING - Flags: rkPd - Def:Slot: source - Type: STRING - Flags: rkPd - Def:Slot: sub_source - Type: STRING - Flags: rkPd - Def:Slot: hostname - Type: STRING - Flags: rkPd - Def:Slot: origin - Type: STRING - Flags: rkPd - Def:.

.

.

.

Table 97 mclassinfo return codes

Code Description

31 cannot read input file


mcollinfo—Getting information about a specific collector


The mcollinfo command retrieves information about collectors loaded in a cell. Information consists of collector name, permission settings, referenced classes and subcollectors. The complete collector tree is retrieved and reported in a hierarchical form. As an option, specific information about selected collectors can be retrieved instead of the whole tree.

mcollinfo syntax

Figure 119 shows the syntax for mcollinfo.


Table 98 lists the command-specific options for mcollinfo. For a list of common command options that apply to all CLI commands, see “ BMC Impact Manager CLI common command options” on page 383.

mcollinfo output

You can request output in raw format for parsing by a program. You can also request standard output formatted for users, including verbose output that provides additional information. See the preceding table for the available options.

Figure 119 mcollinfo syntax

mcollinfo [-h|-?] [-z] [-q] [-c ConfigFile] {-p “Var=Value”} [-n cellName | -n @Host[/Port[#Key]]] [-1 HomeLocation] [-v][-a Amount][-r] [-o OutputFile] ( -d | [-i] [-s] ( Collector | -f InputFile ) )

Table 98 mcollinfo options

Option Description

-a Amount specifies the amount of information (0, 1, 2); the default is 2. For more information, see “ Information amount” on page 393.

-d reports collector definitions

-f {InputFile} reads collectors from InputFile instead of from command line

-i reports collector object identifier (OID)

-o OutputFile produces the output in a file called OutputFile, instead of using standard output

-r produces raw output for programs

-s reports collector status and severity counters

Collector specifies the collector name or OID with optional + suffix for closure



Raw output format

Raw output consists of the collector tree, as shown in Figure 120 on page 397. The collector tree is reported depth-first, left-to-right, as CollInfo.


Standard output is essentially the same as raw output, but standard output does not report the counts. Standard output represents the tree structure through indentation.

By default, it reports permissions as a sequence of role numbers. Classes are reported as object identifiers (OIDs). In verbose-formatted output, it reports roles and classes with their names instead of numbers or OIDs.

Information amount

The amount of reported information is limited as shown in Table 99.

mcollinfo examples

Figure 121 shows an example of mcollinfo.

Figure 120 Raw output format for mcollinfo

CollInfo = CollCompCount (CollCompInfo)*CollCompCountCollCompInfo = CollName CollPerm CollClassCount

(CollClass)*CollClassCount CollInfoCollPerm : CollPermR CollPermW CollPermX CollPerm_ : CollRoleCnt (CollRole)*CollRoleCnt

Table 99 Information amount limitation options for mcollinfo

Option Description

-a 0 reports only collector names

-a 1 add permissions

-a 2 add referenced classes

Figure 121 mcollinfo example

mcollinfo -n dbg -o Net.Global6.1


mcontrol—Performing cell control operations

You can request user-formatted output in verbose mode as shown in Figure 122.

You can also request the number of events for each severity/status combination in the collector as shown in Figure 123. You must specify the collector name.

mcollinfo return codes

Table 100 lists the command-specific return code for mcollinfo. For a list of common return codes that apply to all CLI commands, see “ BMC Impact Manager CLI common return codes” on page 384.


The mcontrol command performs control operations on a cell. The operation is stated as an argument.

mcontrol syntax

Figure 124 on page 398 shows the syntax for mcontrol.


Figure 122 mcollinfo command for verbose mode

mcollinfo -n dbg -v -o Net.GlobalCollector Net.GlobalOID=6.1

Figure 123 mcollinfo command for number of events for severity/status

mcollinfo -n dbg -v -s Net.GlobalCollector Net.GlobalSeverities=0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Table 100 mcollinfo return codes

Code Description

31 cannot read input file

Figure 124 mcontrol syntax

mcontrol [-h|-?] [-z] [-q] [-c ConfigFile] {-p "Var=Value"} [-n cellName | -n @Host[/Port[#Key]]] [-1 HomeLocation] [-v] Control



Table 101 lists the command-specific option for mcontrol. For a list of common command options that apply to all CLI commands, see “ BMC Impact Manager CLI common command options” on page 383.

Table 102 lists the following controls that are available.

Table 101 mcontrol option

Option Description

Control specifies the control command to use. See Table 102 for the available control commands.

Table 102 mcontrol controls (part 1 of 2)

Control Description

metrics [on|off|reset] on = enables metricsoff = disables metricsreset = resets running counters

If an argument is not specified, metrics are reported by default.

pause suspends reception of adapter messages; events are no longer accepted

prop [{Destination}] if one or more Destinations are mentioned, only propagations to these destinations are retried; if no Destinations are specified, all pending propagation destinations are retried

reload [{dir|trace|conf|collect|kb|data|all}]

reload cell configuration, for one or more categories; if you do not choose an argument, all categories reload

■ dir—mcell.dir■ trace—mcell.trace■ conf—mcell.conf, propagate, modify■ collect—collector definitions■ kb—Knowledge Base, classes, rules■ data—data instances■ all—all the categories

restart stops and restarts the cell

shutdown terminates the cell in fast shutdown mode; same as mkill -s

standby switches cell to standby mode

start resumes reception of adapter messages; cell operates normally again

statbld forces the cell to perform a StateBuild immediately instead of waiting for the next scheduled StateBuild; mcontrol waits until termination of the forced StateBuild and, if successful, returns the path to the resulting saved state file

stop terminates the cell in normal mode; same as mkill

tracerule on|off turns rule tracing on or off



mcontrol examples

mcontrol can be used as shown in the following examples.

Retrying pending propagations

To retry pending propagations for a cell named grace, type the command shown in Figure 125.


Terminating a cell

To terminate a cell named grace, type the command shown in Figure 127.

tracerule phases Phases modifies the configuration of which rule phases are enabled for tracing. The Phases value has the same format as the TraceRulePhases parameter. For example,

mcontrol -n CellName tracerule phases -new,-abstract

This command disables tracing of all new and abstract rules.

tracerule names Names modifies the configuration of which rules are enabled for tracing. The Names value has the same format as the TraceRuleNames parameter. For example,

mcontrol -n CellName tracerule names problem_rule

This command enables tracing of the rule named problem_rule (assuming that problem_rule is of a phase that has rule tracing enabled).

Figure 125 Retrying Pending propagations with mcontrol command

mcontrol -n grace -v prop

Figure 126 Example of mcontrol command output for retrying pending propagations

Command on server grace acknowledged

Figure 127 Terminating a cell using the mcontrol command

mcontrol -n grace -v stop

Table 102 mcontrol controls (part 2 of 2)

Control Description


mcrtcell—Creating a new cell


Reconfiguring a cell

To reconfigure cell grace after mcell.dir has been modified, type the command shown in Figure 129.


The cell grace reconfigures without stopping and restarting.

mcontrol return codes

There are no command-specific return codes for mcontrol. For a list of common return codes that apply to all CLI commands, see “ BMC Impact Manager CLI common return codes” on page 384.


Use the mcrtcell command to create a new cell. You can only run the mcrtcell command on the local computer where you are creating the new cell.

Cell names

Cell names must be unique throughout the enterprise.

Figure 128 Example of mcontrol command output for terminating a cell


Figure 129 Reconfiguring a cell

mcontrol -n grace reload dir

Figure 130 Example of mcontrol command output for reconfiguring a cell


WARNING Cells with identical cell names on different computers within your enterprise will cause unexpected results.



The cell name cannot contain spaces or special characters. You can use any alphanumeric string and underscores (_) in a cell name, such as the following:

■ my_cell■ spike12■ oracle

Do not give a cell the same name as any item in the MCELL_HOME\etc directory, such as the kb directory or the mcell.conf, mcell.dir, or mcell.trace files.

Using the mcrtcell command to add cells ensures that the cell names are unique.

mcrtcell actions

The mcrtcell command performs the following actions:

■ determines if an entry exists in the mcell.dir file that matches the cell being created

If a matching entry exists, the creation fails. You can use the -f option to force the creation of the cell.

■ creates the etc\cellName directory, which contains a Knowledge Base copied from the etc\default\Em\kb directory

■ creates a services entry on Microsoft Windows NT, unless you specify the -m option

■ adds an entry to the local mcell.dir file

■ creates an entry in the startup scripts on UNIX platforms, unless you specify the -m option

UNIX files

When you install the cell or run mcrtcell -p PortNumber cellName on a UNIX system, you create the files listed in Table 103 that enable the cell to start on reboot and to stop on shut down. If you run mdelcell cellName, these files are automatically removed.

TIP When naming cells, adopt a naming convention for test and production cells that clearly identifies its purpose. For example, you could assign test cells names that use test as a prefix or suffix. A clear naming convention is important because in BMC Impact Explorer views there is no way to distinguish test and production cells other than by the cell name.



After you configure the cell, you must stop and restart it for the changes to take effect. For instructions, see “ Stopping or starting a cell on UNIX computers” on page 40.

mcrtcell syntax

Figure 131 shows the syntax for mcrtcell.

If you do not specify the -ie or -is option, you create a cell with an empty Knowledge Base, and the cell does not respond to requests.

Table 104 lists the command-specific options for mcrtcell. For a list of common command options that apply to all CLI commands, see “ BMC Impact Manager CLI common command options” on page 383.

Table 103 Files for UNIX

Platform File

AIX platforms etc/cellName.d

HP-UX platforms sbin/init.d/mc_cellNameSolaris platforms etc/init.d/cellName

etc/rc2.d/K99cellNameetc/rc2.d/S99cellName

Linux platforms etc/rc.d/init.d/mc_cellName

etc/rc.d/rc3.d/K99mc_cellName

etc/rc.d/rc3.d/S99mc_cellName

Figure 131 mcrtcell syntax

mcrtcell -p PortNumber [-s SourceCell][-l HomeLocation] [-f] [-m] [-z] [-h|-?] [-ie|-is] NewcellName

Table 104 mcrtcell options (part 1 of 2)

Option Description

-f forces the creation of a cell when the mcell.dir file contains an entry of the same name; reinstalls the Knowledge Base

If you do not use this option, mcrtcell exits without creating a new cell when it finds a duplicate entry in the mcell.dir file.

-ie installs the default BMC Event Manager Knowledge Base

-is installs the default BMC Service Impact Manager Knowledge Base



mcrtcell example

Figure 132 shows an example of how to create a service using mcrtcell.

Figure 133 shows the output produced.

Figure 134 shows an example of how to create another service using mcrtcell.

Figure 135 shows the output produced.

mcrtcell return codes

-m prevents automatic restart on reboot

-p PortNumber specifies the cell port number (PortNumber)

Note: The -p option for mcrtcell overrides the common CLI -p option listed in “Table 85 Common options for CLI commands” on page 383.

-s SourceCell specifies the cell (SourceCell) from which to copy a Knowledge Base

NewcellName specifies the name for the cell being created. For information on cell naming conventions, see “ Cell names” on page 401.

Figure 132 Example of mcrtcell command

mcrtcell -p 2591 -is was05dal

Figure 133 Example of output of mcrtcell

Service successfully created

Figure 134 Example of mcrtcell command

mcrtcell -s was05dal -p 2592 was04fra

Figure 135 Example output of mcrtcell

Service successfully created

NOTE This command does not use the -ie or -is option. It makes a copy of the KB from the previous cell.

Table 104 mcrtcell options (part 2 of 2)

Option Description


mcstat—Returning cell status

Table 105 lists the command-specific return codes for mcrtcell. For a list of common return codes that apply to all CLI commands, see “ BMC Impact Manager CLI common return codes” on page 384.

mcstat—Returning cell status

The mcstat command obtains the status of a cell. This command shows whether a cell is running or stopped.

mcstat Syntax

Figure 136 shows the syntax for mcstat.

Table 106 lists the command-specific option for mcstat. For a list of common command options that apply to all CLI commands, see “ BMC Impact Manager CLI common command options” on page 383.

Table 105 mcrtcell return codes

Code Description

-1 uname command failed

3 MCELL_HOME environment variable not set or duplicate cell name or port definition in mcell.dir

31 no MCELL_HOME environment variable is defined

32 duplicate cell definition in mcell.dir

33 existing cell with same name on a different host

34 existing cell with same name on a different port

35 existing cell with same name on a different host/port

36 failed to create new directory

37 cannot get OS

38 failed to remove a cell

Figure 136 mcstat syntax

mcstat [-h|?] [-z] [-q] [-c ConfigFile] {-p "Var=Value"} [-n cellName | -n @Host[/Port[#Key]]] [-v] [-t TimeOut ]

Table 106 mcstat option

Option Description

-t TimeOut specifies the length of time, in milliseconds, for the command to wait for answer before terminating; default is 60000, or 1 minute


mdelcell—Deleting a cell

mcstat example

To obtain the status for a cell named examplecell, type the command shown in Figure 137.

If the cell is not running, a message similar to the example in Figure 138 appears.

If the cell is running, the message shown in Figure 139 appears.

mcstat return codes

There are no command-specific return codes for mcstat. For a list of common return codes that apply to all CLI commands, see “ BMC Impact Manager CLI common return codes” on page 384.


Use mdelcell to delete a specified cell on the local computer. Deleting a cell by using the mdelcell command removes the cell and its entry in the mcell.dir file. You can use this command only locally on the computer where the cell resides. Executing this command results in the following actions:

■ removes the entry in the mcell.dir file■ deletes the etc\cellName ■ removes the entry from the services on Microsoft Windows or the startup scripts

on UNIX

Figure 137 mcstat example

mcstat -n examplecell

Figure 138 Message for cell not running

Could not connect to Cell examplecell.

Figure 139 Message for cell running

Running



mdelcell syntax

Figure 140 shows the syntax for mdelcell.

Table 107 lists the command-specific options for mdelcell. For a list of common command options that apply to all CLI commands, see “ BMC Impact Manager CLI common command options” on page 383.

mdelcell example

To delete a cell named grace, type the command shown in Figure 141.

If grace is not currently running, this command produces output similar to the example shown in Figure 142 on Microsoft Windows platforms:

On UNIX platforms, the command does not produce output when it runs successfully.

If grace is currently running, this command produces output similar to the example shown in Figure 143.

Figure 140 mdelcell syntax

mdelcell cellName [-z] [-h|?] [-k] [-w TimeOut]

Table 107 mdelcell options

Option Description

-k keeps tmp and log directories of the cell

-w TimeOut specifies the length of time, in seconds, for the command to wait when terminating the cell.

Figure 141 Deleting a cell using mdelcell

mdelcell grace

Figure 142 Output for mdelcell if cell is not running

Service successfully removed

Figure 143 Output for mdelcell if cell is running

Warning! Cell grace was running and mdelcell tries to terminate it.Service successfully removed.


mgetinfo—Retrieving information about a cell

mdelcell return codes

Table 108 lists the command-specific return codes for mdelcell. For a list of common return codes that apply to all CLI commands, see “ BMC Impact Manager CLI common return codes” on page 384.


The mgetinfo command retrieves information about a cell.

mgetinfo syntax

Figure 144 shows the syntax for mgetinfo.

The -n option is required if the cell is remote and defined in the mcell.dir file, or if the cell is local and named something other than HostName.

Table 109 lists the command-specific option for mgetinfo. For a list of common command options that apply to all CLI commands, see “ BMC Impact Manager CLI common command options” on page 383.

Table 108 mdelcell return codes

Code Description

-1 uname command failed

31 no MCELL_HOME environment variable is defined

Figure 144 mgetinfo syntax

mgetinfo [-h|?] [-z] [-q] [-c ConfigFile] {-p "Var=Value"} [-n cellName | -n @Host[/Port[#Key]]] [-1 HomeLocation] [-v] Information

Table 109 mgetinfo option

Option Description

Information specifies the Information option to use. See Table 110 for the available Information options.



Table 110 describes the mgetinfo information options.

A connect request displays the information shown in Table 111.

Table 110 mgetinfo information options

Information Description

activity retrieves the activity status of the cell0 = standby1 = limited2 = full activity.

config retrieves configuration of a cell, including the cell name, home directory, Knowledge Base directory, and the full paths of all configuration files the cell uses

connect retrieves information about the current connections that are open from and to the cell; see Table 111 for description of that information

kbmodules lists KB modules with version information from the cell’s loaded KB; information is displayed in raw format. When combined with the -v switch, it is returned in a more verbose and readable format.

kbsources lists KB source files with version information from the cell’s loaded KB; information is displayed in raw format. When combined with the -v switch, it is returned in a more verbose and readable format.

metrics reports the metrics, collected by the cell, that are stored in MC_CELL_METRIC data objects

param retrieves the options found in the mcell.conf file

This information does not necessarily represent the effective values of these options. If the value is set to an out-of-range value, that value is returned, but the effective value used internally will be the range boundary.

NOTE: All parameter settings are returned in order of definition. There can be multiple settings for the same parameter. Only the last setting reported is effective.

services reports service metrics counting the components and relationships

version displays the version number of the cell

Table 111 Information from connect request (part 1 of 2)

Connect information Description

All Connections

direction IN for incoming and OUT for outgoing

This information refers to the initiator of the connection. An incoming connection means a client contacted the cell, while an outgoing connection means the cell itself contacted another cell. In both cases, data can flow in both directions.

type of client the client type, such as unknown, cell, browser, adapter, CLI, and EIF, which are reported as literal values

name of connected program

the name of the connected program (for example: Impact Explorer, mposter, cellName)



mgetinfo examples

This section contains examples of mgetinfo.

mgetinfo config example

Figure 145 shows an example of mgetinfo config.

On UNIX, this command produces output similar to the example shown in Figure 146.

source address IP address/port of source side of the connectionfor inbound connections, this is the client; for outbound, it is the cell

destination address IP address/port of destination side of the connectionfor inbound connections, this is the cell; for outbound, it is the destination

Incoming Connections

name of user the name of the user; example: Admin

time delta between both sender and receiver in seconds, to be added to time stamps coming in to convert to the cell time

sequence sequence number of last incoming message

sequence sequence number of last answer

Outgoing Connections

time stamp timestamp of last connection setup or trial

sequence sequence number of last outgoing message

message number of messages waiting for connection opening

message number of messages waiting for answer

Figure 145 Example of mgetinfo config

mgetinfo -n aspen config

Figure 146 mgetinfo config command output on UNIX

cellName=aspenHomeDir=/opt/mcellKBDir=/opt/mcell/etc/aspen/kb/ConfigFile=/opt/mcell/etc/mcell.confTraceConfigFile=/opt/mcell/etc/mcell.traceTraceDefaultFile=/opt/mcell/tmp/aspen/traceServerDirectoryFile=/opt/mcell/etc/mcell.dirPropagateConfigFile=/opt/mcell/etc/mcell.propagateModifyConfigFile=/opt/mcell/etc/mcell.modify

Table 111 Information from connect request (part 2 of 2)

Connect information Description



On Microsoft Windows, this command produces output similar to the example shown in Figure 147.

mgetinfo param example

Figure 148 shows an example of mgetinfo param.


mgetinfo services example

Figure 150 shows an example of mgetinfo services.

Figure 147 mgetinfo config command output on Microsoft Windows

cellName=aspenHomeDir=C:/mcell/serverKBDir=C:/mcell/server/etc/aspen/kb/ConfigFile=C:/mcell/server/etc/mcell.confTraceConfigFile=C:/mcell/server/etc/mcell.traceTraceDefaultFile=C:/mcell/server/tmp/aspen/traceServerDirectoryFile=C:/mcell/server/etc/mcell.dirPropagateConfigFile=C:/mcell/server/etc/mcell.propagateModifyConfigFile=C:/mcell/server/etc/mcell.modify

Figure 148 Example of mgetinfo param

mgetinfo -n aspen param

Figure 149 mgetinfo param command output

Trace=YesTraceSrc=NoTraceRuleLevel=1TraceConfigFileName=mcell.traceTraceDefaultFileName=%T/traceLicenseServer=CellOperationLevel=ConsolidationCellOperationRelax=No...

Figure 150 Example of mgetinfo services

mgetinfo services


mgetrec—Obtaining a global record value


mgetinfo connect example

Figure 152 shows an example of mgetinfo connect.


mgetinfo return codes

Table 112 lists the command-specific return codes for mgetinfo. For a list of common return codes that apply to all CLI commands, see “ BMC Impact Manager CLI common return codes” on page 384.


Use the mgetrec command to obtain the value of a global record.

Figure 151 mgetinfo param command output

MC_SM_COMPONENT Number of MC SM Component 87CONNECTIVITY Number of Connectivity 11IT_COMPONENT Number of IT Component 22LOGICAL_COMPONENT Number of Logical Component 47SERVICE_LEVEL_AGREEMENT Number of Service Level Agreement 7MC_SM_RELATIONSHIP Number of MC SM Relationship 126IMPACT_RELATIONSHIP Number of Impact Relationship 126NULL_RELATIONSHIP Number of Null Relationship 0”

Figure 152 Example of mgetinfo services

mgetinfo connect

Figure 153 Output of mgetinfo connect

IN browser ImpactExplorer 10.0.10.17:1545 10.0.10.28:1828 Admin 0 2028 2071

Table 112 mgetinfo return codes

Code Description

31 not a SIM cell



mgetrec syntax

Figure 154 shows the syntax for mgetrec.

The -n option is required if the cell is remote and defined in the mcell.dir file, or if the cell is local and named something other than HostName.

Table 113 lists the command-specific option for mgetrec. For a list of common command options that apply to all CLI commands, see “ BMC Impact Manager CLI common command options” on page 383.

mgetrec example

Figure 155 shows an example of mgetrec.

The preceding command produces output similar to the example shown in Figure 156.

Figure 154 mgetrec syntax

mgetrec [-h|?] [-z] [-q] [-c ConfigFile] {-p "Var=Value"} [-n cellName | -n @Host[/Port[#Key]]]-r Record[.Slot]

Table 113 mgetrec option

Option Description

-r Record[.Slot] specifies the global record to be obtained, optionally limited to one of its slots

Figure 155 Example of mgetrec

mgetrec -r EM_KB_OPTIONS

Figure 156 Output of mgetrec (part 1 of 2)

startup_script_enabled-----NO-----dfilter_enabled-----NO-----dnotification_enabled-----NO-----


mkb—Updating the Knowledge Base

mgetrec return codes

There are no command-specific return codes for mgetrec. For a list of common return codes that apply to all CLI commands, see “ BMC Impact Manager CLI common return codes” on page 384.


Use the mkb command to create, view, or update the Knowledge Base. When you use the mkb command to create a new Knowledge Base, a manifest.kb file is also created.

Use the mkb command primarily to check or modify a Knowledge Base with scripts, such as when you need to upgrade the Knowledge Base automatically for a number of cells installed across your network. After installing the files, compile using the mccomp command.

mkb syntax

Figure 157 shows the syntax for mkb.

Table 114 lists the command-specific options for mkb. For a list of common command options that apply to all CLI commands, see “ BMC Impact Manager CLI common command options” on page 383.

dpropagation_enabled-----NO-----default_location-----

Figure 157 mkb syntax

mkb [-h|-?] [-z] [-q] [-v] [-n CellName | -n @Host[/Port[#Key]] ] [-f ManifestFile] [-b BinFile] [-c ClassFile] [-d DataFile] [-i Interp] [-j RecordFile] [-l LibFile] [-m Directory] [-o CollectorFile] [-p] [-r RuleFile]

Table 114 mkb options (part 1 of 2)

Option Description

-b BinFile binary file name

-c ClassFile imports the specified ClassFile.baroc that defines the class definitions

Figure 156 Output of mgetrec (part 2 of 2)



Use the options described in Table 115 to add new files to the Knowledge Base that you specified with the -f option. The new files are also described in Table 115.

-d DataFile imports the specified DataFile.baroc that defines data instances

-f manifest specifies the path to the manifest.kb file

-i Interp specifies interpreter type either: [a|l2|p4|s5|w4]

-j RecordFile imports RecordRile.baroc that defines the record definitions

-l LibFile imports the specified library file (filename.wic).

Note: The -l option for the mkb command overrides the -l option in “Table 85 Common options for CLI commands” on page 383.

-m Directory creates a new Knowledge Base directory hierarchy based on the contents of the designated manifest.kb file

-o CollectorFile imports the specified CollectorFile.mrl that defines that collector definitions

-p prints the contents of the designated manifest.kb file, along with the names of the .load files in the various directories comprising the Knowledge Base

Note: The -p option for mkb overrides the common CLI -p option listed in “Table 85 Common options for CLI commands” on page 383.

-r RuleFile imports the specified RuleFile mrl that defines the rule definitions

Table 115 mkb new file options

mkb Option Description

-b BinFile adds the binary file (BinFile) for the architecture

-i Interp specifies the appropriate interpreter to use for the architecture; the KB is copied as designated by the Interp value to the appropriate directory for that architecture:

■ l2 - Linux 5.2 and 6.0■ p4 - AIX 4.0 (Power PC)■ s5 - Solaris 2.5 (Sparc)■ w4 - Microsoft Windows/NT 4.0 (Intel)

-c ClassFile adds the class file (ClassFile) to the designated Knowledge Base

-o CollectorFile adds the collector file (CollectorFile) to the designated Knowledge Base

-d DataFile adds the data file (DataFile) to the designated Knowledge Base

-l LibFile adds the library file (LibFile) to the designated Knowledge Base

Note: The -l option for the mkb command overrides the -l option in “Table 85 Common options for CLI commands” on page 383.

-r RuleFile adds the rule file (RuleFile) to the designated Knowledge Base

Table 114 mkb options (part 2 of 2)

Option Description



Each of the above options causes mkb to copy the designated files into the proper Knowledge Base directory and adds information to the .load file of that directory.

mkb examples

This section contains UNIX and Microsoft Windows examples.

UNIX example

Figure 158 shows an example of mkb on UNIX.

This command produces output similar to the example shown in Figure 159 on a UNIX computer named spud.

Figure 158 mkb command on UNIX

mkb -f ./manifest.kb -p

Figure 159 mkb output on UNIX

classes = \mcell\server\etc\spud\kb\.\classes load file: .load root.baroc intevt.baroc...

patrol.baroc collectors = \mcell\server\etc\spud\kb\.\collectors load file: .load collectors.mrl internal.mrl Adapters.mrl catchall.mrl data = \mcell\server\etc\spud\kb\.\data load file: .load lib = \mcell\server\etc\spud\kb\.\lib load file: .loadcan not open file: \mcell\server\etc\spud\kb\.\lib\.load rules = \mcell\server\etc\spud\kb\.\rules load file: .load new.mrl records = \mcell\server\etc\spud\kb\.\records load file: .load intrec.wic


mkill—Stopping a cell

Microsoft Windows example

Figure 160 shows an example of mkb on Microsoft Windows.

This command produces output similar to the example shown in Figure 161 on Microsoft Windows.

mkb return codes

There are no command-specific return codes for mkb. For a list of common return codes that apply to all CLI commands, see “ BMC Impact Manager CLI common return codes” on page 384.

mkill—Stopping a cell

Use the mkill command to stop a running cell or gateway.

mkill syntax

Figure 162 shows the syntax for mkill.

If you do not specify a cell to stop, this command stops the default cell, HostName.

You must use the -n cellName option on multiple cell hosts.

Figure 160 mkb command on Microsoft Windows

mkb -f kb\manifest.kb -m new_kb

Figure 161 mkb command output on Microsoft Windows

manifest directory tree created successfully

Figure 162 mkill syntax

mkill [-h|?] [-z] [-q] [-c ConfigFile] {-p "Var=Value"} [-n cellName | -n @Host[/Port[#Key]]] [-l HomeLocation][-v] [-s]


mlogchk—Performing consistency checks

Table 116 lists the command-specific option for mkill. For a list of common command options that apply to all CLI commands, see “ BMC Impact Manager CLI common command options” on page 383.

mkill example

Figure 163 shows an example of mkill.


mkill return codes

There are no command-specific return codes for mkill. For a list of common return codes that apply to all CLI commands, see “ BMC Impact Manager CLI common return codes” on page 384.


The mlogchk command performs consistency checks on the persistency directory MCELL_HOME\log\cellName. This directory could be in an inconsistent state after abnormal cell or StateBuilder termination. It is an interactive tool that tells the operator what is wrong and what should be corrected.

You must shut down the cell before running the checks because a running cell might modify the log directory during a check.

Table 116 mkill option

Option Description

-s performs rapid shutdown termination; bypasses StateBuilder

Figure 163 Example of mkill

mkill -n examplecell

Figure 164 Output of mkill

server examplecell terminated

NOTE The mkill -s command terminates a cell and bypasses the StateBuilder. If a user has cells set to run the StateBuilder before terminating, then mkill -s -n cellName overrides the StateBuilder option.



The mlogchk command does the following:

■ determines whether an mcdb.lock file exists and, if so

— checks for a running statbld and waits for termination— reports trailing lock file and removes it (after confirmation)

■ determines whether an xact.1 file exists and, if so, reports and instructs the user to run statbld

■ determines whether an mcdb.0 file exists and, if so, reports and proposes to rename or remove it

mlogchk syntax

Figure 165 shows the syntax for mlogchk.

There are no command-specific options for mlogchk.

mlogchk example

Figure 166 shows an example of mlogchk.

For a cell named spud, the preceding command produces output similar to the example shown in Figure 167.

The output continues with the message shown in Figure 168 on page 420 if you respond with y.

Figure 165 mlogchk syntax

mlogchk [-h|?] [-z] [-q] [-c ConfigFile] {-p "Var=Value"}[-n cellName | -n @Host[/Port[#Key]]][-l HomeLocation] [-v]

Figure 166 Example of mlogchk

mlogchk -n spud -v

Figure 167 Output of mlogchk

Warning: Cell spud is running - this may influence the consistency check.To ensure correct results, you should shutdown the Cell now.Do you want to continue (y/n) ?


mpkill—Stopping mposter and msend server processes

mlogchk return codes

Table 117 lists the command-specific return codes for mlogchk. For a list of common return codes that apply to all CLI commands, see “ BMC Impact Manager CLI common return codes” on page 384.


Use the mpkill command to stop a running mposter or msend process.

When an msend or mposter command is started in persistent buffering mode (for example, using the -j option), a second msend or mposter process is started in background—this is the msend or mposter server process. When the server is already running and an msend or mposter command starts using the same buffer directory as the existing server, an additional server is not started; msend or mposter (client) just connects to the server.

mpkill syntax

Figure 169 shows the syntax for mpkill.

Figure 168 mlogchk message

No inconsistency found.

Table 117 mlogchk return codes

Code Description

21 cannot access cell log directory

NOTE This msend or mposter server process, which is hidden to the user, automatically stops itself when it is idle for 10 minutes. “Idle” means that there is no msend or mposter client connected to it and every event in the buffer has been sent and acknowledged by the destination cell. A new server will be started by the client as soon as a msend or mposter client requires it. This feature considerably limits the need to use mpkill.

Figure 169 mpkill syntax

mpkill [-h|?] [-z] [-q] [-c ConfigFile] {-p "Var=Value"} [-n cellName | -n @Host[/Port[#Key]]] (-a | -j Bufdir)



Table 118 lists the command-specific option for mpkill. For a list of common command options that apply to all CLI commands, see “ BMC Impact Manager CLI common command options” on page 383.

mpkill example

Figure 170 shows an example of mpkill. If msend has been started as

msend -n cell1 -j "C:\bufdir\cell1"

to stop the running msend server process, you would enter the mpkill command as shown in Figure 170.


Table 118 mpkill option

Option Description

-a kills all msend or mposter server processes

-j Bufdir kills msend or mposter server processes on a specified persistent buffer

Figure 170 Example of mpkill

mpkill -j "C:\bufdir\cell1

Figure 171 Output of mpkill

BMC Impact MposterKiller 7.0.00 (Build 10891339 - 30-Mar-2006)Copyright 1998-2006 BMC Software, Inc. as an unpublished work. All rights reserved.


mposter and msend—Managing data, global records, and events

mpkill return codes

There are no command-specific return codes for mpkill. For a list of common return codes that apply to all CLI commands, see “ BMC Impact Manager CLI common return codes” on page 384.


Use the msend command to manage events in a cell.

Use the mposter command to manage data, global records, and events in a cell. You can modify global records and create, modify, and delete data instances and events using the mposter command.

You can use the mposter command to modify dynamic data objects in the cell even when the cell is paused.

mposter and msend syntax

Figure 172 shows the syntax for mposter.

NOTE The mposter and msend commands can both be used to send or modify events, but mposter also can be used to send or modify data.

NOTE BMC Software recommends that you use the msend command instead of the mposter command when you do not need to access or modify dynamic data or global records. The msend command is a more secure command because it is more restrictive than mposter.

BMC Impact Solutions does not support using the mposter command to create or to edit service model component instances.Although it is possible to use the mposter command to create and to edit the service model class instances on a cell, these changes are made to only the BAROC service model running on the cell, not to the cell’s standard (reference) published service model in the CMDB. This causes a loss of service model integrity and subsequent service model publishings will fail.

Figure 172 mposter syntax (part 1 of 2)

mposter [-h|?] [-z] [-q] [-c ConfigFile] {-p "Var=Value"} [-n cellName | -n @Host[/Port[#Key]]][-y] [-f DirFile] [-v]



Figure 172 shows the syntax for msend, which is identical to the syntax for mposter.

Table 119 lists the command-specific options for mposter and msend. For a list of common command options that apply to all CLI commands, see “ BMC Impact Manager CLI common command options” on page 383.

[-i] [-I] [-x] [-u] [-w MSecAnswerWait] [-t MSecTerminationWait][-j BufDir] [-d] [-e] [ - | {SourceFile} | -a Class [-o Source] [-m Message] [-r Severity] [-b SlotSetValue] | -l EventID [-b SlotSetValue]]

Figure 173 msend syntax

msend [-h|?] [-z] [-q] [-c ConfigFile] {-p "Var=Value"} [-n cellName | -n @Host[/Port[#Key]]][-y] [-f DirFile] [-v][-i] [-I] [-x] [-u] [-w MSecAnswerWait] [-t MSecTerminationWait][-j BufDir] [-d] [-e] [ - | {SourceFile} | -a Class [-o Source] [-m Message] [-r Severity] [-b SlotSetValue] | -l EventID [-b SlotSetValue]]

Table 119 mposter and msend options (part 1 of 2)

Option Description

- input from standard input stream

-a Class sends an object of class Class

-b SlotSetValue adds SlotSetValue settings (format: “slot=value;...”)

-d sends as data instead of as an event

-e specifies to use EIF instead of MCELL format

-f DirFile specifies the directory file path; the default value is MCELL_HOME\etc\mcell.dir

-i sets to interactive mode

-I reinitializes persistent buffers

-j BufDir makes the buffer directory persistent

-l EventID modify the specified event instead of a new event

Note: The -l option for the mposter command overrides the -l option in “Table 85 Common options for CLI commands” on page 383.

-m Message sets event message to the specified Message text

-o Source sets event source to the specified Source

-r Severity sets the event severity value to the Severity specified

-t MSecTerminationWait sets the length of time in milliseconds to wait for trailing answers before terminating; default is 5000

-u leave messages unanswered

Figure 172 mposter syntax (part 2 of 2)



mposter examples

Figure 174 shows an example of mposter.

The information for the event is entered using BAROC-style input as shown in Figure 175.

The output of the mposter session is similar to what is shown in Figure 176.

Then, the following would be input, as shown in Figure 177.

-w MSecAnswerWait sets the length of time in milliseconds to wait for message answer; default is 0

-x examine timings

-y immediately terminate upon connection failure

NOTE All examples and information in this section also can apply to msend.

Figure 174 Example of mposter

mposter -n aspen -v -

Figure 175 mposter BAROC-style input

HOST_DOWN;origin='HOST_DOWN';msg='host blue is down';

END

Figure 176 mposter BAROC-style output

Event time stamp : 943392578Sending eventMessage 1 - #0Message 1 - #1 - evtid = 0

Figure 177 mposter BAROC-style input

HOST_DOWN;origin='HOST_DOWN';msg='host orange is down';

END

Table 119 mposter and msend options (part 2 of 2)

Option Description



And the mposter output would be similar to what is shown in Figure 178.

In the example shown in Figure 179, mposter adds an instance of the DATA class AppByHost to the host aspen. The example uses dynamic data technology in the following ways:

■ specifying that the instance to add is an instance of AppByHost■ defining the host as aspen■ specifying that it defines applications as word or excel

You can use the mposter command to change any one of definitions without changing any of the others.

The preceding command does not produce any output.

Enabling persistent buffering

To enable persistent buffering, first create a writeable directory (BufDir in Figure 180), then use the syntax shown in Figure 180.

The mposter.lck, mposter.buf, and mposter.pos files are placed in BufDir after the mposter (or msend) command is executed. Multiple instances of mposter (and/or msend) can use the same BufDir directory if the destination cells are the same.

Figure 178 mposter BAROC-style output

Event time stamp : 943392646Sending eventMessage 2 - #2 - evtid = 0Message 2 - #2

Figure 179 Definition changes using mposter

mposter -n aspen -d -a AppByHost -b "host='aspen'; applications=['word','excel']"

NOTE On Microsoft Windows, the mposter and msend commands accept only double quotes with the -b option. If you use single quotation marks with the -b option on Microsoft Windows, the event is not sent, and no error message appears.

On UNIX, with the with the -b option, the command accepts both single and double quotation marks.

Figure 180 Enabling persistent buffering using mposter

mposter [current options] -j BufDir



When persistent buffering is enabled, both mposter and msend can send events to one of a list of cells. To supply a list of cells, use the -n option or the ServerName option and separate each of the cells in the list with a colon, as shown in Figure 181 on page 426.

Write access for persistent buffering

To successfully start the mposter or msend CLI commands in a persistent buffering mode, you must ensure that you have write access to the buffers file. You can locate the buffers file at:

■ UNIX—/etc/itm/.reg/Buffers

■ Microsoft Windows—HKEY_LOCAL_MACHINE/SOFTWARE/BMC Software/BMC Impact/mposter/Buffers

The Microsoft Windows registry key for the Buffers file is not created by default; it is created the first time the mposter (or msend) command is executed using the -j option in a persistent buffering mode.

If the Buffers file is not writable, you will receive the error message shown in Figure 182.

Decreasing the buffer size

The persistent directory may contain the following three files:

■ mposterbuf.buf ■ mposterbuf.pos ■ mposterbuf.lck

The purpose of the mposterbuf.lck file is to provide a file-locking mechanism when multiple mposter-like servers are started at the same time.

Figure 181 Supplying a list of cells for mposter

mposter -n cell1:cell2:cell3 -j BufDir

Figure 182 Error message if buffers files are not writable

Launching mposter server... OKGetting Server Port number... OK (33992)Connecting mposter server... Fatal error! Cannot negotiate connection with mposter server. Check if the cell(s) name, location, port and encryption key are the same as those running server (protocol error: 4)Fatal error! Client initialization failed. A current cause of this problem is a wrong/unavailable cell destination (hostname, port, encryption key).


mquery—Retrieving objects from a cell

The mposterbuf.pos file contains a positive integer, between 0 and the size, in bytes, of mposterbuf.buf. This value, pos corresponds a position in mposterbuf.pos; every event or data contained in the first pos bytes of mposterbuf.buf has been sent to and acknowledged by a cell. Every event contained between pos and the end of file either has not been sent yet or has been sent but has not been acknowledged by the cell yet.

The size of the mposterbuf.buf file is decreased when all the following conditions are met:

■ The size of mposterbuf.buf is at least 50000 bytes (50 KB).

■ The percentage of events sent and acknowledged must make up at least 30% of the total file size. For instance, if mposterbuf.buf is 10 MB, at least 3 MB of acknowledged events must be in mposterbuf.buf for its size to be decreased. This means that mposterbuf.pos should contain a number larger than 3,000,000.

mposter and msend return codes

Table 120 lists the return codes for mposter and msend. For a list of common return codes that apply to all CLI commands, see “ BMC Impact Manager CLI common return codes” on page 384.


The mquery command retrieves objects from a cell.

mquery syntax

Figure 183 shows the syntax for mquery.

Table 120 mposter and msend return codes

Code Description

2 failed to initialize in Server mode

3 failed to find a valid cell

4 failed to close the client connection

Figure 183 mquery syntax

mquery [-h|-?] [-z] [-q] [-c ConfigFile] {-p "Var=Value"} [-n cellName | -n @Host[/Port[#Key]]] [-l HomeLocation] [-v] [-r] [-f Format]( [-d] [-a Class] [-w Where] [-s SlotList | -x SlotList] [-i Collector] [-o OrderSlot] |-Q Query | - | {File} )



Table 121 lists the command-specific options for mquery. For a list of common command options that apply to all CLI commands, see “ BMC Impact Manager CLI common command options” on page 383.

mquery output

Output of the mquery command is available in raw format for parsing by a program, and in printed format for users, with several variations.

Raw output format

The output consists of the number of solutions, terminated with RS (Record Separator, ASCII code 30), and followed by the solutions. Each solution is terminated with RS. A solution consists of a sequence of slot values, separated by FS (Field Separator, ASCII code 28). There is no FS after the last slot value (that is followed by the RS solution terminator). Empty slot values, or nonexistent slots, are represented by an empty value, such as two FS with nothing in between.

Table 121 mquery options

Option Description

- performs queries as read from standard input stream

-a Class select from a specified Class (default is either CORE_EVENT or CORE_DATA).

-d select data objects instead of event objects

-f Format format using: quoted, BAROC, CSV, or XML

-i Collector selects only in a collector (optional + suffix for closure)

-o OrderSlot sorts on the specified slot order (OrderSlot).

Set the sort order by appending a suffix to the OrderSlot value that you specify. Append a plus sign (+) for ascending sort or a minus sign (-) for a descending sort.

-Q Query perform the specified query

-r sets output to be raw output. For more information, see “ Raw output format” on page 397.

-s SlotList selects specific slots from the comma-separated SlotList; the default is ALL). Use special value COUNT to retrieve only the number of selected items. Use special value DELETE to delete the selected items.

-w Where specifies a where condition on the specified Class

-x SlotList excludes specific slots from the comma-separated SlotList (selecting ALL)

File performs queries as read from one or more specified files



Figure 184 shows an example of a raw output specification.


By default, solutions are printed in sequential order. For every solution, the values of the requested slots are printed, one per line. Empty or nonexistent slot values take an empty line. A slot value containing a new line will occupy more than one line. It is not possible to detect these values in standard format.

Verbose mode

In verbose mode, every solution is preceded by a line of the form as shown in Figure 185 on page 429.

where

■ N is the number of the solution (starting from 1) ■ M is the total number of solutions.

The last solution is followed by a line of the form as shown in Figure 186.

Special quoted format

In this variant of the standard format, slot values are quoted when necessary.

Special BAROC format

In this variant of the standard format, every solution is represented by a BAROC instance. This consists of the class name, terminated by a semicolon (;) as shown in Figure 187.

Figure 184 Example of raw output specification

RawOutput = SolutionCount RS Solution RS ... Solution RSSolution = SlotValue FS ... SlotValue

Figure 185 Verbose mode options

-----N/M-----

Figure 186 End of form

-----END-----

Figure 187 Special BAROC format

slotname=slotvalue;



Values have quotes when needed. Nonexistent slots are not printed. The solution is terminated with an END on a line.

Special XML format

In this variant of the standard format, every solution is represented by an XML instance. Nonexistent slots are not printed.

Special CSV format

In the Comma Separated Value (CSV) variant of the standard format, solutions are printed in multiple columns over several rows. In non-verbose mode, each solution is printed on one row. Slot values are placed in columns in the same order as in the column selection. If ALL slots are requested, the order is determined by the cell and depends on the class definitions.

In verbose mode, solutions can be on multiple rows. For an explicitly specified selection of columns, the first row contains those column names. If you request ALL slots, every solution row is preceded by a row containing the slot names. This is required, as the returned slots may vary depending on the class of the object.

Columns are separated with a comma (,). A value that contains a comma (,) or a quote ("), or a new line, is quoted with a quote ("). A quote (") within such a value is doubled.

Query specification

You can specify a query either with command line options or with the -Q option through standard input. Using -Q with standard input, you must specify the query in MRL syntax. You can use the options described in Table 122 to specify the query with CLI.

Table 122 mquery query options (part 1 of 2)

Option Description

-d retrieves data instances instead of events

-a Class selects instances of class Class or its subclasses

If omitted, a default value of CORE_EVENT or CORE_DATA is assumed (depending on whether the -d option is specified)

-w Where imposes one or more conditions on the instance slot values

The Where value is a general MRL expression as used in a Where clause. Several subexpressions can be combined with a comma (,) or AND. Quotes may be needed to escape from shell interpretation.



mquery examples

This section contains examples of the mquery command.

Selecting events with a severity level

Use the command shown in Figure 188 to select all MC_CELL_CONTROL events with severity of at least MINOR, and non-closed status. This query returns the indicated slots and the effective class name.

The command shown in Figure 189 selects all events from the ByHost collectors for hosts host1 and host2 including all of their subcollectors, if any. The result is ordered on status in ascending order beginning with OPEN, and for each equal status value, descending on severity beginning with DOWN.

-s SlotList selects the slots listed in SlotList, a comma-separated sequence of slot names

Special values are

■ ALL—gets all slots■ COUNT—gets no slots, only a count of matching objects is returned■ DELETE—all matching objects are deleted, returning a count of these

The default is ALL.

-x SlotList excludes the slots listed in SlotList, a comma-separated sequence of slot names

All slots are reported except for these.

-i Collector retrieves only matching object instances that belong to one of the collectors specified in Collector

This is a comma-separated sequence of collector object identifiers (OIDs), names, or both. Each one can be suffixed optionally with a + to include its subcollectors as well.

-o OrderSlot sorts the slots mentioned in OrderSlot

This is a comma-separated sequence of slot names. Each one can be suffixed optionally with a + to indicate ascending order or a - to indicate descending order. Without suffix, a + is assumed. Ordering is done first on the first slot, then on the next one, and so on.

Figure 188 Example of mquery—Select events with severity status

mquery -a MC_CELL_CONTROL -w "severity: >= MINOR AND status: != CLOSED"

-s "mc_ueid,CLASS,severity,msg"

Table 122 mquery query options (part 2 of 2)

Option Description


mrecover—Recovering from a catastrophic data loss

Deleting events using the mquery command

You can use the value DELETE with the -s option to delete events, as shown in shown in Figure 190.

This command removes the event with handle 123.

mquery return codes

Table 123 lists the command-specific return codes for mquery. For a list of common return codes that apply to all CLI commands, see “ BMC Impact Manager CLI common return codes” on page 384.


Use the mrecover command to recover the state of a cell after a catastrophic loss of data. Typically, a catastrophic data loss is caused by a system failure. You use the mrecover command locally on the computer hosting the cell from which the data was lost.

Figure 189 Example of mquery—Select events from collector

mquery -i "'By Host'.host1+,'By Host'.host2+" -s "mc_ueid,CLASS,severity,hostname,msg"-o "status,severity-"

NOTE The current implementation of the mquery command has the following limitations:

■ The XML format is experimental and may change in future BMC Impact Solutions product releases.

■ The list slot values in XML are printed as strings, not as XML lists.

Figure 190 Deleting events using mquery

mquery -n cellName -s DELETE -w "event_handle: == 123"

Table 123 mquery return codes

Code Description

21 syntax error in input



The process recovers the data from other cells that received events from the local cell and that sent events to the local cell. The command cannot recover unpropagated events sent directly from adapters.

The mrecover command contacts each of the cells that you list in the TargetCell option and requests that each target cell produce an up-to-date saved state. The events that were propagated from the local cell are extracted from each target cell and stored locally. After all of the target cells have been prompted and the propagated events are retrieved, they are merged into a new saved state for the local cell. Then, the saved state is processed by the local cell during a recovery process.

If the local cell is running or contains an mcdb file, the recovery process aborts. If the recovery process cannot connect to a target cell, you are prompted to choose to stop or continue the recovery process. If you choose to continue, you are prompted to choose to include events collected from the previous session. After the recovery process completes, the saved state is used to restart the recovered cell.

mrecover syntax

Figure 191 shows the syntax for mrecover.

Table 124 lists the command-specific option for mrecover. For a list of common command options that apply to all CLI commands, see “ BMC Impact Manager CLI common command options” on page 383.

NOTE The mrecover command recovers only propagated events.

NOTE If the data loss includes the BMC Impact Solutions product executables or the Knowledge Base definition of the cell, you must reinstall the cell software, the Knowledge Base, and a dedicated recovery Knowledge Base (if applicable) before using the mrecover command.

Figure 191 mrecover syntax

mrecover [-h|-?] [-z] [-q] [-c ConfigFile] {-p “Var=Value”} [-n cellName | -n @Host[/Port[#Key]]] [-1 HomeLocation] {TargetCell} . . .

Table 124 mrecover option

Option Description

TargetCell specifies the name of the cell that propagated events or to which events have been propagated


mrextract—Extracting cell state files to create new state files

mrecover example

To fix a broken cell with input from cella, cellb, and cellc, type the command shown in Figure 192.

mrecover return codes

Table 125 lists the command-specific return codes for mrecover. For a list of common return codes that apply to all CLI commands, see “ BMC Impact Manager CLI common return codes” on page 384.


Events are extracted from the remote cell repository for the local cell being recovered. The mrextract command is one step in the recovery process. For more information, see “ mrecover—Recovering from a catastrophic data loss” on page 432.

The cell must be stopped before using the mrextract command.

Figure 192 Fixing a broken cell using mrecover

mrecover -n broken_cell cella cellb cellc

Table 125 mrecover return codes

Code Description

2 failed to send the command that started the StateBuilder on a remote cell

3 could not obtain information from one or more neighbor cells

5 could not launch an external program (mrmerge or mcell)

6 mrmerge exited abnormally

7 mcell (in recovery mode) exited abnormally

WARNING This command is used by mrecover and should be avoided by end users.



mrextract syntax

Figure 193 shows the syntax for mrextract.

Table 126 lists the command-specific options for mrextract. For a list of common command options that apply to all CLI commands, see “ BMC Impact Manager CLI common command options” on page 383.

mrextract example

Figure 194 shows an example of mrextract.

mrextract return codes

Table 127 lists the command-specific return codes for mrextract. For a list of common return codes that apply to all CLI commands, see “ BMC Impact Manager CLI common return codes” on page 384.

Figure 193 mrextract syntax

mrextract [-h|-?] [-z] [-q] [-c ConfigFile] {-p Var=Value} [-n cellName | -n @Host[/Port[#Key]]][-1 HomeLocation] [-i InputStateFile] [-o OutputFile] {TargetCell} . . .

Table 126 mrextract options

Option Description

-i InputStateFile specifies to use input from InputStateFile; the default is the cell’s mcdb

-o OutputFile sends output to the specified OutputFile file; the default is to send output to standard output

TargetCell specifies the name of the cell to which events have been propagated; separate multiple cell names with a space

Figure 194 Example of mrextract

mrextract -n CellTwo -o \tmp\mcdb.CellOne

Table 127 mrextract return codes

Code Description

37 failed to enable tracing

47 cannot access state builder

67 failure loading kb classes

97 cannot start while state builder is active


mrmerge—Merging event objects

mrmerge—Merging event objects

The mrmerge command is one step in the cell recovery process. This command merges events recovered from other cells into a new saved state for the local cell being recovered. For more information, see “ mrecover—Recovering from a catastrophic data loss” on page 432.

mrmerge syntax

Figure 195 shows the syntax for mrmerge.

Table 128 lists the command-specific options for mrmerge. For a list of common command options that apply to all CLI commands, see “ BMC Impact Manager CLI common command options” on page 383.

mrmerge example

Figure 196 shows an example of mrmerge.

WARNING This command is used by mrecover and should be avoided.

Figure 195 mrmerge syntax

mrmerge [-h|-?] [-z] [-q] [-c ConfigFile] {-p “Var=Value”}[-n cellName | -n @Host[/Port[#Key]]] [-l HomeLocation][-o OutputFile] {InputFile}

Table 128 mrmerge options

Option Description

-o OutputFile specifies the file (OutputFile) to which to send command output; the default output target is terminal; the path name of the recovery cell’s database file (mcdb) to be created by this command

InputFile specifies the input file for the mrextract command

Figure 196 Example of mrmerge

mrmerge -n Cellone -o $MCELL_HOME\log\Cellone\mcdb\tmp\mcdb.X1 \tmp\mcdb.X2


msetmsg—Modifying an event

mrmerge return codes

Table 129 lists the command-specific return codes for mrmerge. For a list of common return codes that apply to all CLI commands, see “ BMC Impact Manager CLI common return codes” on page 384.


Use the msetmsg command to modify the status value of an event in a specified cell. Use the -s option to modify the slot value.

msetmsg syntax

Figure 197 shows the syntax for msetmsg.

Table 130 lists the command-specific options for msetmsg. For a list of common command options that apply to all CLI commands, see “ BMC Impact Manager CLI common command options” on page 383.

Table 129 mrmerge return codes

Code Description

37 failed to enable tracing

47 cannot access StateBuilder

67 failure loading kb classes

97 cannot start while StateBuilder is active

Figure 197 msetmsg syntax

msetmsg [-h|-?] [-z] [-q] [-c ConfigFile] {-p "Var=Value"} [-n cellName | -n @Host[/Port[#Key]]] -i EventId -C -O -B -A -G -S "Slot=Value[{;Slot=Value}]"

Table 130 msetmsg options (part 1 of 2)

Option Description

-i EventId specifies the event handle of the event to be modified

-C sets the status value of the specified event to CLOSED

-O sets the status value of the specified event to OPEN

-A sets the status value of the specified event to ACK



msetmsg example

To close an event whose event ID (event_handle) is 12981, type the command shown in Figure 198.

If this command is successful, it does not produce output.

msetmsg return codes

Table 131 lists the command-specific return codes for msetmsg. For a list of common return codes that apply to all CLI commands, see “ BMC Impact Manager CLI common return codes” on page 384.

-G sets the status value of the specified event to ASSIGNED

-B sets the status value of the specified event to BLACKOUT

-S "Slot=Value[{;Slot=Value}]" specified the slot to be modified and the changes to be made to the slot’s value

Figure 198 Using msetmsg to close an event

msetmsg -n cellName -i 12981 -C

Table 131 msetmsg return codes

Code Description

31 no event handle specified

32 failed to set message

Table 130 msetmsg options (part 2 of 2)

Option Description


msetrec—Setting the value of a global record

msetrec—Setting the value of a global record

Use the msetrec command to set the field values in a global record. Global records are +defined in the records directory of a Knowledge Base. The cell uses global records as global variables in rules.

msetrec syntax

Figure 199 shows the syntax for msetrec.

Table 132 lists the command-specific options for msetrec. For a list of common command options that apply to all CLI commands, see “ BMC Impact Manager CLI common command options” on page 383.

msetrec example

Figure 200 shows an example of msetrec.

Figure 199 msetrec syntax

msetrec [-h|?] [-z] [-q] [-c ConfigFile] {-p "Var=Value"} [-n cellName | -n @Host[/Port[#Key]]] -r Record -S Slot -V Value

Table 132 msetrec options

Option Description

-b specifies slot value assignment

-r Record specifies the global record containing the Slot to be modified

-S Slot specifies the Slot to be modified

-V Value specifies the Value to set for the specified Slot

Figure 200 Example of msetrec

msetrec -n <cellName> -r test_rec -S slot_list_int -V ‘[4,5,6]’


BMC Impact Manager CLI configuration

msetrec return codes

Table 133 lists the command-specific return codes for msetrec. For a list of common return codes that apply to all CLI commands, see “ BMC Impact Manager CLI common return codes” on page 384.


The mclient.conf file contains the default client options for configuring CLIs. Most of the cell configuration options also can be specified for CLIs. For a more information, see “ Cell configuration parameters” on page 444.

The configuration options use the following syntax: option=value, where value equals one of the following:

■ Boolean: Yes | On | No | Off■ Number■ String■ Path

Table 134 describes the CLI configuration parameters.

Table 133 msetrec return codes

Code Description

31 failed to set record slot

Table 134 BMC Impact Manager CLI configuration parameters (part 1 of 3)

Option Description/DefaultDefault value

ServerName specifies the name of the cell; an alternative for the -n cellName option

HostName

ServerLocation the host name or IP address of the cell HostName

ServerDirectoryName specifies the name of the cell directory file mcell.dir

ServerPort specifies the TCP/IP port number where the cell listens for all in-bound requests from sources, such as the BMC Impact Explorer, CLIs, and adapters

1828

Encryption enables or disables encryption to and from the cell Yes

EncryptionKey used by encryption process as part of the encoding key no default



ConnectionSetupTimeOut the maximum time, in seconds, that a CLI command attempts to establish a connection to a cell

If the connection with the cell cannot be completely established within this timeframe, the command aborts.

Note that if the cell is busy with a database cleanup, it may be impossible to connect the CLI with the default values. A database cleanup has a duration limit defined by the EventDBCleanupDurationLimit option, with a default value of 30 seconds. With a default ConnectionSetupTimeOut of 10 seconds, the connection cannot be established within the first 20 seconds of a cleanup.

10 (seconds)

ConnectionPortRange specifies the range of ports to use for outgoing connections

It is the port used on the client side. This is useful only to pass the event through firewalls with high restrictions. Most firewall configurations ignore source port information but require destination port information. However, firewall configuration usually can restrict the source ports as well.

The syntax is PortRange = PortSequence {, PortSequence} PortSequence = Port [- Port]

Warning: On Windows platforms, when using ConnectionPortRange for a CLI running on the same machine as the cell, it is possible that the CLI will not be able to connect. This can occur when the CLI needs more than one attempt to connect (for instance, because the cell was too busy during the first attempt). Subsequent connection attempts will fail due to limitations of the OS.

empty

ConnectionPortReuse indicates whether or not the ports specified in ConnectionPortRange should be reused as much as possible

By default the cell tries to reuse ports from the specified range, in the given order. When ConnectionPortReuse=No, for every new connection within the same session, the next free port from the specified range is used. Only when it reaches the end of the range will it restart at the beginning of the range.

Yes




Configuring tracing for BMC Impact Manager CLI commands

Configuring tracing for BMC Impact Manager CLI commands

You configure CLI command tracing in the MCELL_HOME\etc\mclient.trace file. The mclient.trace file uses the same parameters as the mcell.trace configuration file. For details on the cell tracing configuration, see “ Configuring cell tracing” on page 73.

BMC Impact Manager CLI trace configuration

Tracing of CLIs is configured in the MCELL_HOME\etc\mclient.trace file.

To send tracing output to a text file, add the line of code shown in Figure 201 to the mclient.trace file.

This line produces tracing to the MCELL_HOME\tmp\mclient\out.txt file.

MessageBufferSize the number of messages, or events, retained in the buffer when the cell is unable to send, or when waiting for an answer; a message that is not sent because the destination is down, for example, or a message that was sent but not yet answered, remains in the buffer

2000

MessageBufferCleanupPercentage 10

MessageBufferReconnectInterval the time interval, in seconds, in which the cell attempts reconnection to a destination if the original connection failed

600

MessageBufferKeepWait The amount of time, in seconds, that messages are retained in the buffer until they can be sent.

Once the specified time elapses, the retained messages are removed from the buffer.

3600

MessageBufferKeepSent the time, in seconds, to keep sent messages buffered while waiting for an answer

300

MessageBufferResendCount the number of times to resend unanswered messages 1

Figure 201 command to send tracing output to text file

ALL ALL out.txt




A p p e n d i x C
C mcell.conf file parameters
This appendix discusses all of the parameters in the mcell.conf file and contains the following topics:

Action result event parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444Cell configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444Cell failover configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446Client communication parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447Encryption parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449Event repository cleanup parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450Heartbeat parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452Internal cell monitor parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455KB parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455Propagation parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456Reporting client connection parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459Service model parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460StateBuilder parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460Trace parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461


Action result event parameters

Action result event parameters

Cell configuration parameters

Table 135 Action result event parameters

Parameter Description Type Default value

ActionResultInlineLimit the size limit, in bytes, for an action result to be included directly in the action result event slots

This applies to both the output stream (slot "output_val") and the error stream (slot "error_val"). If the respective result is larger than the indicated size, it is stored in a file.

Instead of placing the value directly in the *_val slot, the reference to the file is placed in the corresponding *_ref slot.

number 4096 (4 KB)

ActionResultKeepPeriod the period, in seconds, that an action result is kept on behalf of a (Browser) client

The client should retrieve the result within that period. After the period has expired, the result is dropped. This is independent of the action result event. A generated action result event is not influenced by this parameter. It exists as long as other events.

number 120 (2 minutes)

Table 136 Cell configuration parameters


CellDescription used as the initial value of the cell_description slot of the internal MC_CELL_INFO record

string BMC Impact Manager

CellOperationLevel indicates the level on which the cell must operate

The operation level determines from which clients the cell accepts connections and events. The default value can accept connections from any computer.

string Consolidation

CellOperationRelax indicates whether the operation level should be lowered in case there is no license available for the desired level, as set by CellOperationLevel

Typically, more license tokens are available for lower operation levels.

Boolean No


Cell configuration parameters

ConnectionPortRangea specifies the range of ports to use for outgoing connections

For forward propagation, this port is used on the client side (or on the propagating cell side). This is useful to pass the event through firewalls with high restrictions. Most firewall configurations ignore source port information but require destination port information. However, firewall configuration usually can restrict the source ports as well.

string empty

ConnectionPortReusea indicates whether or not the ports specified in ConnectionPortRange should be reused as much as possible

By default, the cell or command line interface (CLI) tries to reuse ports from the specified range, in the given order. When ConnectionPortReuse=No, for every new connection within the same session, the next free port from the specified range is used. Only when it reaches the end of the range will it restart at the beginning of the range.

Boolean Yes

ProcessingLimitPercentage

specifies limitation of event processing speed

At 100% the cell accepts events as fast as it can. At x% it does not accept events during (100-x)% of the time. This limits the cell’s CPU utilization.

number 100%

ServerAllInterfaces determines whether the cell listens on one specific interface or on all available interfaces

When ServerAllInterfaces=Yes, the cell communicates on all network interfaces on the host. When ServerAllInterfaces=No, the cell only communicates with the network interface that has the IP address specified in the mcell.dir file of that cell.

Boolean Yes

ServerDirectoryNamea specifies the name of the cell directory file path mcell.dir

ServerPorta specifies the TCP/IP port number at which the cell listens for all in-bound requests from sources, such as the BMC Impact Explorer console, CLIs, and adapters

number 1828

SystemLogDirName specifies the path to the default system-defined log directory

path %H/log

SystemTmpDirName specifies the path to the default system-defined tmp directory

path %H/tmp

a Can also be used in the mclient.conf configuration file, which affects the behavior of all of the BMC Impact Solutions CLI commands. These parameters retain the same qualities and definitions in the mclient.conf file as they have in the mcell.conf file.

Table 136 Cell configuration parameters (continued)



Cell failover configuration parameters

Cell failover configuration parametersTable 137 Cell failover configuration parameters


CellDuplicateAutoFailOver determines whether the primary server automatically fails over to the secondary server.

For automatic failover to occur, this parameter must be set to YES on both servers.

Boolean Yes

CellDuplicateAutoSwitchBack determines whether the secondary server automatically switches back to the primary server when the primary server restarts after failover.

For automatic switchback to occur, this parameter must be set to YES on both the primary and secondary servers.

Boolean Yes

CellDuplicateFailOverStartTimeOut

specifies the length of time (in seconds) that the secondary server waits to become active after it is started.

When the secondary server starts, it expects the primary to connect to it. If the primary server does not connect to the secondary within the time specified by the CellDuplicateFailOverStartTimeOut parameter, the secondary server will become active.

The time specified for CellDuplicateFailOverStartTimeOut should be longer than the time specified for CellDuplicateFailOverTimeOut to allow operators to start up primary and secondary servers at almost the same time, in any order.

number 120


Client communication parameters


CellDuplicateFailOverTimeOut specifies the length of time (in seconds) that the secondary server waits to become active after the secondary server loses connection to the primary server.

number 30

CellDuplicateMode specifies the operation mode of the server.

1 = primary server2 = secondary server0 = the server is operating as a non-high availability cell.

This is the only parameter that needs a different value between primary and secondary.

number 0

Table 138 Client communication parameters


ClientCleanupInterval the interval, in seconds, between clean-ups of pending clients

After each such period, clients that did not give the cell a notice of life are disconnected.

number 300

ClientPollTimeOut the maximum time, in milliseconds, the cell waits for a client request before it continues processing

number 200 milliseconds

ClientSendTimeOut the time interval, in milliseconds, that the cell has to send a packet to a client on the lowest communication level


DateFormat the format used to display timestamps in the date slot

A default value of CIM indicates use of the Common Information Model (CIM) format from the Desktop Management Force Group.

DateFormat parameters use the syntax of %[letter]. Table 139 on page 448 lists the DateFormat parameters for Solaris; for other operating systems, see their documentation.

string CIM

SynchronizeTimeOut the maximum time, in milliseconds, the cell waits for synchronization before dropping a connection


Table 137 Cell failover configuration parameters (continued)




If the cell receives an event with an empty value for the date slot, it sets the date slot to the textually formatted value of the date_reception slot. That value is determined by the DateFormat parameter. This assignment is performed only once, when the event first enters the cell. If the cell is shut down and restarted, the value of date remains the same even if the DateFormat parameter has been modified in the interval.

The CIM format is yyyymmddhhmmss.mmmmmmsutc, where:

yyyy = yearmm = monthdd = dayhh = hour, based on 24-hour clockmm = minutesss = secondsmmmmmm = microsecondss = + or -utc = offset in minutes from UTC; UTC is the Universal Time Coordinate system

Table 139 lists the parameters from the Solaris platform. Other platforms, including UNIX and Microsoft Windows platforms, may have slight differences.

Table 139 Date and time format parameters for Solaris (part 1 of 2)


%% same as %

%a locale’s abbreviated weekday name

%A locale’s full weekday name

%b locale’s abbreviated month name

%B locale’s full month name

%c locale’s appropriate date and time representation

%C locale’s date and time representation as produced by date (1)

%d day of month [1,31]; single digits are preceded by zero (0)

%D date as %m/%d/%y

%e day of month [1,31]; single digits are preceded by a space

%h locale’s abbreviated month name

%H hour (24-hour clock) [0,23]; single digits are preceded by zero (0)

%I hour (12-hour clock) [1,12]; single digits are preceded by zero (0)

%j day number of year [1,366]; single digits are preceded by zero (0)

%k hour (24-hour clock) [0,23]; single digits are preceded by a blank

%l hour (12-hour clock) [1,12]; single digits are preceded by a blank

%m month number [1,12]; single digits are preceded by zero (0)

%M minute [00,59]; initial 0 is permitted but not required

%n insert a new line


Encryption parameters

Encryption parametersTable 140 lists the encryption parameters.

%p locale’s equivalent of A.M. or P.M.

%r appropriate time representation in 12-hour clock format with %p

%R time as %H:%M

%S seconds [00,61]

%t insert a tab

%T time as %H:%M:%S

%u weekday as a decimal number [1,7], where 1 represents Sunday

%U week number of year as a decimal number [00,53], where Sunday is the first day of week 1

%V week number of the year as a decimal number [01,53], where Monday is the first day of the week

If the week containing January 1st has four or more days in the new year, then it is considered week 1. Otherwise, it is week 53 of the previous year, and the next week is considered week 1.

%w weekday as a decimal number [0,6], where 0 represents Sunday

%W week number of year as a decimal number [00,53], where Monday is the first day of week 1

%x locale’s appropriate date representation

%X locale’s appropriate time representation

%y year within century [00,99]

%Y year, including the century. (for example, 2006)

%Z time zone name or abbreviation, or no bytes if no time zone information exists

Table 140 Encryption parameters (part 1 of 2)


AllowAdapterFrom specifies the adapters within the range of IP addresses

These are adapters that use the BMC Impact Solutions communications protocol.

string 0./0

AllowBrowserFrom specifies the BMC Impact Explorer and the BMC Impact Portal connections within the range of IP addresses

string 0./0

AllowCellFrom specifies the cells within the range of IP addresses string 0./0

AllowCLIFrom specifies the command line interfaces (for example, mkill or mcstat) within the range of IP addresses

string 0./0

AllowConnectionFrom specifies the client within the range of IP addresses that is allowed to connect to a cell

string 0./0

Table 139 Date and time format parameters for Solaris (part 2 of 2)



Event repository cleanup parameters


AllowEIFFrom specifies the EIF event sources (for example, a postemsg) within the range of IP addresses

string 0./0

Encryption specifies to use encryption Boolean Yes

EncryptionKey specifies the encryption key string (empty)

ForceEncryption specifies if encryption is to be forced Boolean No

Table 141 Event Repository cleanup parameters


EventAutoClose automatically closes a duplicate event in the database when an event arrives with status=CLOSED, or it is closed in the Refine rule phase

If the default value is left as Yes, the event is dropped and the duplicate is closed. If the value is set to No, there is no duplicate detection and the CLOSED event is not dropped.

Boolean Yes

EventDBCleanupDurationLimit the maximum duration, in seconds, of a single cleanup

After expiration of that period, the cleanup is interrupted. Normal operation proceeds for an equal duration. Then cleanup is resumed, with the same limit again.

number 30

EventDBCleanupInterval the time interval, in seconds, between periodic cleanups of the repository

number 3600, or 1 hourminimum = 60; no maximum

EventDBCleanupPercentage the percentage of free space required at termination of an EventDB cleanup

With a default EventDBSize of 100000, this means that at least 10000 places must be available at termination of a completed cleanup.

number 10minimum=5; no maximum

EventDBCleanupOnDateReception indicates the preference for deleting events from the repository based on when they were received instead of when they were last modified

Boolean No

Table 140 Encryption parameters (part 2 of 2)




The related group of event cleanup parameters gives you control over which events are removed, limits the duration of the cleanup, and specifies a preference for cleaning up closed events rather than older events.

EventDBCleanupPreferClosed indicates the preference for cleaning up closed events rather than older events

When there is not enough free space after removing all expired events, additional, unexpired events are removed. These are selected, oldest first, either from any events or from the closed ones first.

The default is no, meaning that the event status value is not taken into account when selecting events for removal.

Boolean No

EventDBKeepClosed the minimum age, in seconds, of CLOSED events before they are removed from the repository

Note: Any modifications to the EventDBKeepClosed parameter should be carefully considered. Events of these classes remain in the event repository until you manually delete them.

number 604800, or 7 days; no minimum; no maximum

EventDBKeepNonClosed the minimum age, in seconds, of non-closed events before they are removed from the repository

number 2592000, or 30 daysminimum value=0;maximum value =4294967295, or 136 years

EventDBSize the number of events to retain in the repository

The default size is 100000.

number 100000minimum value=100;no maximum

EventDBNoCleanupClosed list of classes in which closed events will not be deleted from the repository

string empty

EventDBNoCleanupNonClosed list of classes in which non-closed events will not be deleted from the repository; comma separated

Boolean SMC_STATE_CHANGE

Table 141 Event Repository cleanup parameters (continued)



Heartbeat parameters

A cleanup first removes expired events. Expired events are those that are older than the times in the EventDBKeepClosed and EventDBKeepNonClosed parameters, for closed and non-closed events, respectively. After this cleanup, if there is still less free space than specified in the EventDBCleanupPercentage parameter, additional, unexpired events are removed. As many events are removed as needed to reach the desired amount of free space.

Older events are removed first, with one possible exception. If parameter EventDBCleanupPreferClosed=Yes, closed events are removed first, even if some older unclosed events remain. In EventDBCleanupPreferClosed=No mode, all events are considered, starting with the oldest first.

The mc_date_modification slot is considered to determine the time of an event. However, if parameter EventDBCleanupOnDateReception=Yes, the date_reception slot is considered instead.

Cleanup is interrupted if it takes longer than the value of the EventDBCleanupDurationLimit parameter. By default, this value is 30 seconds. If the cleanup period was not long enough to remove all expired events, a new cleanup is scheduled for a later time with the same amount of time as the duration limit. If all expired events were removed, the next cleanup is scheduled after the normal interval value of EventDBCleanupInterval.


The heartbeat feature allows a specific cell, called the monitoring cell, to monitor one or more cells, called the monitored cell or cells, for enabled access by the monitoring cell.

Table 142 Heartbeat parameters


HeartbeatEnabled indicates whether the heartbeat monitoring mechanism is enabled or not

Boolean Yes

HeartbeatInterval the default interval between two beats, if not specified in the data object

number 60

HeartbeatMissedCritical the default number of consecutive missed beats that are needed to generate a critical event, if not specified in the data object

number 3

HeartbeatMissedMinor the default number of consecutive missed beats that are needed to generate a minor event, if not specified in the data object

number 2

HeartbeatMissedWarning the default number of consecutive missed beats that are needed to generate a warning event, if not specified in the data object

number 1



The parameter in the mcell.conf file of the monitored cell should be HeartbeatEnabled=Yes. By default, the monitored cell sends a beat every 300 seconds.

Heartbeats are configured through MC_CELL_HEARTBEAT dynamic data objects in the monitoring cell. An MC_CELL_HEARTBEAT dynamic data object contains information, such as the name of the cell to be monitored, the length of the expected time intervals between the heartbeats, and the number of heartbeats that must be missed to generate corresponding internal events in the monitoring cell.

The cell receives the dynamic data object either by loading it from the data directory, receiving it through an mposter call, or viewing it in the Administrative View of the BMC Impact Explorer. The monitoring cell sends a request to the monitored cell. The monitored cell sends a heartbeat back to the monitoring cell at the specified intervals. If the monitoring cell does not receive a heartbeat in the expected timeframe, the monitoring cell generates an alert that can be viewed in the BMC Impact Explorer console.

The default settings for missing heartbeats are as follows:

■ 1 missed heartbeat generate a warning event■ 2 missed heartbeats generate a minor event■ 3 missed heartbeats generate a critical event

For example, in Figure 202 on page 453, cell 1 is the monitoring cell, which sends a request to cell 2, the monitored cell. If it does not receive a response at a specified interval, then the monitoring cell sends an alert that can be seen in the BMC Impact Explorer.

Figure 202 Example of Heartbeat

After a monitoring cell terminates and restarts, it is aware of prior requests for heartbeats because it rereads the dynamic data objects that are stored in the cell repository mcdb. After it rereads the data, the monitoring cell attempts to resend the request to the monitored cell.

Request

Heartbeat

cell 1 cell 2



If the monitored cell terminates, the monitoring cell resends the request for heartbeats at the specified intervals. Table 143 lists the MC_CELL_HEARTBEAT slots.

Table 143 Heartbeat slots

Slot Description

cell target monitored cell name

enable 0 = disabled, 1 = enabled

last_time time last heartbeat was received

interval length of interval between heartbeats

Specify zero (0) to use the default, as determined by the HeartbeatInterval configuration parameter.

missed_warning number of missed heartbeats before a WARNING event is generated

Specify zero (0) to use the default, as determined by the corresponding HeartbeatMissedWarning configuration parameter. Specify -1 to disable generation of the corresponding event.

missed_minor number of missed heartbeats before a MINOR event is generated

Specify zero (0) to use the default, as determined by the corresponding HeartbeatMissedMinor configuration parameter. Specify -1 to disable generation of the corresponding event.

missed_critical number of missed heartbeats before a CRITICAL event is generated

Specify zero (0) to use the default, as determined by the corresponding HeartbeatMissedCritical configuration parameter. Specify -1 to disable generation of the corresponding event.

missed number of consecutive missed heartbeats

NOTE Deleting an instance of an MC_CELL_HEARTBEAT data object from a monitoring cell terminates the monitoring of the corresponding cell or cells.


Internal cell monitor parameters

Internal cell monitor parameters

KB parameters

Table 144 Internal cell monitors parameters


CellEventEnable a flag that indicates whether the cell should generate internal events, such as start, stop, and heartbeat; does not include events generated by the rules

Boolean Yes

CellErrorEvents indicates whether an event processing error should produce a special internal event to flag that error, or not

Boolean Yes

CellMetricsEnabled determines whether metrics for cell performance are collected or not

Boolean Yes

CellTickInterval the time interval, in seconds, between generation of cell heartbeat events (ticks)

The purpose of such heartbeats is to send a sign of life from the cell. A zero (0) value disables cell ticks without disabling other internal events. This parameter operates only if the CellEventEnable is set to Yes.

number 600

RuleLoopDetect a flag that requires the cell to check for certain conditions that can induce infinite looping of events

Setting this parameter to Yes can cause mild cell performance degradation.

Boolean No

Table 145 KB parameters


KBDirName the path to the active KB directory path the kb directory in the cell’s cell-specific configuration directory

KBRecoveryDirName the path to an alternate kb directory to be used for recovery from catastrophic damage

For more information, see “mrecover—Recovering from a catastrophic data loss” on page 432.

path kbrecovery


Propagation parameters

Propagation parametersThe propagation parameters allow you to configure propagation and destination buffers.

You can configure these parameters for individual destinations and also configure a default value for all other destinations. Use the asterisk (*) to specify all destinations. The following parameter definition illustrates how to configure these parameters for all destinations.

This example specifies that the interval to try to reconnect is 600 seconds for all destinations. If the * is not explicitly defined, the default value for the parameter will be applied to all destinations.

To configure parameters for individual destinations, the value for these parameters is formatted as a comma-separated sequence of destination-specific settings in the form of DestinationName=Value. DestinationNames #1 and #2 are reserved to indicate the primary and secondary nodes of a high availability cell.

For example,

This example specifies that the interval to try to reconnect is 10 seconds for the high availability nodes, 1200 seconds for a cell called SlowCell and 600 seconds for all other destinations. If the * is not explicitly defined, the default value for the parameter will be applied to all unspecified destinations.

DestinationBufferReconnectInterval = *=600

DestinationBufferReconnectInterval = #1=10,#2=10,*=600,SlowCell=1200

Table 146 Propagation parameters

Parameter Description TypeDefault value

DestinationBufferBaseSize the initial number of messages, or events, retained in the buffer

number 5000

DestinationBufferExpandPercentage percentage of the actual buffer size that the buffer expands when events continue to be propagated after the buffer is full

number 10


Propagation parameters

DestinationBufferSizeLimit maximum allowed buffer size

The default value of 0 means the buffer size is unlimited. In practice, the size is limited to 2^32-1, or to the available amount of memory.

If the limit is set to a value lower than DestinationBufferBaseSize, the buffer will not expand beyond DestinationBufferBaseSize.

number 0

DestinationBufferReducePercentage minimum percentage of free buffer size required to perform a reduction

number 50

DestinationBufferKeepSenta the time, in seconds, to keep sent events buffered while waiting for an answer

number 300

DestinationBufferKeepWait The amount of time, in seconds, that events are retained in the buffer until they can be sent.

Once the specified time elapses, the retained events are removed from the buffer.

number 3600, or 1 hour

DestinationBufferReconnectInterval the time interval, in seconds, in which the cell attempts reconnection to a destination if the original connection failed

The cell continues to reestablish a connection as long as there are events in the buffer.

number 600

DestinationBufferResendCount the number of times to resend unanswered events

number 1

PropagateBufferBaseSize the number of requests for propagation to retain in the propagation buffer

Such a request corresponds to firing a Propagate rule. There is one propagate buffer per cell with as many places for requests as set by the parameter.

number 20000

PropagateBufferExpandPercentage percentage of the actual buffer size that the buffer expands when events continue to be propagated after the buffer is full

number 10

Table 146 Propagation parameters (continued)



Deprecated MessageBuffer propagation parameters

Deprecated MessageBuffer propagation parameters

The MessageBuffer propagation parameters described in this section have been deprecated, but are retained for backward compatibility with earlier versions of BMC Impact Manager. These parameters may be removed in a later version of the product.

If one of the DestinationBuffer parameters is not specified, or if it does not contain a default setting, the value of the corresponding MessageBuffer parameter is used as default. If the corresponding MessageBuffer parameter is not specified, an internal default value is used.

PropagateBufferSizeLimit maximum allowed buffer size

The default value of 0 means the buffer size is unlimited. In practice, the size is limited to 2^32-1, or to the available amount of memory.

If the limit is set to a value lower than PropagateBufferBaseSize, the buffer will not expand beyond PropagateBufferBaseSize.

number 0

PropagateBufferReducePercentage minimum percentage of free buffer size required to perform a reduction

number 50

PropagateConfigFileName the name of the propagation configuration file

path mcell.propagate


Table 147 Deprecated MessageBuffer propagation parameters


MessageBufferSize the initial number of messages, or events, retained in the buffer

number 5000

MessageBufferKeepSenta the time, in seconds, to keep sent messages buffered while waiting for an answer

number 300

MessageBufferKeepWait The amount of time, in seconds, that messages are retained in the buffer until they can be sent.

Once the specified time elapses, the retained messages are removed from the buffer.

number 3600, or 1 hour

Table 146 Propagation parameters (continued)



Reporting client connection parameters

Reporting client connection parametersTable 148 lists the parameters that report on client operations on the cell.

MessageBufferReconnectInterval the time interval, in seconds, in which the cell attempts reconnection to a destination if the original connection failed

The cell continues to reestablish a connection as long as there are messages in the buffer.

number 600

MessageBufferResendCount the number of times to resend unanswered messages

number 1

MessageBufferSize the number of messages, or events, retained in the buffer when the cell is unable to send, or when waiting for an answer; a message that is not sent because the destination is down, for example, or a message that was sent but not yet answered, remains in the buffer

A cell maintains one buffer for each destination. Such buffers have the same size, as set by the parameter.

number 20000

PropagateBufferSize the number of requests for propagation to retain in the propagation buffer

Such a request corresponds to firing a Propagate rule. There is one propagate buffer per cell with as many places for requests as set by the parameter.

number 20000


Table 148 Reporting client connection parameters


ReportConnectClients reports connect and disconnect of clients

string browser, Console, ImpactExplorer, mcontrol, mkill, mposter, msetmsg, msetrec

ReportModifyClients reports modifications of events by clients

string mposter, msetmsg, msetrec

Table 147 Deprecated MessageBuffer propagation parameters (continued)



Service model parameters

Service model parametersTable 149 lists the parameters that control the service model.

StateBuilder parametersThe running of the StateBuilder is controlled by the cell, using the parameters in the mcell.conf file. Table 150 lists the StateBuilder parameters.

Table 149 Service model parameters


ServiceModelPublish controls whether or not Service Model Data is published

Note: If ServiceModelPublish is disabled, the ServiceModelDirectFeed parameter has no impact. In this case, Service Model Data is always accepted through direct feed.

Boolean YES

ServiceModelDirectFeed when ServiceModelPublish is enabled, ServiceModelDirectFeed controls whether or not Service Model Data is accepted through direct feed

Boolean NO

Table 150 StateBuilder parameters


StateBuildInterval the time interval, in seconds, between two builds of saved states of the cell

number 3600

StateBuildSize the maximum size, in kilobytes, of a transaction file before it is transformed into a new saved state when the StateBuilder runs again.

If BMC Impact Manager seems to be consuming too much CPU, verify that State Builder is not running too frequently. Compare the time stamps of the mcdb.* files in the log directory of the cell. If the time between two state builds is less than 10 minutes, increase the StateBuildSize parameter.

number 1000

StateBuildConfigFileName the StateBuilder configuration file name path statbld.conf

StateBuildAtTerminate indication to run the StateBuilder when the cell terminates

Boolean No

StateBuildRunTimeOut the timeout, in seconds, to consider when waiting for the StateBuilder to terminate

number 600 seconds


Trace parameters

Trace parametersTable 151 Cell tracing parameters


Tracea allows the generation of trace messages Boolean Yes

TraceSrc includes the file and line number in the trace messages Boolean No

TraceConfigFileName location of the file containing the configuration of the trace messages

path mcell.trace

TraceDefaultFileName destination file to redirect trace messages from stderr to, in case the cell runs as a daemon or service

path %T/trace

TraceRuleLevel sets the level of rule execution tracing:

■ 0—no rule tracing and no cell error catch (not recommended)

■ 1—no rule tracing; cell errors are caught in the standard cell trace (default)

■ 2—rule tracing enabled

number

TraceRulePhases When rule tracing is enabled, lists the rule phases to be traced. The value ALL can be used to specify that all phases are to be traced. Each phase can be prefixed with a + or a - sign to indicate addition or removal from the list. The list is interpreted in sequential order.

For example, the following parameter setting:TraceRulePhases=ALL,-refine,-regulate

indicates that all rule phases will be traced except for the refine and regulate phases.

NOTE: TraceRulePhases and TraceRuleName work together to determine which rules are traced. A rule is only traced if both the phase to which it belongs and the rule itself are configured for tracing.

string ALL


Trace parameters

TraceRuleNames When rule tracing is enabled, lists module:rule combinations to be traced. The value ALL can be used to specify that all modules and/or rules are to be traced. Each module:rule combination can be prefixed with a + or a - sign to indicate addition or removal from the list. The list is interpreted in sequential order.

For example, the following parameter setting:TraceRuleNames=HelpDesk:ALL,-HelpDesk:rule1,SendMail:rule1

indicates that all rules in the HelpDesk module will be traced except for rule1. Additionally, rule1 from the SendMail module will be traced.

NOTE: TraceRulePhases and TraceRuleNames work together to determine which rules are traced. A rule is only traced if both the phase to which it belongs and the rule itself are configured for tracing.

string

TraceRuleHeader allows you to configure the header text of the trace messages. You can configure the header text to contain references to parameters, using the following designations to represent the associated parameters:

■ %I — message id ■ %F — source file name ■ %L — source line number ■ %M — KB module name ■ %R — rule name ■ %P — rule phase ■ %H — handle of the main event being processed

(event_handle slot) ■ %C — class name of the main event being

processed

For example, the default parameter settingTraceRuleHeader=%F, %L: %P %R: %C #%H:

results in a message similar to:mc_intevt.mrl, 42: new StbldStop: MC_CELL_STATBLD_STOP #118: Rule execution starting

text %F, %L: %P %R: %C #%H:

TraceRuleToXact indicates whether to include rule tracing in the transaction file, as well as in the standard cell trace, in module RULES

Boolean No

Table 151 Cell tracing parameters (continued)



Trace parameters

TraceFileSize limit on the size of a trace destination file, expressed in kilobytes

When the trace file grows beyond the indicated size, it is renamed with a numerical suffix appended. A new trace file is started.

Special value 0 (the default) means no limitation on file size.

number

TraceFileHistory number of trace files to be kept in history

When this number is reached, a new numbered trace file will remove the oldest one.

number 0

TraceFileAppend indicates whether to append to existing trace files or empty existing trace files at startup

Boolean Yes


Table 151 Cell tracing parameters (continued)



Trace parameters


A p p e n d i x D
D Environment variables
The installation process creates or updates environment variables used by BMC Impact Solutions.


Microsoft Windows environment variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466Recreating environment variables on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466UNIX environment variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467Recreating environment variables on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467


Microsoft Windows environment variables

Microsoft Windows environment variablesTable 152 lists the Windows environment variables for BMC Impact Solutions.

Recreating environment variables on WindowsAn executable is available for backward compatibility and the rare occasion when the environment variables must be recreated on the same system or a different system.

To recreate the environment variables, run the following script:

..\system32\drivers\etc\mcell\setup_env.bat

Table 152 Microsoft Windows environment variables

Environment variable Full path name Default directory

BMC_PORTAL_KIT_HOME

defines the path to BMC Impact Portal configuration files and executable files

%BMC_PORTAL_KIT_HOME% C:\BMCSoftware\BMCPortalKit\

DATASTORE_HOME

defines the path to the BMC Datastore files

%DATASTORE_HOME% C:\BMCSoftware\Datastore

MCELL_HOME

defines the path to BMC Impact Manager configuration files and executable files

%MCELL_HOME% C:\Program Files\BMC Software\MasterCell\server


UNIX environment variables

UNIX environment variablesTable 153 lists the UNIX environment variables for BMC Impact Solutions.

Recreating environment variables on UNIXAn executable is available for backward compatibility and the rare occasion when the environment variables must be recreated on the same system or a different system.

To recreate the environment variables, run one of the following scripts:

. /etc/mcell/mcadapter/setup_env.shsource /etc/mcell/mcadapter/setup_env.csh

Table 153 UNIX environment variables

Environment variable Full path name Default directory

BMC_PORTAL_KIT_HOME

defines the path to BMC Impact Portal configuration files and executable files

$BMC_PORTAL_KIT_HOME /opt/bmc/BMCPortalKit

DATASTORE_HOME

defines the path to the BMC Datastore files

$DATASTORE_HOME /opt/bmc/Datastore

MCELL_HOME

defines the path to BMC Impact Manager configuration files and executable files

$MCELL_HOME /opt/mcell


Recreating environment variables on UNIX


A p p e n d i x E
E BMC Microsoft Windows services and UNIX
processes

This appendix describes the services and processes for BMC Impact Solutions products and components.


BMC Microsoft Windows services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470BMC UNIX processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470


BMC Microsoft Windows services

BMC Microsoft Windows servicesTable 154 lists the Microsoft Windows services for BMC Impact Solutions products and components.

BMC UNIX processesTable 155 lists the UNIX processes for BMC Impact Solutions products and components.

Table 154 BMC Microsoft Windows services

Service name

datastore ■ BMCPDSAgent VM IC7 has ‘OracleBMCPDSORA92Agent’

■ BMCPDSListener VM IC7 has ‘OracleBMCPDSORA92TNSListener’

■ BMCPDSService VM IC7 has ‘OracleServiceBMCPDS’

Portal appserver ■ BMC Portal

Portal webserver ■ BMCPortalWebserver

BMC Atrium CMDB ■ AR System Portmapper■ Remedy Action Request System Server

mcell ■ mcell_cellName

BMC Impact Publishing Server

■ BMC Impact Publishing Server

Impact Integration Web Services

■ SIM Web Services VM IC7 has ‘iiws_cellName’

Table 155 BMC UNIX processes

These names are shown as part of the string

datastore ■ BMCPDS

BMCPDS is the default; the process name is user-defined during installation

Portal appserver ■ bmc/BMCPortalKit/appserver

Portal webserver ■ bmc/BMCPortalKit/webserver

BMC Atrium CMDB ■ bmc/cmdb/bin/arserverd ■ bmc/cmdb/bin/arsvcdsp■ bmc/cmdb/bin/armonitor

mcell ■ mcell –n cellName


BMC UNIX processes

BMC Impact Publishing Server

■ pserver

Impact Integration Web Services

■ iiws

Table 155 BMC UNIX processes

These names are shown as part of the string


BMC UNIX processes


A p p e n d i x F
F BMC Impact Event Adapters MAP files
This appendix discusses how to define the syntax of and how to use a MAP file.

Default MAP files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474Custom maps and map-related files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474

Custom MAP files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474Customized Perl MAP-functions file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475

MAP file structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486

OverviewWhen an event is read by an Adapter, the Adapter must convert the event from its internal representation, such as a Perl hash, into the BMC Impact Manager compatible format, the BAROC language. The structure of the conversion is controlled by a special configuration file, the MAP file. Each Adapter uses its own MAP file to produce BMC Impact Manager events.

BAROC classes for Adapters are defined in the mcxa.baroc file, which is installed in the default Knowledge Base of each BMC Impact Manager Event Processor. The Adapters create a copy of this file in the MCELL_HOME\etc directory. This file also contains classes for standard events sent by msend and mposter.


Default MAP files

Default MAP filesTable 156 lists the default names for the MAP files of the different BMC Impact Event Adapters.

On UNIX platforms, MAP files are located in the MCELL_HOME/etc directory.

On Windows platforms, MAP files are located in the MCELL_HOME\etc directory.

Custom maps and map-related filesIf you want to expand map functionality beyond that offered using the default maps, you can create custom map files that produce the event formats that you require.

Custom MAP files

To use a MAP file other than the default, specify the path and name of the map file as the value of the MapFile parameter in the Adapter specification in the mcxa.conf file. For example:

MapFile = mymap.map

Table 156 Default MAP files

Adapter Default MAP file name

Perl EventLog for Windows mceventlog.map

LogFile mclogfile.map

SNMP Trap mcsnmptrapd.map

Apache LogFile mcapache.map

UNIX syslog mcsyslogd.map

TCP Client mctcpclt.map

TCP Server mctcpsrv.map

Telnet mctelnet.map

UDP Client mcudpclt.map

UDP Server mcudpsrv.map


Customized Perl MAP-functions file

Customized Perl MAP-functions file

The MAP file can use other MAP-functions files by using the REQUIRE directive in the configuration file. While you still can define customized functions in BMC Impact Manager, the REQUIRE directive should be used rather than the MapFunctionsName parameter. For more information, see “REQUIRE directive” on page 486.

Table 157 lists the default MAP-functions file for each Adapter.

By default, the MAP-functions file is located in MCELL_HOME/lib (UNIX) or in MCELL_HOME\lib (Windows).

MAP file structureThe structure of a MAP file is line-oriented. Each line can be one of the six (6) types of recognized statements:

■ a comment■ a define statement■ an input variables statement■ an initialization statement■ a default class statement■ a class statement

Sections

The MAP file can be divided into the following sections:

■ INPUT_VARIABLES

In this section, input variables from the Adapter are defined. Input variables statements belong in this section. See “INPUT_VARIABLES section” on page 476.

Table 157 Default map functions Perl files

Adapter MAP-functions file

Perl EventLog for Windows eventlogmap.pl

LogFile logfilemap.pl

SNMP snmptrapdmap.pl

Syslog syslogdmap.pl


Sections

■ INIT

In this section common initialization of the slots is performed. Init statements belong in this section. See “INIT section” on page 482.

■ DEFAULT

A default class is defined in this section. Default class statements belong in this section. See “DEFAULT section” on page 483.

■ CLASS

The mapping between BMC Impact Manager classes and internal Adapter classes is defined in the CLASS section. Class statements belong in this section. See “CLASS section” on page 483.

INPUT_VARIABLES section

Input variables take their value from the parsing of data received by the Adapter. Parsers do this by parsing a log file from a Syslog or LogFile Adapter, decoding a packet from an SNMP Adapter, or using a dedicated API from a user-defined Adapter. Variables are stored internally by the Adapter in the form a Perl Hash table. Variables must be declared inside the INPUT_VARIABLES structure in order to be recognized and used by the MAP file. The input variables are not chosen arbitrarily. They must correspond to the internal Perl structure of the event.

Single variables

The INPUT_VARIABLES section begins with a line that contains only the keyword INPUT_VARIABLES and ends with a line that contains only the keyword END. Within the section each variable is declared in a single line. The name of a variable must begin with the $ character.

Variables contain scalar values such as $avariable. These values are scalar in the context of the Perl language. They can represent a string or a number, depending on the variable definition. Therefore, these variables must be assigned only to relevant BMC Impact Manager slots.

NOTE These variables cannot be customized unless the method of event reception is changed.


Sections

The variables also can be references in Perl context to any type of object. Such reference variables cannot be used for slot assignment, except as references to a list as discussed below, but can be used as arguments of customized functions. If the variable is a reference to a Perl list, it can be an assignment value for a slot which is of the LIST_OF type.

Series of variables

The MAP file supports declaration of series of variables. The syntax is the same as for scalar variables except that the variable name must be followed by an interval of values. Three forms of acceptable declarations of sets are:

$setA 0—43$setB 43$setC 0—i

The first line declares 44 scalar variables, $setA1,$setA2,...,$setA43. The second line is equivalent to the first declaration. The third line declares a set of undefined size. In this case, variables $setC0, $setC1, $setC2, ..., $setC99 can be used in the MAP file. If the set has a size larger than 100, its size must be specified in the declaration. There is no size limit to sets other than your computer’s memory resources. In other words,

$set N

is equivalent to

$set0$set1...$setN

Order

Except in the variables declaration, the input variables section can contain comments. This section must be the first, as illustrated in the example of the input variables section of the SNMP Trap Adapter in Figure 203.

Figure 203 Comments code example

INPUT_VARIABLES$Version$Community$Enterprise$TrapType$Specific$TimeTicks$SourceAddr


Sections

The MAP file is case sensitive. $Source and $SOURCE are two different variables.

For backward compatibility, the $LOGFILE INPUT_VARIABLES contains the value of the LogLOGFILE parameter in the configuration file or “logfile” as default. A new INPUT_VARIABLE, $logname, is available and contains the name of the log file. In addition, the syntax of the parameters is changed to be consistent with all Adapters. Specific parameters to the LogFile Adapter begin with Log in which the ‘L’ is upper case.

Slot assignments

Most MAP file entries are either a slot assignment or a condition. A slot assignment is used to enter an input value into a BMC Impact Manager slot.

Unlike variables, the BMC Impact Manager slots are not declared in the MAP file. They are syntactically reproduced when they are sent to the cell. Figure 204 illustrates acceptable slot assignment formats:

$RequestId$ErrorStatus$ErrorIndex$EnterpriseName$TrapTypeStr

# Special INPUT_VARIABLES (references on list)$var$oid$oidt

# Variable for indexes. $idx is a reference on a list # of lists.# It cannot be used for direct slot assignments

$idxEND

Figure 204 Slot assignment formats

slot_name = 1234slot_name = “a string”slot_name = #mydefineslot_name = $variableslot_name = $variable[3]slot_name = buildlist (<args>, ...)slot_name = gethostbyaddr (<arg>)slot_name = gethostbyname (<arg>)slot_name = lower (<arg>)slot_name = printf (<format>, <args>, ...)slot_name = substr (<arg>, <start_pos>, <length>)slot_name = upper (<arg>)slot_name = <perl_func> (<args>, ...)

Figure 203 Comments code example


Sections

The first five lines are simple assignments either from constants (lines 1–3) or from a variable (lines 4 and 5). When slot_name is assigned to a constant, this constant is recognized from the first non-space character after the equal (=) sign, to the last non-space character on the same line.

Strings must be delimited by double quotes (“”). Because of the construction of a MAP file, a string cannot contain new lines. In order to include new lines in a string, a user-defined Perl function must be defined. For more detail, see the last assignment for slot_name containing <perl_func>. Strings can contain double quotes since the last double quote in the line is considered to be the end of the string.

Line 5 involves a substring of a variable, $variable. This corresponds to the matching substring of $variable, evaluated in a condition statement involving a regular expression matching $variable.

Slots can also be assigned to the return value of one of the seven functions as listed in Table 158. Functions are used to insert in a slot a value held by an entity in the network, such as the IP address of a computer.

Table 158 Slot Functions

Function Description

buildlist (<args>, ...) <args> is a list of arguments represented by constants or variable names. buildlist returns a list of values that can be assigned to a LIST_OF slot. See the BMC Impact Manager Knowledge Base Reference Guide for details about LIST_OF slots. If the left side of the buildlist assignment is not a LIST_OF slot, the cell will reject the event.

gethostbyaddr (<arg>) <arg> is either a string or a variable name containing the internet address of a computer, such as 123.456.789.012. gethostbyaddr returns the full name of the computer, or zero (0) if not found.

gethostbyname(<arg>) <arg> is either a string or a variable name containing the name of a computer. gethostbyname returns the internet address of the computer in the form a string, such as 123.456.789.012, or zero (0) if not found.

lower (<arg>) <arg> is either a string or a variable name containing a string. The function returns <arg> converted to lowercase.

substr (<arg>, <start_pos>, <length>) <arg> is either a string or a variable name containing a string. <start_pos> and <length> are either integers or variables containing integers. substr acts as the Perl substr function. See Perl documentation for details.


Sections

The most general method of assignment is represented by the following assignment form: slot_name can be assigned to the return value of built-in Perl functions, or any user defined Perl function, that is defined in an external file and loaded with the REQUIRE directive.

slot_name = <perl_func>( <args>, ...)

<perl_func> can be either a built-in Perl function, such as length or time, or a function defined in files loaded with the REQUIRE directive. The arguments <argS> of <perl_func> can be any of the following:

■ constants such as “a string”, 1234■ input variables such as $avariable, $anothervar[1]■ variables known in the global context such as @INC, $ENV{’PATH’}■ simple expressions involving function calls such as length($avariable)

Constants and input variables are used as in other assignments. In addition, <perl_func> can accept other arguments that are valid Perl expressions in the global context. Local variables of the MAP module MA::Map and other modules are not known, except for variables with a global scope not declared with a “my’ statement, when their name is preceded by the module name and ::). These expressions cannot contain comma characters (,), except in strings that have single or double quotes. For example, an argument such as badarg($farg1, $farg2) is not valid, while goodarg(“string, string”) is a valid argument.

Conditions

A condition is a Boolean expression associated with a CLASS statement that must be satisfied so the current event matches the class. A condition has the format:

<var> <operator> <comp_value>

<var> is either an input variable or a substring of an input variable set in a previous condition, such as:

printf (<format>, <args>, ...). <format> is either a string or a variable name containing a string. <args> is a list of arguments, possibly empty, represented by constants or variables, similar to other assignments, whose values must correspond to the <format> argument. printf behaves like the printf Perl function and therefore like the C printf function. See C and Perl documentation about printf for details.

upper (<arg>) <arg> is either a string or a variable name containing a string. The function returns <arg> converted to uppercase.

Table 158 Slot Functions

Function Description


Sections

$avariable$anothervar[1]

<operator> is one of the operators listed in Table 159.

When the operator is smaller, greater, smaller_or_equals or greater_or_equals, <var> must contain a number.

<comp_value> represents:

■ number, such as 12, –2, 0xFF, .314E+2.

■ string, such as “A string” (<operator> must be equals or not_equals).

■ regular expression, such as /.*matchthis.*/ (<operator> must be equals or not_equals).

■ DEFINE representing one of the above three values, such as #mydefine.

Pattern matching

<comp_value> regular expressions are evaluated with the Perl rules for pattern matching. See your Perl documentation about pattern matching for details. The regular expression can contain parentheses that match substrings of <var>. These substrings can be accessed by using the [] operator on <var>. Technically, if <var> represents $var, the Perl variables $1, $2, ..., $9 are stored in $var[1], $var[2], ..., $var[9]. For example:

Table 159 Operators

Operator Description

equals When <var> and <comp_value> contain numbers, the condition is satisfied if <var> and <comp_value> are equal. When <var> and <comp_value> contain strings, the condition is satisfied if <var> and <comp_value> contain the same string. Remember that these are case sensitive. When <var> contain a string and <comp_value> is a Perl regular expression, the condition is satisfied when <var> matches with the Perl regular expression.

not_equals not_equals can be used in the same conditions as equals and returns the negation of the expression where not_equals is replaced by equals.

smaller When <var> and <comp_value> are numbers, the condition is satisfied if <var> is strictly smaller than <comp_value> (<var> < <comp_value>).

greater When <var> and <comp_value> are numbers, the condition is satisfied if <var> is strictly larger than <comp_value> (<var> > <comp_value>).

smaller_or_equals When <var> and <comp_value> are numbers, the condition is satisfied if <var> is smaller or equal to <comp_value> (<var> _ <comp_value>).

greater_or_equals When <var> and <comp_value> are numbers, the condition is satisfied if <var> is larger or equal to <comp_value> (<var> _ <comp_value>).


Sections

Suppose that $match contains “first second third etc....” The first condition is satisfied since $match contains at least two words. After the first condition, $match[1] contains “first” and $match[2] contains “second”. The second condition is satisfied and slot is set to “second.”

A more complex example is:

The second condition also involves pattern matching. The second condition is satisfied; $match[1] contains “ir” and $match[2] contains “st”. slot is set to “st”. Such substrings can be used in nested CLASS structures. The second example shows how a substring, itself, can be used as an expression for pattern matching. In this case, the new partial strings extracted from the subexpression are accessed by using the operator [] from the base string. To clarify, examine the condition: $match[1] equals /f(..)(.*)/. After a successful matching, the expressions corresponding to the two expressions (..) and (.*) will be stored in $match[1] and $match[2], which overrides the previous values of $match[1] and $match[2]. Expressions such as $match[1][1] and $match[1][2] are not allowed. This may seem counterintuitive, but it is very much in accordance with the Perl approach to pattern matching, where special variables $1, $2, ..., take new values at each match.

Regular expressions

■ cannot contain references to the variables declared in the INPUT_VARIABLES section

■ support the following modifiers: g i m o s x

Consult the Perl documentation for details about such modifiers. For example.

$match equals /AnY_cAsE/i

matches the string “any_case” in lower and upper case.

INIT section

The INIT section contains assignments of BMC Impact Manager slots that are common to all events. Figure 205 illustrates the structure of the INIT section.

$match equals /\s*(\w+)\s+(\w+)\s+.*/$match[1] equals “first”slot = $match[2]

$match equals /\s*(\w+)\s+(\w+)\s+.*/$match[1] equals /f(..)(.*)/slot = $match[2]


Sections

<assignment> is an assignment. When an external event is mapped into a BMC Impact Manager event, the assignments of the INIT section are evaluated for each event. A CLASS or DEFAULT assignment overrides a slot value previously set in the INIT section.

DEFAULT section

Figure 205 illustrates the structure of the DEFAULT section.

<class_name> is the name of the default class, such as EVENT, DEF_ADAPTER_EV. Be certain that the class name is recognized by the cell to which it is sent. If an event does not match any CLASS requirements, an event of class <class_name> can be generated. The slots of the event are set by evaluation of the assignments of the INIT and DEFAULT sections. DEFAULT assignments override INIT assignments of the same slot. The DEFAULT section can contain no assignments. The DEFAULT section is optional. At most, one DEFAULT section is authorized.

By default, the DEFAULT mechanism is disabled. That is, if an event does not match any class, it is dropped before being sent to the cell. To enable the DEFAULT class mechanism, either:

■ Use the -e command-line option without argument, or

■ Use the MapUseDefaultClass (MapUseDefaultClass=1) parameter in the configuration file (etc/*.conf).

CLASS section

The CLASS structures contain the main information about how to map Adapter events into BMC Impact Manager events. CLASS structures can be nested. Figure 207illustrates the CLASS leaf section.

Figure 205 INIT structure

INIT <assignment> <assignment> ...END

Figure 206 DEFAULT structure

DEFAULT <class_name> <assignment> <assignment> ...END


Sections

General structure

Figure 208 illustrates the general structure for nested class mapping.

<class_name>, <sub_class_name>, and <subsub_class_name> are names of the BAROC classes. An event matches a CLASS <class_name> when all conditions (<condition>) associated with that class and parent classes are satisfied. If all conditions (<condition>) are satisfied, assignments (<assignment>) associated with that CLASS and possible parent classes (CLASS) are evaluated in order to build a BAROC event. This BAROC event is then sent to a cell. Classes are evaluated sequentially. As soon as an incoming event satisfies all conditions of a CLASS and does not match any subclass of that CLASS, an event of the corresponding BAROC class is created, then sent.

Figure 207 CLASS leaf structure

CLASS <class_name><condition><condition>...<assignment><assignment>...END

Figure 208 Nested class mapping Structure

CLASS <class_name><condition><condition>...<assignment><assignment>...CLASS <sub_class_name>

<condition>...<assignment>...CLASS <subsub_class_name>...END

ENDCLASS <sub_class_name>...END

END


Sections

Even if it is often the case, the CLASS structure of the MAP file is not required to reflect the BAROC classes as defined in a .baroc file. The nature of the hierarchical classes in the MAP file is purely syntactic. The BAROC class corresponding to a subclass need not be a subclass, in the BAROC sense, of the BAROC class corresponding to the parent CLASS in the MAP file sense. In addition, a MAP file can contain several classes having the same <class_name>.

Class name

Moreover, a MAP file can contain CLASS <class_name> statements of nonexistent corresponding BAROC class names (<class_name>). In this case, either the MAP writer has verified that no event will match that CLASS without matching any subclass or events of CLASS <class_name> will be dropped by the cell, as in Figure 208.

The above CLASS structure defines several possible matches for CLASS A or CLASS B. Even if CLASS B is nested in CLASS A in the first CLASS A structure, CLASS B is not necessarily a BAROC subclass of CLASS A. Note that the BAROC CLASS B must have a defined slot, slot1. CLASS dummy need not be a defined BAROC class since the condition under the nested CLASS B, $var2 equals /.*/, is always satisfied, which means that it is impossible to generate a dummy event from that MAP file sample.

Figure 209 Class name example

CLASS A$var1 equals /string3/slot1 = “abc”CLASS B

$var2 equals /string2/slot2 = “def”

ENDENDCLASS B

$var2 equals /string3/slot1 = “ghi”

ENDCLASS dummy

$var1 equals /string3/CLASS A

$var1 equals /string4/slot1 = “jkl”

CLASS B$var2 equals /.*/slot1 = “mno”

ENDEND


Directives

Directives

A MAP file can also contain a DEFINE or a REQUIRE directive.

DEFINE directive

A DEFINE directive is a line beginning with the DEFINE keyword, as the following illustrates.

DEFINE the_define “define value” <new line>

When such a statement is made, each subsequent statement in which a value is represented by #the_define (the first ’#’ character is required), is replaced by “define value,” excluding the space characters before the end of line.

A comment line is a line in which the first non-space character is a #, a !, or a % character. Comment lines and empty lines are ignored.

REQUIRE directive

Instead of using the MapFunctionsName parameter, user-defined Perl files can be included in the .map file by using the REQUIRE directive, as follows:

REQUIRE <perl_module>

In general, <perl_module> is a Perl module or script containing functions accessible from within the .map file. The location must be either the Perl standard library directory or in the MCELL_HOME\lib\perl directory. Subdirectories are allowed with the standard Perl “::“ notation. For example, Figure 210 is an extract from the mcsyslogd.map file.

DateSyslog2Epoch is defined in MCELL_HOME\lib\perl\MA\MapUtil.pm.

Multiple REQUIRE statements are allowed within the same .map file.

Figure 210 mcsyslogd.map file excerpt

REQUIRE MA::MapUtil# ... lines are missingCLASS SYSLOG_BASE $complete equals

logfile = $LOGFILEsource = "Syslog"mc_incident_time = DateSyslog2Epoch ($complete[1])


Directives

Following the object-oriented Perl methods, the first argument of each user-defined call is a reference to the MA::Map object. The INPUT_VARIABLES of the MAP file can be found in the {specific_event} key of the MA::Map object, as Figure 211 illustrates.

In Figure 211, above, DateSyslog2Epoch has been called with the single argument $complete[1]. The Adapter automatically adds the MA::Map object to the beginning of function arguments, so that the first shift inside the implementation of DateSyslog2Epoch returns the MAP object, while the second shift returns the string corresponding to $complete[1]. See the MCELL_HOME\lib\perl\MA\Map.pm file for more details.

Figure 211 Map call

sub DateSyslog2Epoch{

my MA::Map $map = shift;my $str = shift;

# See MapUtil.pm for the rest of source.## INPUT_VARIABLES could accessed as (for instance):# my $ivars = $map–>{specific_event};# foreach my $iv (keys %$ivars)# {# # Do something with $iv and $ivars > {$iv}

NOTE The function that $complete performs in the LogFile, Perl EventLog for Windows, and SNMP Adapter mappings is performed by $data for the IP Adapters (see references to the $data variable on pages 115, 117 and 121). $data is provided automatically. You do not have to get it. However, you cannot rename it.


Directives


A p p e n d i x G
G IP Adapters

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489IP Adapter architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490IP Adapters configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490IP Adapter types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491

TCP Client Adapter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491TCP Server Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494Telnet Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496UDP client Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500UDP server Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503

OverviewThe IP Adapters use the various protocols of the IP protocol suite to establish connections with programs from which you want to generate events.

With the IP Adapters, you are able to specify the connection method to the data source and the type of parsing that you want performed on the collected data.

Data that is collected using an IP connection is parsed into a Perl hash (name-value pair data tokens) by a parser that you specify. The parsed data is passed to a mapping function, which converts the data tokens into events. The events are sent to msend, which passes them to the cell.

For information about how and when an Adapter collects data, see “IP Adapter architecture” on page 490.

The IP Adapters are bundled with three pluggable parsers. You specify which parser you want to use as a parameter in the Adapter configuration. For more information about parsers, see the BMC Impact Solutions: General Administration guide.


IP Adapter architecture

IP Adapter architectureThe Adapter architecture is a loop that is a central waiting state for a program.

When an Adapter is started, it registers to the loop. The loop checks to see if any file descriptors are active. When a descriptor becomes active, the Adapter receives the new data.

IP Adapters configurationThe Adapter configuration is contained in a list of parameters that are recorded in the Adapter definition in the mcxa.conf file. You configure an Adapter by specifying values for that Adapter’s parameters. For information about configuring an Adapter definition, see the BMC Impact Solutions: General Administration Guide.

Each Adapter has unique parameters that apply only to that instance of the parameter. These parameters are listed under the description for each parameter type in “IP Adapter types” on page 491.

In addition, global and common parameters also determine the configuration of an Adapter parameter instance (where instance-specific parameters do not override them).

The global parameters that affect IP Adapters are:

■ EngineMgrName■ PollInterval■ TraceFile■ TraceLevel■ TraceSizeCount■ TraceSizeMax■ TraceSizePeriod

The common parameters that affect IP Adapters are:

■ MapFile■ MapFunctionsName■ MapUseDefaultClass■ ServerName

For more information about global and common parameters, see the BMC Impact Solutions: General Administration guide.


IP Adapter types

IP Adapter typesThe BMC Impact Event Adapters include a number of different IP Adapters. With the variety of different Adapters that are available, you can select the means for collecting event data that is most appropriate to your requirements.

The IP Adapters are:

■ “TCP Client Adapter” on page 491■ “TCP Server Adapter” on page 494■ “Telnet Adapter” on page 496■ “UDP client Adapter” on page 500■ “UDP server Adapter” on page 503

The parameter descriptions include tables that describe the specific parameters of each Adapter type. Specific parameters determine how a single instance of an Adapter behaves. However, Adapter behavior is also determined by global and common parameters. The settings of global and common parameters affect multiple instances of various types of Adapters. For more information, see the BMC Impact Solutions: General Administration guide.

TCP Client Adapter

The TCP Client Adapter connects to a TCP Server to receive a data stream. The Adapter passes the data stream to a parser. The parser parses the data stream into data tokens, which the mapping function converts into events.

Table 160 on page 491 describes the TCP Client Adapter parameters.

Table 160 TCP Client Adapter configuration parameters (part 1 of 3)


instancename name of the Adapter instance

The instance name is the first entry in the Adapter configuration and must be enclosed in square brackets.

Required.

Note: To run more than one instance of the Adapter, specify a unique name and configuration for each Adapter instance.

ConnectTimeout maximum time, in seconds, to wait until a connection attempt is considered unsuccessful

Default: 10


TCP Client Adapter

Engine type of Adapter in use

Required.

Valid value: MA::Adapter::TcpClient

LocalHost local IP address on a computer with multiple network interfaces to which the TCP Client Adapter binds

Specify a value for this parameter only when the Adapter is on a computer that has multiple network interfaces. By default, the Adapter will bind to the default interface.

Valid values: host name or IP address

Note: Do not specify localhost, 127.0.0.1, or INADDR_ANY as a value for this parameter.

LocalPort local port number to which the TCP Client Adapter binds

Default: ANY

Mapfile name of the MAP file used to generate events from the tokenized data

Required.

Parser parser instance to use to parse and tokenize the client input stream

Required.

You must code the name of another section in the mcxa.conf file that defines a parser with a unique name. It is not valid to code the name of a parser type as would be used in the Engine parameter.

Example:

Parser = ParseSyslog

where ParseSyslog is the unique name for a parser definition, such as:

[ParseSyslog] Engine = MA::Parser::FixedWidth

In the Adapter definition, do not code: Parser = MA::Parser::FixedWidth

RemoteHost hostname or IP address of the remote computer to which the TCP Client Adapter is connecting

Required.




TCP Client Adapter

Figure 212 shows a sample TCP Client Adapter configuration, as it would appear in the mcxa.conf file.

Diagnostics

All Adapter errors are logged as events. Optionally, you can enable tracing by setting the tracing parameters in the global section of the mcxa.conf file. For more information, see the BMC Impact Solutions: General Administration guide.

The TCP Client Adapter can generate an ERR_RECV error, which indicates that a problem occurred when receiving data from the server. For more information, see the event that is created for this error.

RemotePort port on the remote computer to which the TCP Client Adapter is connecting

Required.

RestartInterval interval, in seconds, at which:

■ the TCP Client Adapter re-attempts to bind to the local port if that port is busy when the Adapter makes its first bind attempt

■ the TCP Client Adapter sends a packet if the connection that the Adapter uses is functioning

Note: If the current connection fails or the remote server stops responding, this parameter value is also used to schedule additional connection attempts by the Adapter.

Default: 60

Figure 212 Sample TCP Client Adapter configuration

[TcpClient] DISABLEEngine = MA::Adapter::TCPClientParser = SeparatorParserMapFile = mctcpclt.mapRemoteHost = localhostRemotePort = 13 # date/time service




TCP Server Adapter

TCP Server Adapter

The TCP Server Adapter receives connections from one or more TCP clients. These clients send data streams to the Adapter. The Adapter passes the data stream to a parser. The parser parses the data stream into data tokens, which the mapping function converts into events.

Table 161 on page 494 describes the TCP Client Adapter parameters.

NOTE You cannot use Telnet as a means for communicating with the TCP Server Adapter. The TCP Server Adapter does not recognize incoming Telnet commands as meaningful binary control codes. Instead, the Adapter interprets Telnet information as raw data.

Table 161 TCP server Adapter configuration parameters (part 1 of 2)




Required.



Required.

Valid value: MA::Adapter::TcpServer

LocalHost local IP address on a computer with multiple network interfaces to which the TCP Server Adapter binds




LocalPort local port number on which the TCP Server Adapter listens for connections

Default: 1999


Required.


TCP Server Adapter

Figure 213 shows a sample TCP Server Adapter configuration, as it would appear in the mcxa.conf file.

Diagnostics


MaxClients maximum number of clients allowed to connect simultaneously to the TCP Server Adapter

Default: 10

Parser parser instance that should be used to parse and tokenize the client input stream

You must code the name of another section in the mcxa.conf file that defines a parser with a unique name. It is not valid to code the name of a parser type as would be used in the Engine parameter.

Example:




In the Adapter definition, do not code:

Parser = MA::Parser::FixedWidth

RestartInterval interval, in seconds, at which the TCP Server Adapter re-attempts to bind to the local port if that port is busy when the Adapter makes its first bind attempt

Default: 30

Figure 213 Sample TCP server adapter Configuration

[MyTcpServer]Engine = MA::Adapter::TcpServerMaxClients = 10RestartInterval = 30MapFile = mctcpsrv.mapLocalHost = 127.0.0.5LocalPort = 1999Parser = MyFixedWidthParser

Table 161 TCP server Adapter configuration parameters (part 2 of 2)



Telnet Adapter

The TCP Server Adapter can generate an ERR_RECV error, which indicates that a problem occurred when receiving data from the server. For more information, see the event that is created for this error.

Telnet Adapter

The Telnet Adapter is a Telnet client that can connect to a Telnet Server to receive a data stream. The Adapter passes the data stream to a parser. The parser parses the data stream into data tokens, which the mapping function converts into events.

Use the Telnet Adapter in the following situations:

■ interactivity is required (the Adapter logs on, submits a command, and receives output)

■ the process that is being monitored by the Adapter is not meant to stop (such as log file monitoring)

The Telnet Adapter operates on the following principles:

■ The Telnet Adapter uses the “interpret as command” functions DO, DONT, WILL, and WONT.

■ The Telnet Adapter uses “suppress go ahead” (SGA) to decrease negotiation time.

■ To eliminate looping problems with SGA, each command is accepted or rejected only once and the reply is consistent every time.

■ The current Telnet Adapter supports a minimal set of Telnet Negotiation commands. Almost every proposal (DO) that the Telnet Adapter receives from its peer is replied to with a negation (WONT).

Table 162 on page 497 describes the Telnet Adapter parameters.


Telnet Adapter

Table 162 Telnet adapter configuration parameters (part 1 of 3)




Required.


ConnectTimeout maximum time, in seconds, to wait until a connection attempt is considered unsuccessful

Default: 10


Required.

Valid value: MA::Adapter::Telnet

IdleTimeout maximum time, in seconds, after which new data is expected to have arrived. After this time, the connection is considered unsuccessful.

Default: 15 seconds

LocalHost local IP address on a computer with multiple network interfaces to which the Telnet Adapter binds




LocalPort local port number to which the Telnet Client binds

Default: ANY

LoginPrompt regular expression of the login prompt

Required.

Default: "login[: ]*$|username[: ]*$"


Required.


Telnet Adapter


Required.

Example:






PasswordPrompt regular expression that provides valid alternative password prompt text

Required.

Default: "password[: ]*$"

Prompt list of alternate prompt characters

Required.

Default: "[\$>#%]"

script Telnet login script

Required.

Default: telnet.conf

RemoteHost hostname or IP address of the remote computer to which the Telnet Adapter is connecting

Required.

RemotePort port on the remote computer to which the Telnet Adapter is connecting

Required.

RestartInterval interval at which the Telnet Adapter re-attempts to bind to the local port if that port is busy when the Adapter makes its first bind attempt

This interval also can be used for any other rescheduling that happens within the Adapter (such as rescheduling timeout or termination).

Default: 60




Telnet Adapter

Figure 214 shows a sample Telnet Adapter configuration, as it would appear in the mcxa.conf file.

Diagnostics

All Telnet Adapter errors are logged as events. Optionally, you can enable tracing by setting the tracing parameters in the global section of the mcxa.conf file.

RestartWhenDone reestablishes a connection when it fails or is broken due to a hang-up

Valid values:

■ 0 – no reconnect■ 1 – reconnect

Default: 0

TelnetAuthTimeout maximum time, in seconds, to wait for the completion of the authentication phase

Required.

TelnetCommand command to execute after logging onto the remote computer

Required.

TelnetPassword password used to connect to the remote computer

Required.

TelnetUsername user name used to connect to the remote computer

Required.

Figure 214 Sample Telnet Adapter configuration

[MyTelnet] #name of Adapter instanceEngine = MA::Adapter::TelnetParser = SeparatorParser# Use the parser you want for the outputMapFile = mctelnet.mapRestartInterval = 60 # Interval used when an error occurs# Or when Adapter restarts IdleTimeout = 15 # Close the connection when no data has# been received for 10 seconds (implicit restart)ConnectTimeout = 10 # Restart if the connection takes longer# Than 10 seconds to completeRemoteHost = localhost # Which host to connect toRemotePort = 23 # Which port (23 = telnetd port)TelnetAuthTimeout = 15TelnetUsername = myusername # Username for loginTelnetPassword = mypasswd # Password for loginTelnetCommand = "ls -l" # Command to execute after login




UDP client Adapter

The Telnet Adapter can generate an ERR_RECV error, which indicates that a problem occurred when receiving data from the server. For more information, see the event that is created for this error.

UDP client Adapter

The UDP Client Adapter connects to a UDP Server to receive a data stream. The Adapter passes the data stream to a parser. The parser parses the data stream into data tokens, which the mapping function converts into events.

Table 163 describes the UDP Client Adapter parameters.

NOTE If you suspect problems with the Telnet Negotiation commands, monitor the Telnet option negotiation process by enabling Trace level 6. For details about tracing, see the BMC Impact Solutions: Event Monitoring Operator’s Guide.

Table 163 UDP client Adapter configuration parameters (part 1 of 3)




Required.

■ Note: To run more than one instance of the Adapter, specify a unique name and configuration for each Adapter instance.

ConnectTimeout maximum time a connection will stay active

After the period of time specified in ConnectTimeout has expired, the Adapter closes the connection. No more data will be received from that connection.

If no ConnectTimeout value is specified or if the value specified is 0, the timer is disabled. This is the default behavior.

Engine type of Adapter in use.

Required.

Valid value: MA::Adapter::UdpClient


UDP client Adapter


Default: 15

The UDP Client Adapter sends a packet at a regular interval, specified by the sum of the periods specified by the IdleTimeout and RestartInterval parameters.

LocalHost local IP address on a computer with multiple network interfaces to which the UDP Client Adapter binds




LocalPort local port number to which the UDP Client Adapter binds

Default: ANY


Required.


Required.

Example:






RemoteHost hostname or IP address of the remote computer to which the UDP Client Adapter is connecting

RemotePort port on the remote computer to which the UDP Client Adapter is connecting




UDP client Adapter

Figure 215 shows a sample UDP Client Adapter configuration, as it would appear in the mcxa.conf file.

Diagnostics


The UDP Client Adapter can generate an ERR_UDP_INIT error, which indicates that a problem occurred when receiving data from the server. For more information, see the event that is created for this error.

RestartInterval interval, in seconds, at which

■ the UDP Client Adapter re-attempts to bind to the local port if that port is busy when the Adapter makes its first bind attempt

■ the UDP Client Adapter sends a packet at the rate prescribed by this parameter plus the interval prescribed in the IdleTimeout parameter, if the connection that the Adapter uses is functioning

Default: 60

The RestartInterval parameter value is also used to schedule additional connection attempts by the Adapter when any of the following occur:

■ the current connection fails■ the remote server hangs■ the amount of time specified in the IdleTimeout parameter expires

SendOnConnect string that is sent after a connection is established

Figure 215 Sample UDP client Adapter configuration

[MyUDPClient]Engine = MA::Adapter::UdpClientMapFile = mcudpclt.mapRemoteHost = test.bmc.comRemotePort = 13Parser = SeparatorParser




UDP server Adapter

UDP server Adapter

The UDP Server Adapter receives connections from one or more UDP clients. The Adapter passes the data stream to a parser. The parser parses the data stream into data tokens, which the mapping function converts into events.

Table 164 describes the UDP Server Adapter parameters.

Table 164 UDP Server Adapter configuration parameters (part 1 of 2)




Required.


Engine type of Adapter in use.

Required.

Valid value: MA::Adapter::UdpServer


Default: 15

LocalHost local IP address on a computer with multiple network interfaces to which the UDP Client Adapter binds




LocalPort local port number on which the UDP Server Adapter listens for connections

Default: 2000


Required.


UDP server Adapter

Figure 216 shows a sample UDP Server Adapter configuration, as it would appear in the mcxa.conf file.

Diagnostics


The UDP Server Adapter can generate the following errors:

■ ERR_RECV—indicates that a problem occurred when receiving data from the server

■ ERR_UDP_INIT—indicates that a problem occurred when starting the UDP connection

For more information, see the event that is created for this error.


Required.

Example:






RestartInterval interval, in seconds, at which the UDP Server Adapter re-attempts to bind to the local port if that port is busy when the Adapter makes its first bind attempt

Default: 60

Figure 216 Sample UDP Server Adapter configuration

[MyUDPServer]Engine = MA::Adapter::UdpServerMapFile = mcudpsrv.mapLocalPort = 1997 Parser = SeparatorParser

Table 164 UDP Server Adapter configuration parameters (part 2 of 2)



A p p e n d i x H
H BMC Impact Event Adapters parsers

What a parser does. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505LogFile, Perl EventLog for Windows, and SNMP Adapter parsers. . . . . . . . . . . . . . 505IP Adapter parsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507

Specifying a CSV parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507Specifying a Fixed-width (column) parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509Specifying Record and Field separated parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514

What a parser doesA parser formats the data that is collected by one of the BMC Impact Event Adapters, converts it into tokens (fields), and passes these tokens to the mapping process.

The SNMP Adapter, the BMC LogFile Adapter, and the Perl Windows EventLog Adapter each use a dedicated parser engine. This engine cannot be replaced or modified. You do not need to specify the parser in the Adapter definition.

The BMC Impact Event IP Adapters can use any of three pluggable parsers, which each parse the data in a different format. For each IP Adapter, you must specify a parser in the Adapter definition in the mcxa.conf file. The IP Adapter requests the parser as an object.

LogFile, Perl EventLog for Windows, and SNMP Adapter parsers

The LogFile Adapter, Perl EventLog for Windows Adapter, and SNMP Adapters include dedicated internal parsing functions.


LogFile, Perl EventLog for Windows, and SNMP Adapter parsers

Events in a log file are determined either by a record separator or by a Perl regular expression.

The most common event separator is the newline (\n). The parameter LogRecordSeparator contains the record separator of the events. LogRecordSeparator recognizes Perl escape characters, such as \n, and generally can contain several characters or even a regular expression. For example, setting LogRecordSeparator="\n\n" results in events being delimited by two consecutive new line characters that results in a single empty line. By default, setting LogRecordSeparator = "\n" creates events that are line-based. In other cases, the parsing will be multi-lined.

The input variable $complete is set to the string between the two consecutive LogRecordSeparator entries.

According to the value of the parameter LogRegExpr, the following instances are considered:

■ LogRegExpr is empty. $complete is split into substrings, delimited by the LogFieldSeparator variable. These substrings are stored in $varlog<N> variables (N>=0). For example, if

$complete contains "a;b;c;d", and$LogFieldSeparator contains ";"

then

$varlog0="a"$varlog1="b"...

■ LogRegExpr is not empty. The regular expression LogRegExpr is applied to $complete. Subpatterns of $complete are stored in $varlog<N> variables (N>=1). For example,

$complete contains "12345 abcde", and$logRegExpr contains "(\d+)\s*(\w+)"

then

$varlog1=12345$varlog2="abcde"

■ LogRecordSeparator is empty and LogRegExpr is not empty. In this case, the regular expression contained in LogRegExpr will be applied to the log file from the point at which the previous successful matching stopped. The input variable $complete will be set to the whole matching of the regular expression. LogVarPrefix contains the names of variables containing subpatterns. By default,

LogVarPrefix="varlog"


IP Adapter parsers

If both variables are empty, the behavior of the Adapter is not determined.

IP Adapter parsersUnlike the Logfile Adapter, the SNMP Adapter, and the Perl EventLog for Windows Adapter, which have their own dedicated parsers, the IP Adapters can use any one of the following parsers that are included with the BMC Impact Event Adapters.

■ “Specifying a CSV parser”■ “Specifying a Fixed-width (column) parser” on page 509■ “Specifying Record and Field separated parser” on page 514

Specifying a CSV parser

The CSV parser, MA::Parser::CSV, is a pluggable parser that parses a datastream into records (newline), in which each record is a comma-separated value list. The parser returns each value as a token to the mapper.

To specify the CSV parser

1 Using a text editor, open the mcxa.conf file.

2 In the section of the file that describes the Adapter that you want to use with the CSV parser, add the following line:

Parser = parsername

3 In the parser section of the mcxa.conf file, define parser parsername.

Table 165 on page 508 describes the parameters that you can modify in the parser definition.


Specifying a CSV parser

Table 165 CSV parser parameters (part 1 of 2)


FieldSeparator a set of characters that will be used as a delimiter

Optional.

Default: comma (,)

KeepEmptyRecords indicates whether empty records are formatted as tokens and passed to the mapping function

Required.

Valid values:

■ 1 – tokenize empty records ■ 0 – discard empty records (Default)

RecordNegFilter a regular expression that acts as a criterion to which each parsed record is compared

If the criterion is included in the record, the record is discarded.

Optional.

RecordPosFilter a regular expression that acts as a criterion to which each parsed record is compared

If the string is included in the record, the record is formatted as a token and passed to the mapping function.

Optional.


Specifying a Fixed-width (column) parser

Figure 217 on page 509 shows a sample parser definition for a parser named MyParser.

4 Save and close the mcxa.conf file.


The fixed-width parser, MA::Parser::FixedWidth, is a pluggable parser that parses a datastream into records. From each record, a field is extracted based on a fixed-width format.

RecordSeparator regular expression used to break a datastream into separate records

The resulting record is returned in the $data variable, which can then be used in the MAP file to refer to the entire record as one field. The $data variable is provided automatically. You cannot rename it.

Optional.

Default: \r?\n

Note: The input variable $data is set to the string between two consecutive RecordSeparator entries. It performs the function that $complete performs in the LogFile, Perl EventLog for Windows, and SNMP Adapter mappings.

VarPrefix variable prefix used by the mapper

Each token will be returned as prefix0 ... prefixn.

Optional.

Default: varlog

Default variables sent to the mapper are named varlog0, varlog1, ...

Figure 217 Sample CSV parser specification example

[MyParser]Engine = MA::Parser::CSVFieldSeparator = "," # DefaultKeepEmptyRecords= 0 # Discard Empty RecordsRecordNegFilter = "(test|dummy) event" RecordPosFilter = "(ERROR|WARNING)" VarPrefix = "token" # Return token0 ... tokenn

Table 165 CSV parser parameters (part 2 of 2)




To specify the fixed-width parser


2 In the section of the file that describes the Adapter that you want to use with the fixed-width parser, add the following line:

Parser = parsername

3 In the parser section of the mcxa.conf file, define parser parsername.

Table 166 on page 510 describes the parameters that you can modify in the parser definition.

Table 166 Fixed-Width parser parameters (part 1 of 2)


FieldDefinitions a numerical pair that specifies which data are used in a field

The first number in the pair specifies from which character in the string to begin collecting data. The second number specifies how many consecutive characters are to be included in the field.

For more information, see “Defining Fields” on page 512.

Required.


Required.

Valid Values:




Optional.



Optional.





Optional.

Default: \r?\n


TrimLeadingWS removes leading white space, if any, from fields

Required.

Valid Values:

■ 1 – removes white space (Default)■ 0 – does not remove white space

TrimTrailingWS removes trailing white space, if any, from fields

Required.

Valid Values:

■ 1 – removes white space (Default)■ 0 – does not remove white space

VarPrefix variable prefix used by the mapper

Each token will be returned as prefix0 ... prefixn.

Optional.

Default: varlog


Table 166 Fixed-Width parser parameters (part 2 of 2)




Figure 218 shows a sample parser definition for a parser named MyParser.


Defining Fields

The contents of each field are determined by a pair of numbers. Each record from which the field is extracted is a string of data. The first field number indicates the starting position in the record at which the string field begins. The second number indicates the length of the string.

Defining a Single Field

The first character of the record is zero (0). A starting number of 5 indicates that the string begins with the sixth character in the record string.

Either number in the field specification can include a negative number. The field length position can include an asterisk wildcard (*).

■ When the starting point (the first number) is negative, the starting position is determined from the end of the record.

Figure 218 Fixed-width parser specification example

[MyParser]Engine = MA::Parser::FixedWidthRecordSeparator = "\r?\n"FieldDefinitions = "0:10,5:10,15:20"KeepEmptyRecords = 0TrimLeadingWS = 1TrimTrailingWS = 1VarPrefix = "token" # Return token0 ... tokenn

EXAMPLE In this example, the string is:

ABCDEFGHIJKLMNOPQRSTUVWXYZ

If the field specification is <0,3>, then the string that composes the field is ABC. The A is at position 0, and then starting from position 0, three characters are selected to comprise the field.

If the field specification is <11,2>, then the string that composes the field is LM (remember that the first character in the record is at position 0, not 1). The L is at position 11, and then starting from position 11, two characters are selected to comprise the field.



■ When the field length (the second number) is negative, the ending point of the string is calculated by counting back that number of characters from the end of the string and including everything in between the start point and up to that end point.

■ Both the starting point and the length can be negative values.

■ When the length is an asterisk (*), all characters from the starting point to the end of the record string comprise the field string. Use the asterisk when you do not know the record field length but want to select all of it from the starting point that you specify.



If the field specification is <-8,3>, then the string that composes the field is STU. The S is at position -8, and then starting from position -8, three characters are selected to comprise the field.

Alternately, you can express the same string in positive numbers: <18,3>.



If the field specification is <8,-3>, then the string that comprises the field is IJKLMNOPQRSTUVW. The string starts at I (position 8) and includes all but the last three characters in the record string.



If the field specification is <-20,-4>, then the string that comprises the field is GHIJKLMNOPQRSTUV. The string starts at G (position -20) and includes all but the last four characters in the record string.


Specifying Record and Field separated parser

Defining Multiple Fields

Each record can contain multiple fields. A prototype for their order is

<START1>:<LENGTH1>[, <START2>:<LENGTH2>[, <STARTn>:<LENGTHn>[...]]]


The Record and Field Separated parser, MA::Parser::Separator, is a pluggable parser that parses a datastream into user-definable records. Each record is then converted into a token using a user-defineable field separator.

To Specify the Record and field separated parser


2 In the section of the file that describes the Adapter that you want to use with the record and field separated parser, add the following line:

Parser = parsername

3 In the parser section of the file, define parser parsername.

The parameters of the parser definition that you can modify are described in Table 167 on page 515.


ABCDEFGHIJKLMNOPQRSTUVWXYZABC

If the field specification is <15,*>, then the string that comprises the field is PQRSTUVWXYZABC. The string starts at P (position 15) and includes all remaining characters in the record string.



Table 167 Record and field separated parser parameters (part 1 of 2)


FieldSeparator regular expression used to break a record into multiple fields

Required.

Default: \s+ (separates on any instance of white space)


Required.

Valid Values:




Optional.



Optional.



Optional.

Default: \r?\n




Figure 219 shows a sample parser definition for a parser named MyParser.


TrimLeadingWS trims the leading white space from the record before applying the RecordSeparator, which is done using the split function

In this parser, TrimLeadingWS does not trim the white space from each FIELD after the RecordSeparator has been applied.

VarPrefix variable prefix used by the mapper. Each token will be returned as prefix0 ... prefixn.

Optional.

Default: varlog


Figure 219 Record and Field Separated Parser Specification Example

[MyParser]Engine = MA::Parser::SeparatorRecordSeparator = "\r?\n"FieldSeparator = "\s+"KeepEmptyRecords = 0 # Discard Empty RecordsRecordNegFilter = "(test|dummy) event" RecordPosFilter = "(ERROR|WARNING)" VarPrefix = "token" # Return token0 ... tokenn

Table 167 Record and field separated parser parameters (part 2 of 2)



A p p e n d i x I
I Backend processes for publishing and unpublishing MIB files

The publish MIB files back-end process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517The unpublish MIB files back-end process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518

The publish MIB files back-end processThe Product Name automates the publish MIBs process. The steps involved in the publish MIB files back-end process have been reproduced here for your reference only.

1. The new MIB files are moved from your local computer to the Net-SNMP directory.

2. Before overwriting a MIB file that already exists in the Net-SNMP directory, a backup of that file is saved in the MCELL_HOME\tmp\adapters\snmpadapter\mibs directory.

3. The mib2map.pl utility, which is located in the MCELL_HOME\bin directory, is run. It generates the following four output files:

— mcsnmptrapdmib.baroc: This file contains the BAROC class definitions of the SNMP Traps found.

— mcsnmptrapdmibe.baroc: This file contains the BAROC enumerations of the MIB enumerated variables that are sent by traps.

— mcsnmptrapdmib.dat: This file contains information about object identifiers (OIDs), symbolic names, enumerations and indexes found in MIB traps.

— mcsnmptrapdmib.map: This file converts traps into BAROC.


The unpublish MIB files back-end process

4. The four output files are saved in the MCELL_HOME\bin directory.

5. A backup of the previous mcsnmptrapd.dat file is saved in the MCELL_HOME\tmp\adapters\snmpadapter\mib2mapOutput directory.

6. A backup of the previous mcsnmptrapd.map file is saved in the MCELL_HOME\tmp\adapters\snmpadapter\map directory. The file is renamed to mcsnmptrapdLastModified.map.

7. The mcsnmptrapdmib.dat and mcsnmptrapdmib.map files are renamed to mcsnmptrapd.dat and mcsnmptrapd.map respectively, and moved to the MCELL_HOME\etc directory.

8. The customizations in the previous mcsnmptrapd.map file are merged with the new mcsnmptrapd.map file.

All the invalid MIB files in the Net-SNMP directory are identified and displayed in the status area. Before you manually delete an invalid file existing in the Net-SNMP directory, ensure that the invalid file does not support any valid MIB files.

The unpublish MIB files back-end processThe Product Name automates the unpublish MIB files process. The steps involved in the unpublish MIB files back-end process have been reproduced here for your reference only.

NOTE ■ In the mcxa.conf file, if you have not specified the file names for the MapFile and

SnmpDatFile parameters, by default the Product Name uses the mcsnmptrapd.map and mcsnmptrapd.dat file names respectively. This document uses mcsnmptrapd.map and mcsnmptrapd.dat to refer to the files that are configured for the MapFile and SnmpDatFile parameters respectively in the mcxa.conf file.

■ In the mcxa.conf file, if you have not specified the file name for the MapFile parameter, the Product Name renames the mcsnmptrapd.map file to mcsnmptrapdLastModified.map. Otherwise, ‘mcsnmptrapd’ is replaced with the file name that you have specified for the MapFile parameter in the mcxa.conf file. For example, filenameLastModified.map.

NOTE The Publish MIBs process preserves the entries of classes in the mcsnmptrapd.map file even if the corresponding MIB files do not exist in the Net-SNMP directory.



1. A backup of the mcsnmptrapd.map and mcsnmptrapd.dat files is saved in the MCELL_HOME\backup\adapters\snmpAdapter\removeMib directory. These two files are located in the MCELL_HOME\etc directory.

2. The mcsnmptrapd.map template file is copied to the MCELL_HOME\etc directory.

3. A backup of the mcsnmptrapdmib.baroc and mcsnmptrapdmibe.baroc files is saved in the MCELL_HOME\backup\adapters\snmpAdapter\removeMib directory. These two files are located in the MCELL_HOME\bin directory.

4. The following tasks are repeated for each MIB file that has to be unpublished.

A. The modules within the MIB file that has to be unpublished are identified.

B. The mib2map.pl utility, which is located in the MCELL_HOME\bin directory, is run only for the MIB file that has to be unpublished. The four output files that are generated are mcsnmptrapdmib.baroc, mcsnmptrapdmibe.baroc, mcsnmptrapdmib.dat, and mcsnmptrapdmib.map. The four output files are saved in the MCELL_HOME\bin directory.

C. The classes created for the MIB file are extracted from the mcsnmptrapdmib.map file, which is located in the MCELL_HOME\bin directory. The same classes are then removed from the mcsnmptrapd.map file, which is located in the MCELL_HOME\etc directory.

D. The content of the mcsnmptrapd.dat file, which is located in the MCELL_HOME\bin directory, is referenced and then the same content is removed from the mcsnmptrapd.dat file, which is located in the MCELL_HOME\etc directory.

5. The backup of the mcsnmptrapdmib.baroc and mcsnmptrapdmibe.baroc files, which are located in the MCELL_HOME\backup\adapters\snmpAdapter\removeMib directory, is restored to the MCELL_HOME\bin directory.

6. The MIB files that are unpublished are also removed from the Net-SNMP directory.


A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Glossary

AAbstract phase

The event-processing phase in which Abstract rules are evaluated and, if conditions are met, abstraction events are generated. See also abstraction event.

Abstract ruleAn event-processing rule that creates an abstraction event from one or more raw events. See also abstraction event.

abstracted eventAn event that contributes to the creation of an abstraction event. The abstracted event is the basis for inferring that some condition exists. For example, if a critical subprocess of an application is down, the application is down. See also abstraction event.

abstraction eventA conceptual or summary event based on other events that are occurring. You cannot understand the context of an abstraction event by its details. To understand its context, you must view the relationships between the abstraction event and the events that triggered its creation in the BMC Impact Explorer Events tab, Relationships window. See also abstracted event.

AcknowledgeThe event operation action that acknowledges the existence of an event. See also local action.

Acknowledged statusThe event status that results from an Acknowledge event operation action; it means that an operator has acknowledged the event's existence.

action1. Generally, a procedure that is invoked to produce a specific result. It can be a script or a call to an executable that is invoked automatically in response to an event, or it can be a manual intervention. Actions can be scheduled or immediately invoked locally or remotely.

2. In BMC Impact Manager, an executable that can be run by a cell. Actions are called in an Execute rule. Users can request the execution of actions in the BMC Impact Explorer. See also local action and non-local action.

Glossary 521


adapterA background process that audits data from various sources, evaluates it for specific conditions, and creates the corresponding events. Adapters also transform event data into the format understood by BMC Impact Manager.

adapter instanceAn instance of an adapter that is defined in the adapter configuration file. The definition is given a name and specifies an adapter type, such as a log file adapter.

adapter map fileA text file that defines the translation of a message between one event format and another. It is also known as a .map file.

Administrative ViewThe BMC Impact Explorer user interface for cell administration. Administrative users can start, pause, stop, and reconfigure a cell by using this interface. They can also make changes to a cell’s dynamic data tables. You access this view by clicking the Administration tab in BMC Impact Explorer.

administratorThe person responsible for administrative tasks within the product.

aliasSee service component alias.

annotated data pointA specially marked point on a parameter graph that provides detailed information about a parameter at a particular moment. The associated data is accessed by double-clicking the data point, which is represented by a user-specified character.

API See Application Program Interface (API).

Application Program Interface (API) A set of externalized functions that allow interaction with an application.

assetAn object instance in the BMC Atrium Configuration Management Database (BMC Atrium CMDB). There are two types of assets in the BMC Atrium CMDB: non-service components, such as desks and other non-IT physical assets, and service components that participate in the delivery of enterprise services.

asset inventoryThe list of all physical and logical assets that have an identifiable value to the organization or against which threats and vulnerabilities can be identified and quantified as part of risk assessment.



Assign To The event operation action that assigns the responsibility for an event to an individual.

Assigned statusThe event status that indicates that the specified operator is responsible for the event. It results from the Assign To or the Take Ownership event operation actions.

attributeA characteristic or property of an object, such as a common-data-model service-model component class. An attribute may contain a value.

automationIn BMC Impact Explorer, operator responses that have been programmed to occur automatically when an event is received.

BBAROC language

Basic Recorder of Objects in C. A structured language used to create and modify class definitions. A class definition is similar to a structure in the C programming language. The elements in a BAROC class are called slots.

base class In programming, a root superclass, a class from which all other classes of its type are derived.

base priorityA static priority value that is combined with the component's current status to determine the final self-priority value. Typically, the base priority determines the highest self-priority that a component will reach when its status become Unavailable.

blackout scheduleA schedule that determines when one or more components will be automatically placed in a blackout state.

BMC Atrium CMDB Common Data Model (BMC Atrium CMDB CDM)An extensible schema that provides a unified representation of configuration items and their relationships to each other. It is used to store asset data (such as hardware information, service management information, and people information) and to provide a mechanism for linking that information to provide a complete view of how all assets are connected and can affect each other.

BMC Atrium CMDB Reconciliation EngineThe BMC Atrium CMDB application used to merge data from multiple sources, such as topology discovery and configuration discovery, into a consistent dataset.

Glossary 523


BMC Atrium Configuration Management Database (BMC Atrium CMDB)The database application that is the common datastore for asset, configuration management, and service model data in BMC Business Service Management products. It enables BMC products to share IT management and monitoring data and perform service management.

BMC Desktop Status Indicator (BMC DSI)An icon that appears in the desktop system tray of a computer to show the current status of an object being monitored by BMC Impact Portal. To view the status page of the monitored object, you double-click the icon.

BMC Event Manager (BMC EM)A real-time event management product license package that provides event management, including event collection, correlation, enrichment, and integration. It enables IT operations staff to focus the proper resources on resolving the most critical events.

BMC EMSee BMC Event Manager (BMC EM).

BMC IDG See BMC Impact Database Gateway (BMC IDG).

BMC IEA See BMC Impact Event Adapters (BMC IEA).

BMC IELA See BMC Impact Event Log Adapter for Windows (BMC IELA).

BMC Impact Database Gateway (BMC IDG)The interface that enables BMC Impact Manager events to be exported to a relational database.

BMC Impact Event Adapters (BMC IEA)The adapters that collect log file information, convert it to BMC Impact events, and send the events to designated BMC Impact Manager instances.

BMC Impact Event Log Adapter for Windows (BMC IELA)The native Windows platform executable that audits Windows event logs. It runs as a Windows service and checks for new event log records.

BMC Impact Explorer (BMC IX)The console with which you can connect to BMC Impact Manager instances, examine the events stored in them, and perform event and service management activities.

BMC Impact Explorer ServerObsolete term. See BMC Impact Portal.



BMC Impact Integration product (BMC II product) An interface that enables the synchronized flow of events and data between a BMC Impact Manager instance and another BMC Software product or a specific third-party product.

BMC Impact Manager (BMC IM)The BMC Impact product that provides automated event and service impact management. It runs as a service on supported Windows platforms and as a daemon on UNIX platforms, and can be distributed throughout the networked enterprise and connected in various topologies to support IT goals.

BMC Impact Manager instanceAn installation of the BMC Impact Manager product on a host computer. Compare with cell.

BMC Impact Publishing ServerThe BMC Impact Portal service or daemon that obtains the service model from the BMC Atrium CMDB and publishes (distributes) it to the designated service impact management cell or cells.

BMC Impact PortalThe BMC Portal module that you use to monitor the status of business services and their components.

BMC Impact ReportingThe BMC Impact Solutions component that you use to create and view long-term reports.

BMC Impact Service Model EditorA graphical editor that you use to develop, maintain, and extend the service model that is stored in the BMC Atrium Configuration Management Database (BMC Atrium CMDB).

BMC Impact Web Console (BMC IWC)Obsolete term. See BMC Impact Portal.

BMC IWCObsolete term. See BMC Impact Portal.

BMC IX See BMC Impact Explorer (BMC IX).

BMC IXSObsolete term. See BMC Portal.

BMC PortalA BMC product that consists of the BMC Portal Server (infrastructure) and console modules, each of which deliver specific Business Service Management (BSM) functionality. The BMC Impact Portal and BMC Performance Manager Portal are examples of console modules.

BMC Reporting FoundationThe base component on which BMC Software reporting systems and solutions are built.

Glossary 525


BMC Service Impact Manager (BMC SIM)A real-time service impact management product license package that provides technologies for both service impact and event management. BMC SIM identifies related applications and the underlying systems and databases of any software or infrastructure component and ties systems-level monitoring to the supported business services, enabling IT personnel to respond quickly to problems that threaten the delivery of business services.

BMC SIMSee BMC Service Impact Manager (BMC SIM).

BMC_System classIn the BMC Atrium CMDB Common Data Model, the parent class for all system information. In this class tree, classes representing computer systems, mainframes, application systems, and virtual systems are defined.

built-in actionAn automated, predefined action performed by a system.

business functionA group of business processes that make up a specific function, such as customer support.

business objectsAn object defined in the BMC Impact Service Model Editor, published to a BMC Impact Manager instance, and monitored in BMC Impact Portal. Business objects contribute business service data for use in status indicators and reports.

business processA series of related business activities that operate to achieve one or more business objectives in a measurable way. Typical business processes include receiving orders, marketing services, delivering services, distributing products, invoicing for services, and accounting for money received. A business process rarely operates in isolation. It depends on other business processes, and other business processes, in turn, rely on it. A business process usually relies on several business functions for support, such as IT and Personnel.

business process decompositionThe identification and cataloging of the business activities and IT resources that combine to make up a business process. The result of business decomposition is a business process model.

business serviceA service that is identifiable by business representatives and supports explicit business processes that have a clear link to the business’s value chain. Most business services have an easily identifiable senior business representative, are composed of a number of specific applications, and rely on the functioning of infrastructure services. For example, the provision of all logistic components underpinning the sale of consumer goods is a business service. See also service.



Business Service Management (BSM)A dynamic method for connecting key business services to the IT systems that manage them. BSM enables users to understand and predict how technology changes will affect their business, and how changes in the business affect the IT infrastructure.

Ccause event

In a sequence of events, the event that is identified as the cause of the other events. See also effect event.

CDMSee BMC Atrium CMDB Common Data Model (BMC Atrium CMDB CDM).

cellThe event processing engine that collects, processes, and stores events within a BMC Impact Manager instance. Each cell uses the information in its associated Knowledge Base to identify the types of events to accept and how to process and distribute them.

child collectorA collector contained within another collector. See also event collector.

class1. A data storage element. In database terms, it relates to a table in a database or a form in the Remedy AR System.

2. In BMC Impact Manager, a BAROC-language data structure that defines a type of object used in BMC Impact Manager. A BAROC class is made up of data fields, called slots, that define its properties.

3. In BMC Impact Portal: see object class.

CLI commandA command that is issued on the OS command line for automation or immediate execution. For a complete list of CLI commands, see BMC Impact Solutions: Administration. See also command line interface (CLI).

CloseThe event operation action that closes an event. If the event was assigned to the current user, Close sets the status to Closed and shows an Operator Closed entry in the operation history. Otherwise, Close sets the status to Closed and shows an Override Closed entry in the operation history.

Closed statusThe event status that results from a Close event operation action.

Glossary 527


CMDB See BMC Atrium Configuration Management Database (BMC Atrium CMDB).

collector See event collector.

collector rule See event collector rule.

collector set See event collector set.

command line interface (CLI)A user interface in which you issue commands one at a time on a command line for automation or immediate execution. In BMC Impact Manager, you use the CLI in conjunction with a graphical user interface (GUI) to operate the product.

componentA logical or physical asset that is represented in the BMC Atrium CMDB. There are two types of assets represented in the BMC Atrium CMDB: non-service components, such as desks and other non-IT physical assets, and service components that participate in the delivery of business services. See also service component.

component instanceA named component that represents an actual IT resource. See also service component.

component poolA reference to all of the logical and physical assets that participate in the delivery of enterprise services and can be part of the service model. The component pool includes both assets that are part of the service model and assets that are not. See also object and component.

component relationship See service component relationship.

component typeIn the Service Model Editor, an icon with an editable template that represents a specific common data model component class. A user can select a component type and edit its template to create a new instance of the component class.

computed prioritySee priority.

configuration management database (CMDB) See BMC Atrium Configuration Management Database (BMC Atrium CMDB).



consoleOne of the following commonly BMC Impact Manager product GUIs: BMC Impact Portal, BMC Impact Explorer, BMC Impact Reporting Console, and Service Model Editor.

console local actionAn action taken from a console and that is executed on the console host computer.

consolidation nodeA BMC Impact Manager instance that can receive and process events originating from other systems on the network.

consumerIn a service model component relationship, the component that uses a service provided by another component, the provider. See also provider.

core competencyCapabilities that collectively account for all business activities within a business enterprise, such as planning and developing products.

CORE_DATA classThe base class for all BMC Impact Manager BAROC data classes. It is the parent class for all customized data classes.

CORE_EVENT classThe base class for all BMC Impact Manager event classes. It is the parent class for all customized event classes.

Correlate phaseThe event-processing phase in which the Correlate rules are evaluated to determine whether any events have a cause-and-effect relationship. See also Correlate rule.

Correlate ruleAn event-processing rule that establishes the cause-and-effect relationship between two events. Correlate rules represent a one-to-one relationship.

correlation1. The process of identifying a cause-and-effect relationship between two events from one or more sources for the purpose of identifying a root cause.

2. The cause and effect relationship itself.

3. A type of policy.

Glossary 529


Ddata class

A BAROC class that is a child of the base data class, CORE_DATA, and that defines a type of data. Users can create their own data classes.

datastoreA central place in which an aggregation of data is kept and maintained in an organized way.

Decline OwnershipThe event operation action that indicates that the assigned operator does not accept responsibility for an event. Decline Ownership clears the owner’s name, sets the status back to Acknowledged, and shows a Declined entry in the operation history.

default status view typeIn the BMC Impact Portal, one of the view types available from the Status tab.

Delete phaseThe event-processing phase in which Delete rules are evaluated and actions are taken to ensure that data integrity is maintained when an event is deleted from the event repository during the cleanup process.

Delete ruleAn event-processing rule that is used to clean up obsolete information when an event is deleted from the repository. Delete rules are evaluated when an event is deleted and they take actions to ensure that data integrity is maintained.

destinationOne end of a relationship. In the case of an impact relationship, it is the end associated with the consumer of events.

draft service modelA working version of the service model that can contain both published and unpublished elements.

duplicate eventA subsequent occurrence of an event that has already been received, such as the second or later notification that a component is down. An event that has matching values for all the slots defined with the dup_detect=yes facet in the event class definition. You can use Regulate rules to detect and count duplicate events. See also facet.

During ScheduleTime periods in which a component has a higher service demand and higher importance than in the off-schedule time period. In a During Schedule time period, the component is typically assigned a higher priority value and downtime cost than during an off-schedule time period.



For example, if a high service demand occurs during 9:00 AM and 5:00 PM, you can create a During Schedule timeframe for that time period. See also off-schedule time and Exceptions Within During Schedule.

During Schedule costThe outage cost (per second) related to the component when the outage occurs within the During Schedule timeframe.

dynamic collectorA special type of collector that, in response to events, can add or remove event collectors from the cell during runtime.

dynamic dataContextual reference data that is stored in a table in the event repository (mcdb) and that is updated during runtime if the context has changed. Administrators can use and manipulate dynamic data in the BMC Impact Explorer Administration View.

EECF

See Event Condition Formula (ECF).

effect eventIn a sequence of events, the event that is identified as an effect of a cause event. See also cause event.

elected event See impact event.

encryption keyThe seed encryption key. If the destination product has a key value, all clients must encrypt their communications using the same key value.

enrichment1. The process of adding to or modifying the original event data to enhance it for problem management, service management, correlation, automation, notification, or reporting functions.


escalation1. The process of referring a problem up the chain of command.


Glossary 531


escalation procedureThe particular steps defined for performing escalation. For example, you might specify that operations personnel would be notified within 5 minutes of a problem occurrence, a manager would learn of it after 15 minutes, and a director after 1 hour (if the problem still exists).

eventIn a BMC Impact environment, a structured message passed to and from cells. Each event is an instance of an event class.

Event Adapters See BMC Impact Event Adapters (BMC IEA).

event class1. A BAROC class that is a child of the base event class, CORE_EVENT, and that defines a type of event.

2. A category of events that you can create as a child of the base event class, CORE_EVENT, according to how you want the events to be handled by an event manager and what actions you want to be taken when the event occurs. Event classes may be inherited from parent objects, depending on the specific product. Event classes are inherited from parent objects in BMC Impact Manager.

event collectorAn event grouping whose content is defined by its collector rule. Event collectors are displayed in the BMC Impact Explorer and are defined in the BMC Impact Manager Knowledge Base. See also event collector rule.

event collector ruleA type of rule in the Knowledge Base that defines how events from a cell are organized and presented in the BMC Impact Explorer. Collector rules are written in Master Rule Language (MRL).

event collector setA group of event collectors, organized in a parent-child hierarchy, that results from progressive filtering of the incoming events that match the top-level (parent event collector) criteria. A collector set organizes the events for display in the BMC Impact Explorer.

Event Condition Formula (ECF)The section of an MRL rule definition that specifies the conditions that an incoming event must meet to trigger evaluation of the rule during processing. For example: APP_MISSING_PROCESSES where [hostname: == ‘red1’,sub_origin: contains ‘System’] is an ECF. See Master Rule Language (MRL).

event datastoreAn archive of generated event data.



event group A grouping of collectors that depicts the relationship of events through the hierarchy of the navigation tree. Each level of the collector set is shown as a node under the event group. The parent level of an event group represents all of the events associated with the collectors. An event list is associated with the lowest level nodes of an event group. The parent level of an event group is associated with an image view.

event list1. A tabular listing of events.

2. In BMC Impact Explorer, you can access the event list from the Events tab.

Event Log Adapter for Windows See BMC Impact Event Log Adapter for Windows (BMC IELA).

event managementThe collection and correlation of events across an enterprise to enable IT operations to focus the proper resources on the most critical events.

event management policyOne of several generic rule types that perform actions against events that meet selection criteria specified in an associated event selector. Unlike manually written rules, event policies are defined interactively using the Event Management Policy Editor in the BMC Impact Explorer. See also user-defined policy.

event operation historyThe tabular display of the operation actions taken against an event in BMC Impact Explorer. You can access the event operation history from the Operations History tab of the Event Details pane on the Events tab in BMC Impact Explorer.

event operationsCommands issued by operators to respond to events and correct the problems that the events represent. Operators perform these commands from an event list in BMC Impact Explorer.

event processor See cell.

event propagationThe act of forwarding events and maintaining their synchronization among multiple BMC Impact Manager instances (cells).

event repository1. An archive of generated event data.

2. In BMC Impact Manager instances (cells), the storage facility (mcdb) in which event information is stored.

Glossary 533


event selection criteriaThe syntax of an event selector that specifies the conditions that an incoming event must meet to trigger selection of the event for rule evaluation during each phase of event processing. You can specify event selection criteria through the BMC Impact Explorer GUI. An MRL Event Condition Formula (ECF) also contains event selection criteria. An event selector contains one or more event selection criteria.

event selectorThe filtering mechanism associated with an event management policy that selects the events against which the event management policy performs actions. An event selector contains one or more event selection criteria. Event selectors are defined interactively by using the BMC Impact Explorer. An event management policy can use one or more event selectors.

event sourceThe monitored IT resource from which source event data is collected, such as an operating system or application log file.

event timeoutAn event timeout policy changes an event status to closed after a specified period of time elapses.

Events ViewThe BMC Impact Explorer user interface for viewing and manipulating event data. See also Services View and Administration View.

Exceptions Within During ScheduleTime periods in a service schedule that are exceptions to the During Schedule timeframe, and in which a component has a lower service demand and lower importance than in the During Schedule time period. For example, if you have a During Schedule timeframe of 9:00 AM to 5:00 PM, you can specify the period between 12:00 PM and 1:00 PM as an Exception Within During Schedule timeframe. The time between 12:00 and 1:00 is treated as Off schedule time, and a lower priority is associated with the component in that time. See also During Schedule and off-schedule time.

Exceptions Within During Schedule costThe outage cost (per second) related to the component when the outage occurs within the Exceptions Within During Schedule timeframe.

Execute phaseThe event-processing phase in which Execute rules are evaluated, and, if conditions are met, specified actions are performed.

Execute ruleAn event-processing rule that performs actions when an attribute (slot) value changes in the event repository. Execute rules are evaluated during the Execute phase of event processing. Often, the resulting actions are internal actions, but you can use the execute primitive in a rule to call an external executable.



expressionA combination of operators, operands (constants, variables, functions, and primitives), and conditions that represents a value or a relationship between values.

Ffacet

A specific attribute of a BAROC class slot (field) that either controls the values that the slot can have or controls aspects of a class instance's processing.

field See attribute.

Filter phaseThe event-processing phase in which Filter rules are evaluated to determine which events need additional processing or are unneeded and can be discarded.

Filter ruleAn event-processing rule that determines whether a specific type of event should be passed as it is, subjected to further processing, or discarded during the Filter phase.

functionCode that executes an operation in a cell and returns a value. A function can be used as an expression within a rule or a policy and in alias formulas. See also primitive.

Ggateway

See BMC Impact Integration product (BMC II product).

gateway.export fileA special file that controls the propagation and synchronization of events to a BMC Impact Manager Integration product. The file is in the $MCELL_HOME/etc/ directory on UNIX platforms and in the %MCELL_HOME\etc\ directory on Windows platforms.

global recordA special BAROC class instance that defines a persistent global variable. When a cell starts, it creates one instance of each global record defined in the Knowledge Base and restores any existing values. Global record definitions are stored in the record subdirectory of the cell Knowledge Base. You can get and set global record values in MRL rules or by using the BMC Impact Manager CLI mgetrec and msetrec commands.

global slot orderIn BMC Impact Explorer, a set of slots (attributes), in a particular order, that is associated with a filter and is shared among users.

Glossary 535


global timeframeA timeframe that is created in the Service Model Editor and stored in the BMC Atrium CMDB. A global timeframe is usable from within the BMC Impact Service Model Editor and the BMC Impact Explorer and is available to all cells within an environment. See also local timeframe.

groupA logical or an arbitrary collection of user-defined objects that may or may not have measurable relationships and may or may not have summary data associated with them.

Hheartbeat

1. A periodic message sent between communicating objects to inform each object that the other is still active and accessible.

2. In BMC Impact Manager, a dynamic data object sent by a cell to monitor other cells to verify that they remain active and accessible.

heartbeat intervalThe time between heartbeats; the period of the heartbeat.

highest value functionA calculation method that is used to determine impacts priority

Iimage view

A graphical and hierarchical display that depicts a business view. You can create image view objects or elements to represent managed systems (tools), geographic locations, operators, time, severity levels, categories, and so forth.

impactAn assessed measure of the effect that an incident, fault, or other change will or may have on business operations or service levels.

impact eventAn event whose status is used in computing the status of its associated service component. By default, the status of each event associated with a service component is used to compute its status. However, you can exclude events.

impact production datasetInstances of an environment that are effectively published to the environment’s impact managers. The following example is an impact dataset:

BMC.IMPACT.PROD: the impact production dataset associated with the BMC Impact Service Model Editor



impact propagationThe effect of an impact to a providing service component (provider) on the service components that use its services (consumers) as defined by an impact relationship. See also impact relationship.

impact relationshipA relationship between two service components in a service infrastructure in which a consumer component depends on a provider component to deliver some needed resource to it. A change in status of the provider affects (has an impact on) the status of the consumer component.

impacted stateThe object state that indicates that an object’s functioning is impaired.

impacts priorityThe priority of a component based on the self-priorities of components that this component impacts. So that the remediation process can be aligned with business needs, the computed priority for each causal component is based upon impacts priority.

The value is the result of the combined priorities of all the other components that are impacted when the component goes down. The value is dynamic and changes as the self-priorities of the impacted components change.

import datasetA dataset that contains objects imported to the BMC Atrium CMDB from an external data source such as BMC Topology Discovery.

inactive relationshipA relationship between two components in a service infrastructure in which there is no impact to the consumer component. An inactive relationship indicates that the two components are connected logically and are represented visually as “linked.” See also impact relationship.

in-modelQualifies a service component as being part of a service model. By default, new components in the BMC Atrium CMDB do not belong to any service model. To change a component to in-model, you will typically use the BMC Impact Service Model Editor. Impact relationships get automatically set to in-model when their related components are in-model. Only those that are in-model can be published to a production cell.

included timeframesA set of timeframes that are included in the service schedule.

indexA value that is used by an MRL rule to sort the slot information for an event or data object.

informational alertAn alert of relatively low importance, such as a message about a routine state change. See also severity.

Glossary 537


infrastructure elementAn addressable object that can be monitored, such as a managed system in PATROL.

instance1. A specific object with specific attributes or characteristics that distinguish it from other items (members) of its class or type.

2. In BMC Impact Manager, an object that has specific attribute values and that was created using a class definition.

integration product See BMC Impact Integration product (BMC II product).

interface classA BAROC class that defines the programming interface used by an MRL rule primitive, such as get_external, to return data from an external program. At cell startup, an interface class is loaded into memory. The cell invokes the executable defined in an argument of the primitive. The executable’s value is returned by the interface.

internal base class A BAROC internal class that defines the required structure for the base class from which a group of BMC Impact Manager classes is derived.

internal eventAn event that is created by the cell during event processing. An internal event is processed in the same way as an incoming event. All internal events are processed before any new, incoming external events are processed.

Internet Protocol (IP) adapterAn adapter that collects and translates events from a Telnet, UDP, or TCP data source.

IP adapter See Internet Protocol (IP) adapter.

IT component See BMC_System class.

Kkey slot

A slot whose value is compared during searches.

Knowledge Base (KB)A collection of information that forms the intelligence of a BMC Impact Manager instance and enables it to process events and perform service impact management activities. This information includes event class definitions, service component definitions, record definitions, interface definitions, collector definitions, data associations, and processing rules.



Llocal action

An executable that you can run directly from the BMC Impact Manager. Local actions are written in XML and are stored in the OS-specific subdirectory of the bin directory of the BMC Impact Manager cell Knowledge Base.

local timeframeA timeframe that is created in the BMC Impact Explorer. A local timeframe is stored in a single cell and is available to the event management policies within the cell. See also global timeframe.

logical componentA non-physical object that represents something that does not exist physically in the IT infrastructure such as a service, geography, organization, or user group.

Mmacro

An executable used in .map files to manipulate the fields used for event translation.

manifest.kbA central locator file that specifies the locations of the directories that make up a Knowledge Base. The manifest.kb file is used by the compiler to load the Knowledge Base sources files for compilation.

map See image view.

maskingThe process of combining an overlay dataset with a standard dataset to obtain a view in which the standard dataset objects are overlaid or masked by any modified copy contained in the overlay dataset.

Master Rule Language (MRL)A compact, declarative language used to define rules and collectors for processing and organizing events in BMC Impact Manager. Uncompiled rule and collector source files have a .mrl file extension.

mccompThe BMC Impact Manager rules compiler. Rules are written in the Master Rule Language (MRL). The platform-independent compiler converts them to byte code that the cell can read and process.

mcdb See event repository.

Glossary 539


mcell.conf fileThe configuration file that contains configuration options for a BMC Impact Manager instance (cell). It is in the $MCELL_HOME/etc/ directory on UNIX platforms and in the %MCELL_HOME%\etc\ directory on supported Windows platforms.

mcell.dir fileThe file that lists the cells to which a BMC Impact Solutions product or component can connect and communicate. The information in each cell includes its name, its encryption key, and its host name and port number. This file is in the $MCELL_HOME/etc/ directory on UNIX platforms and in the %MCELL_HOME%\etc\ directory on supported Windows platforms.

mcell.modify fileThe file that lists the slots that affect the mc_modification_date slot. When a specified slot is modified, the time stamp of the modification is reset in the mc_modification_date slot, so that slot is listed in mcell.modify.

mcell.propagate fileThe configuration file that specifies the slot values that are synchronized during event propagation between BMC Impact Manager instances (cells). It is in the $MCELL_HOME/etc/ directory on UNIX platforms and in the %MCELL_HOME%\etc\ directory on supported Windows platforms.

mcell.trace fileThe configuration file that specifies the trace information about a BMC Impact Manager (cell) that should be recorded and the location to which it is written. It is in $MCELL_HOME/etc/ directory on UNIX platforms and in the %MCELL_HOME%\etc\ directory on supported Windows platforms.

mclient.conf fileThe configuration file that specifies the configurations for the BMC Impact Manager CLI commands. It is in the $MCELL_HOME/etc/ directory on UNIX platforms and in the %MCELL_HOME%\etc\ directory on supported Windows platforms.

mclient.trace fileThe configuration file that specifies the trace information that should be collected for the BMC Impact Manager CLI commands and the location to which it should be written. This file is in the $MCELL_HOME/etc/ directory on UNIX platforms and in the %MCELL_HOME%\etc\ directory on supported Windows platforms.

mcontrol commandThe CLI command that sends control commands to a BMC Impact Manager instance (cell).

mc_udidSee universal data identifier (mc_udid).



mean time between failures (MTBF)The average elapsed time from the point at which an IT service object is made available until the next occurrence of failure in the same service object.

mean time between system/service incidents (MTBSI)The average elapsed time between the occurrence of a system or service failure and the next failure in the same system or service.

mean time to repair (MTTR)The average elapsed time from the occurrence of an incident to restoration of the service.

metaclass See internal base class.

MetaCollectorA virtual collector that contains a group of event collectors from multiple BMC Impact Manager instances. It exists only in the BMC Impact Explorer. You can customize it to suit your organizational needs.

moduleA product that plugs into the BMC Portal.

MTBF See mean time between failures (MTBF).

MTBSI See mean time between system/service incidents (MTBSI).

MTTR See mean time to repair (MTTR).

Nnavigation tree

See navigation tree view.

navigation tree view1. A hierarchical display of the objects and user-defined groups and views.

2. In BMC Impact Explorer, a hierarchical view of defined objects and groups. An object can be a filter, rule, or event. The groups are arranged to show relationship and dependency between the managed systems. The navigation tree view appears in the left pane.

3. In the BMC Portal, a hierarchical display of groups defined in a view.

Glossary 541


New phaseThe event-processing phase in which New rules are evaluated to determine which events in the repository should be updated with new information from new incoming events.

New ruleAn event processing rule that is evaluated during the New event processing phase, and can update events stored in the repository (mcdb) with fresh information from new incoming events.

nodeA BMC Impact Manager instance that can receive only events originating on the local host system.

non-local actionA user-initiated action that does not execute on the user console host computer.

non-service componentA logical or physical asset defined in the BMC Atrium CMDB that does not participate in the delivery of business services, such as a desk or other non-IT physical asset. A non-service component is not visible within the BMC Impact Service Model Editor.

normalizationThe process of homogenizing event data into a common event format so that a standard set of event data is collected and reported regardless of the event source.

not-in-modelA service component that exists as a logical or physical asset in the BMC Atrium CMDB but is not currently part of the service model. A not-in-model service component is visible within the BMC Impact Service Model Editor component pool.

notification1. A message, either detailed or concise, that contains information about a condition that triggered an alert state on a monitored element. An email message or SNMP trap that is sent when the program detects a problem that triggers an alert.


null relationshipSee inactive relationship.



Oobject

1. An item that can be inserted into a dashboard. For example, a chart, link, or Active-X control.

2. A generic term for anything that is displayed in the user interface.

See class.

object classIn BMC Impact Solutions, a data structure that defines a type of object. An object class can be a BAROC-language data structure in a BMC Impact Manager cell Knowledge Base or a Common Data Model (CDM) data structure in the BMC Configuration Management Database. A class is made up of data fields, called attributes (slots) that define its properties. See also event class and object.

object linkingIn BMC Portal, the ability to associate two objects that are the same IT asset or resource but that occur in different console modules, and manage them as one object.

off-schedule timeTime periods in which the component has a lower service demand, a lower priority, and lower downtime cost than in the During Schedule time periods. Off-schedule time includes any time that is not defined in the service schedule. Exceptions Within During Schedule time periods are treated as off-schedule time when determining base priority. See also service schedule, Exceptions Within During Schedule, and During Schedule.

open eventAn event that may require action. An open event may have a status of Open, Acknowledged, Assigned, or Blackout.

Open statusThe event status that indicates that the event has not been examined, or that neither an operator nor an automated process has been assigned responsibility for the event.

Pparent event collector

A event collector that contains child collectors to form an event collector set.

permissionA rule associated with an object to control which users, groups, and roles can access the object and in what manner. A permission gives the user a specific type of access to the object (for example, read permission or write permission). See right.

phase, rule See rule phase.

Glossary 543


policy See event management policy.

policy class A BAROC class that is a child of the base data class POLICY and that defines a type of policy.

policy instanceA specific implementation of any of the types of event management policies. For example, you could have an instance of a blackout policy that defined blackout periods for holidays and another instance of the same policy that defined blackout periods for monthly maintenance.

portA number that designates a specific communication channel in TCP/IP networking. Ports are identified by numbers. BMC Impact Manager communicates using the ports specified during installation.

portalThe access point for web-based management tools. The portal houses applications installed by a user and communicates with remotely monitored systems. See also BMC Portal.

presentation nameA descriptive name or label that you can designate to appear instead of a specific internal slot name or class name in the user interface screens. You define presentation names in resource files.

primitiveSimilar to a function, code that executes an operation in a cell and returns a value; can be used as an instruction, or as a function if contained in a Boolean expression.

priorityAn attribute indicating the precedence or scale of importance of an event.

priority propagatorA component that is configured to propagate its priority to its causal components.

production cellA BMC EM or BMC SIM cell that service operators and service managers use to monitor the events and services associated with IT resources in real time.

production viewA read-only view in the BMC Impact Service Model Editor that displays some of the components and relationships contained in the production dataset (the visibility can be constrained by user permissions). Each BMC Impact Service Model Editor user can have several of these views. BMC Impact Service Model Editor users can dynamically convert a production view into a sandbox View. See also sandbox and sandbox View.



promotionA user-initiated action in BMC Impact Service Model Editor that assists in reconciling objects (such as components, relationships, and management data) from a sandbox dataset to the production dataset.

Propagate phaseThe event-processing rule phase in which Propagate rules are evaluated to determine the events to be forwarded to another cell or to a BMC Impact Integration product.

propagate policy A type of policy that forwards events to other cells in the managed domain. A propagate policy is evaluated during the Propagate phase of event processing.

propagate priorityWhen a component forwards its self-priority to its causal components.

Propagate ruleAn event-processing rule that is used to forward events to other cells in the managed domain. Propagate rules are evaluated during the Propagate phase of event processing.

propagated eventAn event that is forwarded from one cell to another cell or to a BMC Impact Integration product during the Propagate phase of event processing.

providerA logical or physical asset that delivers services or provides resources that are used by other service components in the delivery of business services.

publish environmentAn environment that consists of a production dataset, an impact production dataset, and one or more test or production cells that are published.

published-modified componentA service component that has been modified since its service model was published (distributed) to BMC Impact Manager instances.

published componentA service component that is currently part of the published service model that has been distributed to BMC Impact Manager instances.

publishingThe automated or user-initiated action performed by the BMC Impact Publishing Server in which components, relationships, and management data from the production dataset are published to one or several production or test cells.

publishing serverSee BMC Impact Publishing Server.

Glossary 545


published service modelA service model that is currently distributed to BMC Impact Manager instances (cells). It contains only published elements.

RReconciliation Engine

See BMC Atrium CMDB Reconciliation Engine.

record See global record.

recurrence1. The characteristic of occurring more than once.

2. The type of policy that handles recurrent events. See also recurrent event.

recurrent eventAn event that occurs more than one time. Both scheduled and unscheduled events can be recurrent events: a monitored hardware device could experience multiple voltage spikes within a single polling cycle, and a reminder notification could be scheduled to be sent periodically until acknowledgment is received. See also duplicate event.

Refine phaseThe first phase of event processing, in which Refine rules are evaluated to validate incoming events and, if necessary, collect additional data needed before further event processing can occur.

Refine ruleA rule evaluated during the first phase of event processing to validate an incoming event and, if necessary, to collect any additional data needed before further processing can occur.

regular expressionSometimes referred to as “regex,” regular expressions are used in pattern matching and substitution operators. A simple regular expression is a sequence or pattern of characters that is matched against a text string when performing search and replacement functions.

Regulate phaseThe event-processing phase in which Regulate rules are evaluated and, if true, collect duplicate events for a time period and, if a specified threshold of duplicates is reached, passes an event to the next processing phase.

Regulate ruleAn event-processing rule that processes duplicate events or events that occur with a specified frequency. With a Regulate rule, you can create a new event based on the detection of repetitive or frequent events. See also Regulate phase.



related eventThe event that was generated by a source event. A related event can also be the source of other related events.

relationA logical association that expresses the relevance of one event to another.

relation definitionThe BAROC data instance that defines a relation.

remote action A user-initiated action that does not execute on the user console host computer; an executable that can be run by a cell. Remote actions are written in the Master Rule Language (MRL) and are stored in the OS-specific subdirectory of the bin directory of the Knowledge Base.

ReopenThe event operation action that reopens an event that is in the Closed state. Reopen sets the status to Open and shows a Reopen entry in the operation history.

repository See event repository.

restricted objectA dynamically created object that contributes to service status, but which the user does not have permission to view.

rightAn authorization entitling a user to perform a certain action. Rights apply to a whole application or to specific objects of a certain type.

root cause analysisThe process of monitoring events and correlating event data to identify the true cause of a problem.

ruleA conditional statement written in MRL and that, if determined to be true, executes actions. Cell event processing occurs in phases with the cell comparing each event to the series of rules associated with that phase. Each phase’s rules are evaluated one by one before the event is passed to the next phase. The order in which rules are evaluated during a particular phase is based on the order in which the rules were loaded.

rule engine See cell.

rule phaseA specific stage of event processing. Event processing compromises a combination of sequential phases and nonsequential phases, each with a corresponding rule type.

Glossary 547


rule typeThe designation that identifies a rule as being in a specific phase of event processing. The cell executes rules within the context of the associated event-processing phase and in the order in which the rules were loaded from the rule file.

Ssandbox

An overlay dataset associated with the production dataset. The overlay dataset provides a view of the underlying production dataset masked by changes made by the user in the overlay dataset.

sandbox ViewIn the BMC Impact Service Model Editor, a personal work area for designing and developing a service model.

saved stateThe state of a BMC Impact Manager instance (cell) as determined by the StateBuilder utility, statbld.exe. The StateBuilder utility periodically consolidates the data in the transactions file (xact) to produce the “saved state” of the product instance. This information is stored in the event repository (mcdb) and the state is reloaded when BMC Impact Manager restarts.

scheduleSee service schedule.

SDK See Software Development Kit (SDK).

selector See event selector.

selector class A BAROC class that is a child of the base data class SELECTOR and that defines a type of event selector.

self-priorityThe result of mapping the base priority value for a component with its status value.

send to testA user-initiated action in the BMC Impact Service Model Editor in which objects (such as components and relationships) are copied from a sandbox View to a test dataset. The copy captures both sandbox objects and production objects to reproduce a consistent model or submodel in the test environment.



serviceAn integrated composite of several components, such as management processes, hardware, software, facilities, and people, that delivers something of value to satisfy a management need or objective.

service catalogA list of IT services that identifies the physical and logical assets that help provide a service. The data collected in the service catalog can be used to form a configuration management database.

service componentA logical or physical resource that participates in the delivery of services. A service component is any class that is a subclass of the BMC_BaseElement class in the BMC Atrium CMDB or the cell Knowledge Base.

service component aliasA name that is assigned to a service component instance and used in associating an event type with the component instance. You add an alias to a service component instance’s definition in the Service Model Editor. A service component instance can have several different aliases to enable different event types to be associated with it.

service component relationshipIn a service model, the association of two service components in which one component, the provider, delivers some resource or service to the consuming component or components. See also provider and consumer.

Service Impact Management (SIM)A technique for managing the impact of IT events on the company’s core business services to ensure their delivery. See also BMC Service Impact Manager (BMC SIM).

service modelAn extensible system for defining the various resources that combine to deliver business services, for modeling their behaviors and functional relationships, and for managing the delivery of the resulting services. In Service Impact Management, the map of how IT components relate to the business processes that they support. All IT events and service issues are analyzed against the service model to determine the root cause of problems and to report on service impacts.

service scheduleA set of timeframes that includes During Schedule timeframes, Exceptions Within the During Schedule timeframes, and the priority values and downtime costs for a component associated with each timeframe.

Services ViewThe BMC Impact Explorer user interface for viewing service-model components and their relationships and for viewing and managing the events that affect service availability.

Glossary 549


Set PriorityThe event operation action that escalates or de-escalates an event. Set Priority sets the events priority to the specified values and shows a Priority Set entry in the operation history.

severityAn indication of the seriousness of an event.

severity-to-status mapping tableOne of the two tables that relate event severity and service component status. It is used by the cell to map the severity of an impact event to a status value to be used in the computation of the associated service component's status. See also status-to-severity mapping table.

slotAn field in a BAROC class definition. A class definition consists of one or more slots. Each slot has a data type and can have specific attributes, called facets, that can control the values that the slot can have or other aspects of a class instance’s processing. A subclass inherits all the slots of the parent class. See also attribute.

slot facet See facet.

SM See service model.

SNMP adapterAn adapter that listens at a port for SNMP traps. It evaluates the traps and formats them based on the configured event mapping. If the event-mapping conditions are satisfied, it sends the event to the cell.

SNMP Adapter Configuration ManagerA component of the BMC Impact Event Adapters that converts Management Information Base (MIB) data into BMC Impact Manager class data.

Software Development Kit (SDK)A set of procedures and tools with which you can develop a type of application.

source dataThe information that enters the BMC Impact Manager system from another entity and that will be transformed into an event in the system.

source eventThe event that generates a related event.

statbld.conf fileThe configuration file for the StateBuilder utility. It is in the $MCELL_HOME/etc/ directory on UNIX platforms and in the %MCELL_HOME%\etc\ directory on supported Windows platforms.



statbld.trace fileThe configuration file that specifies the trace information to be collected for the StateBuilder utility and where it should be written. It is in the $MCELL_HOME/etc/ directory on UNIX platforms and in the %MCELL_HOME%\etc\ directory on supported Windows platforms.

state change eventA generated event type that records changes in a component’s status. State change events never participate in component status computation.

StateBuilder utilityThe utility, statbld.exe, that periodically consolidates the data in a cell’s transactions file (xact) and writes the “saved state” of the cell to the repository (mcdb).

status1. For events, an indication of the event’s management. Possible values are Open, Closed, Acknowledged, Assigned, and Blackout.

2. For service components, an indication of the relative availability of an IT resource. Possible values are OK, Unknown, Blackout, Information, Warning, Minor Impact, Impacted, and Unavailable.

status-to-severity mapping tableThe status-to-severity map is used by the cell to map the main status of a component to the severity of a history event.

status computation modelA model that determines the status of a consumer service component when a change in the status of its provider service component occurs.

status propagationThe effect that a change in status of a provider component has on the status of its consumer components.

STATUS_PROPAGATION tableA dynamic data table that defines the different pairs of service component types whose instances can have a relationship and the status propagation model to be used for each relationship.

store and forwardA mechanism that ensures that if an event cannot reach its destination, it is saved in a file and sent when a viable connection to the destination becomes available.

stored eventAn event that has been processed by the cell and stored in its event repository. Only stored events can be returned by queries and displayed in BMC Impact Explorer, returned by the mquery CLI command, or referenced by the Using and Update clauses of an MRL rule.

Glossary 551


superclassA hierarchically superior event or data class. A class that is derived from another class inherits part of its attributes (slots) from its superclass.

suppression1. The intentional exclusion of an event or a type of event.

2. The type of policy that governs event suppression.

syslog adapter An adapter that collects information from the log file generated by the UNIX daemon syslogd. The syslog adapter reads syslogd events and formats and sends them to the cell.

TTake Ownership

The event operation action that assigns the current user as the event’s owner, sets the event status as Assigned, and shows an entry of Taken in the operation history.

targetThe entity designated to receive events from an adapter, an event generator, or a BMC Impact Manager instance. Also, a cell whose content currently is displayed in a BMC Impact Explorer dialog box.

test cellA cell, distinct from a production cell, in which to test an in-development service model. A test cell is either a BMC EM cell used to develop and test event management data, rules, policies, actions, and collectors, or a BMC SIM cell used to develop, test, and publish service models.

test datasetA dataset that is used to relay objects from a sandbox View to a test cell. Each BMC Impact Service Model Editor user has a dedicated test dataset. A test dataset combines with a test cell to make a user test environment. The following example is a test dataset:

BMC.IMPACT.Joe.TEST.1: the impact dataset containing instances that are effectively published to the impact manager of Joe’s Test environment

threshold1. In BMC Impact Manager, the point beyond which the value of a facet, slot, or other attribute can trigger an alert.


Threshold ruleA rule that executes if the number of events exceeds the specified number within a particular timeframe.



TIME_FRAME classA BAROC class that is a child of the base data class TIME_FRAME and that defines a type of timeframe.

TIME_ZONE classA BAROC class that is a child of the base data class TIME_ZONE and that defines a type of time zone.

timeframe1. User-defined blocks of time that can be added to a service schedule. Timeframes are added to the service schedule as During Schedule timeframes or Exceptions Within During Schedule timeframes. Any unassigned time is considered Off schedule. See also During Schedule, Exceptions Within During Schedule, and off-schedule time.

2. The specification for the period during which an event management policy instance is in effect.

Timer phaseThe event-processing phase in which Timer rules for the delayed execution of another rule type are evaluated. This phase spans the New, Abstract, Correlate, and Execute phases of event processing.

Timer ruleAn event-processing rule that triggers the delayed execution of another type of rule.

Timer trigger See Timer rule.

tree See navigation tree view.

Uunknown object

An object whose status cannot be determined because of a connectivity failure.

universal data identifier (mc_udid)A unique, system-generated value used to identify a specific service component instance. Each service component must have a value for the mc_udid attribute (slot). One use of the universal data identifier is in associating aliases to a service component instance.

unpublished componentA service component that is currently part of the service model but that has not been published (distributed) to BMC Impact Manager instances.

Glossary 553


user-defined policyA type of policy that a service manager or operations manager can define to perform specialized event processing; not available through any BMC Impact Explorer built-in policy. See also event management policy

Using clause An MRL rule clause that is used primarily to retrieve data instances for a dynamic rule, but can also be used to retrieve instances of past events.

VView

In the Service Model editor, the centralized area where you begin to build and maintain a service model. Each View is unique to a user account. Multiple users can have different Views into the same service model. You can save Views for later reuse.

Wweighted function

A calculation method that is used to determine impacts priority.

When clauseA part of MRL rule syntax for Abstract, Correlate, Execute, Propagate, and Timer rules. Events must first meet the selection criteria in the rule before the When clause is evaluated. Changes to slot values cause When clauses to be re-evaluated.

wildcardA type of pattern matching that uses the asterisk character (*) to represent any number of different characters, and the question mark character (?) to represent a single unknown character. See also regular expression.

workspaceSee View.



Index

Symbols$data variable 509, 511, 515.jar files

digitally signing 220

Aaction result event parameters

ActionResultInlineLimit 444ActionResultKeepPeriod 444

activating maximum tracing for all modules 390adapter engine 197adapter, event

described 238adapters

BAROC classes 473default configuration file 196default engines 197Engine parameter specifies type 197global parameters 197mcxa.conf 196

addingslot flags and default values 395slot names and representation types 394

administering remote cellsAdministration View (BIX) 80

Administration Viewcreating new data instance 253edit menu 255exporting data 256managing cells from 80menu, context 253metrics collection 87overview 242Reload menu 82Slot Quick Filter 248sort multiple columns 251sort, single-click 252

administrator activitiesmodifying cell connection settings 136

AllowAdapterFrom 449AllowBrowserFrom 449AllowCellFrom 449AllowCLIFrom 449AllowConnectionFrom 449

AllowEIFFrom 450application.properties configuration file 129architecture

IP adapters 490assignments, map files, slots 478

BBAROC

classes, mcxa.baroc file 473BAROC language

described 238Basic Recorder of Objects in C. See BAROCBIX

defining presentation name search order using ix.properties file 217

extracting presentation name resource files 215BIX tool tips

enabling and disabling for presentation names 221blackout policy (standard), creating 285blackout policy, creating 286, 320Blackout.cfg 272BMC Event Manager solution

overview 237BMC Impact Administration server

command line interface 91configuration files 91customizing BMC IX colors 109default mapping of roles and permissions 98defining client logging 108defining group roles 95defining high availability for Impact Administration

cell 112defining permissions 98defining primary and secondary servers 109defining standalone servers 109editing logging properties 108high availability 109iadmin command 91iadmin command format 93iadmin command options 92iadmin reinit options 111LDAP configuration 115manual editing guidelines 94Master server 90, 109

Index 555


BMC Impact Administration server (continued)purpose 90relation to BMC Impact Portal 90, 102relation to Impact Administration cell 93Standard server 90, 109starting and stopping 91supporting remote actions for infrastructure

management 114synchronization properties 110synchronizing with BMC Atrium CMDB 105synchronizing with BMC Impact Portal 102transaction and trace logs 112updating cell information 106updating user information (file-based authentication)

103BMC Impact Event Adapters

used in event collection 238BMC Impact Explorer

Administration View, overview 240configuration files, event group 152console views 239defining presentation name search order using

ix.properties file 217Event Groups, described 361Events View, overview 239overview 239remote cell administration 80role in event management 239Services View, overview 240

BMC Impact Manager CLIcommon options 383configuration of 440described 40

BMC Impact Manager productcell, described 36overview 36

BMC Impact Portalcommunication and encryption parameters 139configuration parameters 128configuring the ixs.properties file 128policy file 147report goal line configuration parameters 139

BMC Impact Service Model Editorrole in service model development 241

BMC Portalstarting from command line 127starting from Services Window 127starting on UNIX 127stopping from command line 127stopping on UNIX 127URL address 128URL address syntax 128

BMC Software, contacting 2BMC_PORTAL_KIT_HOME environment variable 466,

467buffering

mposter command 426


buffering (continued)using mposter 426

Business Service Managementrole of BMC Event Manager solution 237role of BMC Impact Explorer 239

Ccell

Admin 185defining high availability for Impact Administration

112Impact Administration 112, 185

cell configurationcreating files for specific cells 46files 69modifying cell connection settings 136

cell functionsSIM 37

Cell Info dialog box (BIX) 87cell names

conventions for 401cell objects, retrieving 422, 437cell parameters

CellDescription 444CellOperationLevel 444CellOperationRelax 444ConnectionPortRange 445ConnectionPortReuse 445ProcessingLimitPercentage 445ServerAllInterfaces 445ServerDirectoryName 445ServerPort 445SystemLogDirName 445SystemTmpDirName 445

cell tracing parameters, list of 461CellDescription 444CellErrorEvents 455CellEventEnable 455CellMetricsEnabled 455CellOperationLevel 444CellOperationRelax 444cells

administering remote cell (in BIX) 81creating new 401, 434deleting 406described 36EM

functions of 36extracting state files from 434heartbeats 455importing data into 272naming, mcrtcell command 401obtaining status using mcstat 406permissions required to start on UNIX 41posting events 422


cells (continued)production, described 37reconfiguring 69, 401recovering data 432remote administration 80retrieving information 408running in foreground 387sending events to 422, 437SIM, functions of 36starting 387starting a specified cell 386starting and stopping 40starting and stopping on UNIX 40starting and stopping on Windows 41starting or stopping on Windows 41starting with services 42status 405stopping with mkill 42, 417stopping with services 42test, described 37view information 81

CellTickInterval 455class information request 390Class Manager console. See BMC Atrium CMDB Class

Manager consoleclasses

map file sections 476map files 483

CLI, BMC Impact Manager. See BMC Impact Manager CLIclient configuration for passive connections 62client parameters 455

ClientCleanupInterval 447ClientPollTimeOut 447ClientSendTimeOut 447DateFormat 447SynchronizedTimeOut 447

ClientCleanupInterval 447ClientPollTimeOut 447ClientSendTimeOut 447closing an event 438closure policy, creating 288collectors 396

dynamic 365static 364

com.bmc.sms.iwc.component.properties. generalProperties.properties file property 138

com.bmc.sms.iwc.domain.notification.impact.type property 138

com.bmc.sms.iwc.domain.recentitem. RecentItemsFolderIcon property 138

com.bmc.sms.iwc.event.table property 138com.bmc.sms.iwc.event.table.maximumevents property

138com.bmc.sms.iwc.event.table.minimumevents property

138com.bmc.sms.iwc.status. 138com.bmc.sms.iwc.status.table property 138

com.bmc.sms.iwc.status.table. existinggroup property 138com.bmc.sms.iwc.status.table.causes property 138com.bmc.sms.iwc.status.table.consumers property 138com.bmc.sms.iwc.status.table.providers property 138com.bmc.sms.iwc.ui.recentitems.maxsize property 137Command Line Interface (CLI), BMC Impact Manager

described 40command options

mkill 417mrmerge 436

commandsmccomp 385mcell 41, 386mcfgtrace 387, 389mclassinfo 390mcollinfo 396mcontrol 398mcrtcell 401mcstat 405mdelcell 406mgetinfo 408mgetrec 412mkb 414mkill 41, 42, 417mlogchk 418mpkill 420mposter 422, 425mquery 422, 437mrecover 432mrextract 434mrmerge 436msend 422, 437msetmsg 437msetrec 439net start 42net stop 42reference 382

comments, configuration file 198common parameters 200

defined 199definitions 199

communication and encryptionAllowAdapterFrom 449AllowBrowserFrom 449AllowCellFrom 449AllowCLIFrom 449AllowConnectionFrom 449AllowEIFFrom 450BMC Impact Portal configuration parameters 139encryption behavior 65ForceEncryption 65mcell.conf settings 64mcell.dir settings 65mclient.conf settings 65

compilingKnowledge Base 385

Index 557


conditionsfor map files 480

configuration activities for administratorsmodifying cell connection settings 136

configuration filescell 69cell-specific, creating 46comments 198definitions 198ix.properties 150ixs.properties 128MAP file 473mcell.conf 41, 44, 47mcell.modify 63–64mcell.propagate 59mcell.trace 73parameters 198sections 198StateBuilder configuration 225structure 196

configuration parametersBMC Impact Portal configuration and encryption 139HeartbeatEnabled 452HeartbeatInterval 452HeartbeatMissedCritical 452HeartbeatMissedMinor 452HeartbeatMissedWarning 452

configuringBIX using the ix.properties file 150BMC Impact Portal using ixs.properties 128clients for passive connections 62error tracing for BMC Impact Manager 387, 389reloading cell configuration 69setting cell-specific configurations up 46StateBuilder 225TCP Server adapter 494telnet adapter 497UDP Client adapter 500UDP Server adapter 503

connectingcells in a protected zone 62

ConnectionPortRange 441, 445ConnectionPortReuse 441, 445consistency checks 418console

dynamic data 252exporting data 256Slot Quick Filter 248sort data fields 251sort, single-click 252

console_policy.prop 147consumer relationship, described 241control operations 398conventions

for cell naming 401correlation policy, creating 291


creatinga new cell 401a new service with mcrtcell 404another service 404configuration files

cell-specific 46csv parser

description 507customer support 3

Ddata

creating new instance 253dynamic 252exporting 256importing 272sorting 251

Data instance menu 253DATASTORE_HOME environment variable 466, 467DateFormat 447default adapters configuration file 196DEFAULT map file sections 476, 483default, map files 474DEFINE, map file directive 486definitions, configuration file 198deleting

a cell 406, 407events using mquery 432

diagnosticsTCP client adapter 493TCP Server adapter 495telnet adapter 500UDP Client adapter 502UDP Server adapter 504

diagramevent management process flow 242service impact management process flow 242

digital test certificate 220digitally signing .jar files 220dynamic blackout policy, enabling 333dynamic collectors 365dynamic data 252

model 453dynamic data enrichment policies

blackout 333creating new 321

dynamic enrichment policy, creating 336

EECF (event condition formula) 267edit menu 255EM cell

functions of 36


EM cell (continued)production 37test 37

enablingpersistent buffering 425

encryptionbehavior 65mcell.conf settings 64mcell.dir settings 65mclient.conf settings 65

encryption key 65Engine parameter

adapter type, specified by 197enrichment policy, creating 294environment variables

BMC_PORTAL_KIT_HOME 466, 467DATASTORE_HOME 466, 467for UNIX 467for Windows 466MCELL_HOME 466, 467recreating on UNIX 467recreating on Windows 466

error filemcell.err 79

escalation policy, creating 297, 298establishing inbound connection in protected environment

62evaluation order of policies 269event

sources 238event adapter

described 238event collectors

described 360event condition formula 267event group

configuration files 152event groups

described 360granting access 371

event managementcell functions 36overview 237policies, described 260process flow diagram 242

event management policiesclosure 288correlation 291enabling and disabling 320escalation 297notification 302propagation 306recurrence 308standard blackout 285suppression 311threshold 313timeout 317

event parametersEventAutoClose 450EventDBCleanupDurationLimit 450EventDBCleanupInterval 450EventDBCleanuponDateReception 450EventDBCleanupPercentage 450EventDBCleanupPreferClosed 451EventDBKeepClosed 451EventDBKeepNonClosed 451EventDBNoCleanupClosed 451EventDBNoCleanupNoCleanupNonClosed 451EventDBSize 451repository cleanup 450

event policycompiling 270defined 261evaluation order 269types of 262

event processor (cell), described 36event propagation

enabling 61illustrated 61

event repositorycleanup parameters 450described 40

event selectorsdefined 266, 281groups 266

EventAutoClose 450EventDBCleanupDurationLimit 450EventDBCleanupInterval 450EventDBCleanupOnDateReception 450EventDBCleanupPercentage 450EventDBCleanupPreferClosed 451EventDBKeepClosed 451EventDBKeepNonClosed 451EventDBNoCleanupClosed 451EventDBNoCleanupNonClosed 451EventDBSize 451events

deleting using mquery 432exporting to a flat file 231merging objects 436modifying 437posting with mposter 422propagating using a gateway 59

Events View (BIX) navigation trees 239events, sorting 251examples

mccomp 386mcell 387mcfgtrace 390mclassinfo 393mcollinfo 397mcontrol 400mcrtcell 404mcstat 406

Index 559


examples (continued)mdelcell 407mgetinfo config 410mgetinfo connect 412mgetinfo param 411mgetinfo services 411mgetrec command 413mkb 416mkill 418, 421mlogchk 419mquery 431, 432mrecover 434mrextract 435mrmerge 436msetmsg 438msetrec 439

ExportConfigFileName 225ExportDiscarded 225exporting

event data from mcdb by StateBuilder 225events to a flat file 231

exporting data 256ExportTriggerArguments 225ExportTriggerProgram 225external data sources 270

Ffiles

application.properties 129gateway.export 224, 231, 232ixs.properties 128kb_core_resource.properties 214kb_deprecated_resource.properties 215manifest.kb 385mcdb state 224mcell.conf 41, 47mcell.dir 47–50, 383mcell.err error 79mcell.modify 63, 128mcell.propagate 59mcell.trace 73mcfgtrace 387, 389propagation configuration 59statbld.conf 224, 231statbld.exe 224statbld.trace 224, 233StateBuilder configuration 225trace configuration 73xact transaction 224

filtersusing hidden slots 147

fixed-width parserdescription 509

ForceEncryption 65foreground, running cell in 387


functionsmap files, slots 479

Ggateway 59gateway configuration 226gateway.export file 224, 231, 232global parameters 200

adapters 197list of 200

global recordsobtain a value 412setting a value 439

goal line (reports) configuration parameters 139

HHeartbeatEnabled parameter 452HeartbeatInterval parameter 452HeartbeatMissedCritical parameter 452HeartbeatMissedMinor parameter 452HeartbeatMissedWarning parameter 452heartbeats, cell 455home directory, defining 145

Iicons

BMC Impact Explorer configuration files for event groups 152

image viewsoverview 128

image views, defined 363importing data 272infrastructure management

Admin cell 185Administer subtabs 172audit log 179, 181, 184default service model 156, 158Details subtabs 169editing infrastructure relationships 173GUI view 160, 166high availability cells 177icons 166Impact Administration cell 185Impact Administration server 186manually deleting components 186navigation tree 159, 168permissions 157registered components 157, 180, 186related components 171remote actions 164, 166, 177, 187remote systems 161roles 157


infrastructure management (continued)run states 187specifying support files 183support files 162, 182, 184

INIT 482map file sections 476section, map file 482

INPUT_VARIABLES, map file sections 475, 476integration

described 238IP adapters

architecture 490list of types 491overview 489TCP client adapter description 491TCP Server adapter description 494telnet adapter description 496UDP Client adapter description 500UDP Server adapter description 503

ix.properties filedefining presentation name search order for BIX 217entry format 216property descriptions 150

ixs.properties fileparameters 141using to customize BMC Impact Portal 128

Jjar files, digitally signing 220Java Web Start application

extracting presentation name resource files 215

Kkb_core_resource.properties file

entry format 218modifying 219

kb_deprecated_resource.properties file 215KBDirName 455KBDirName parameter 455KBRecoveryDirName parameter 455keys

creating and modifying presentation names 218formats for presentation names 218

Knowledge Basescompiling 385components of 39described 39EM, components of 39KBDirName 455parameters

KBRecovery 455SIM. components of 39updating 414

LLocation.cfg 272LogFile Adapter, parsing 505

Mmanifest.kb file 385map files

Class structure 483conditions 480configuration file 473default 474directives

DEFINE 486REQUIRE 486

INIT 476operators 481personalized 474REQUIRE directive 486sections

CLASS 476DEFAULT 476, 483INIT 482INPUT_VARIABLES 475, 476

slotsassignments 478functions 479

structure 475mccomp command 385

example 386options 385return codes 386syntax 385

mcdb state file 224affects on recovery process 433

mcell command 41, 386example 387options 387return codes 388syntax 386

mcell.conf fileparameter rules 44path substitution parameters 45specifying paths 45

mcell.dir file 383configuring clients for passive connections 62description and usage 47–50example file 48format of entries 47keywords for entries 48rules applied to entries 48ways to update 49

mcell.err file 79mcell.modify file 63, 63–64, 128

Index 561


mcell.propagate file 59default options 60usage 59

mcell.trace file 73, 387, 389MCELL_HOME environment variable 466, 467mcfgtrace command 387, 389

example 390options 389parameters 389syntax 389

mclassinfo command 390adding slot flags and default values 395adding slot names and representation types 394examples 393obtaining a list of classes 393obtaining a list of slot names 394options 391output 391return codes 395syntax 391

mcollinfo command 396example 397options 396output 396return codes 398syntax 396

mcontrol command 398commands

mcontrol 399examples 400options 399reconfiguring a cell 401retrying pending propagations 400syntax 398terminating a cell 400

mcrtcell command 401actions 402creating a service 404creating another service 404examples 404options 403return codes 405syntax 403

mcstat command 405example 406options 405return codes 406

mdelcell command 406deleting a cell 407example 407options 407return codes 408syntax 407

menu, editing 255menu, Reload 82merging event objects 436


message buffer parametersMessageBufferKeepSent 457, 458MessageBufferKeepWait 457, 458MessageBufferReconnectIntervalparameters

MessageBufferReconnectInterval 457, 459MessageBufferResendCount 457, 459MessageBufferSize 456, 458, 459

MessageBufferKeepSent 457, 458MessageBufferKeepWait 457, 458MessageBufferReconnectInterval 457, 459MessageBufferResendCount 457, 459MessageBufferSize 456, 458, 459MetaCollector, event

described 361metrics collection, tab for 87mgetinfo command 408

config example 410connect example 412options 408param example 411return codes 412services example 411syntax 408

mgetrec command 412example 413options 413return codes 414syntax 413

mkb command 414examples 416options 414return codes 417syntax 414

mkill command 41, 42, 417command options 417examples 418, 421options 418, 421return codes 418, 422syntax 417, 420

mlogchk command 418examples 419return codes 420syntax 419

modifyingcell connection settings 136

monitoring passive connections 63mpkill command 420mposter command 422, 425

buffering 426enabling persistent buffering 425options 423return codes 427syntax 422, 423

mposter processesstopping 420

mquery command 422, 437deleting events 432


mquery command (continued)examples 431, 432options 428output 428return codes 432selecting events with a severity level 431syntax 427

mrecover command 432example 434options 433return codes 434syntax 433

mrextract command 434example 435options 435return codes 435syntax 435

mrmerge command 436command options 436example 436options 436return codes 437syntax 436

msend command 422, 437msend processes

stopping 420msetmsg command 437

closing an event 438examples 438options 437return codes 438syntax 437

msetrec command 439example 439options 439return codes 440syntax 439

Nname keys

creating and modifying 218naming conventions

for cells 401new data instance, creating 253notification policy, creating 302, 303

Oobjects

list of presentation names for 214obtaining a global record value 412obtaining a list of classes 393obtaining a list of slot names 394obtaining status of cell using mcstat 406

operators, map files 481options

mccomp 385mcell 387mcfgtrace 389mclassinfo command 391mcollinfo 396mcontrol 399mcrtcell 403mcstat 405mdelcell 407mgetinfo 408mgetrec 413mkb 414mkill 418, 421mposter 423mquery 428mrecover 433mrextract 435mrmerge 436msetmsg 437msetrec 439

outputmclassinfo 391mcollinfo 396mquery command 428

overview, IP adapters 489

Pparameter types

common 199global 199specific 199

parametersActionResultInlineLimit 444ActionResultKeepPeriod 444BMC Impact Portal configuration 128client 455common

definitions of 199configuration file 198definitions of common 199destination Cell name 198HeartbeatEnabled 452HeartbeatInveral 452HeartbeatMissedCritical 452HeartbeatMissedMinor 452HeartbeatMissedWarning 452KBRecovery 455list of 200mcfgtrace 389Server 455specific

Logfile, characteristics 205Logfile, list of 205

Index 563


parameters (continued)specific (continued)

SNMP Trap, characteristics 209SNMP Trap, list of 209

state 455trace, list of 461tracing, configuring 77

parserscsv parser 507fixed-width parser 509separator parser 514

passive connections 62client configuration 62monitoring 63

passwordsinvalid, logging on to BMC Portal 126

pending progagationsretrying 400

permissionsconsiderations for root user 40

persistent buffering, mposter command 426personalized map files 474PMEP files 272policies

Blackout 285, 320Closure 288compilation 270Correlation 291creating new dynamic data enrichment 321defined 261dynamic data enrichment blackout 333Dynamic Enrichment 336enabling dynamic data enrichment dynamic data

enrichment policiesenabling out-of-the-box 332

enabling standard out-of-the-box 320Enrichment 294Escalation 297evaluation order 269new closure 288new correlation 291new escalation 297new notification 302new propagation 306new recurrence 308new standard blackout 285new suppression 311new threshold 313new timeout 317Notification 302Propagation 306Recurrence 308Suppression 311Threshold 313Timeout 317

policy fileBMC Impact Portal 147


policy file (continued)console_policy.prop 147

policy type, user-definedcreating presentation names for 356creating processing rules for 357creating, task overview 354defining policy data class for 354

posting events to a cell 422presentation names

about 214creating a new resource file 216creating and modifying name keys 218default definitions 215defining 218defining for a new policy type 356enabling and disabling BIX tool tips for 221extracting resource files for BIX (Java Web Start) 215files 217key formats 218list of objects with 214resource file locations 214resource file search order 217

ProcessingLimitPercentage 46, 445product support 3production cells

described 37PropagateBufferSize 457, 459PropagateConfigFileName 458propagating

events using a gateway 59propagation configuration file, mcell propagate 59propagation parameters

PropagateBufferSize 457, 459PropagateConfigFileName 458

propagation policy, creating 306protected environments

client configuration for passive connections 62monitoring passive connections 63

protected zone, connecting cells in 62provider relationship, described 241

Rreconfiguring

cell files for 69cells with mcontrol command 401

recreating environment variableson UNIX 467on Windows 466

recurrence policy, creating 308, 309Reload menu (BIX)

Administration View (BIX) 82remote cell administration (BIX), control cell 81reports

BMC Impact Portal goal line configuration parameters 139


REQUIRE directive, map files 486REQUIRE, map file directive 486resource files

creating 216extracting for BIX (Java Web Start) 215locations of 214search order 217

retrieve objects from cell 422, 437retrying pending progagations 400return codes

mccomp 386mcell 388mclassinfo 395mcollinfo 398mcrtcell 405mcstat 406mdelcell 408mgetinfo 412mgetrec 414mkb 417mkill 418, 422mlogchk 420mposter 427mquery 432mrecover 434mrextract 435mrmerge 437msetmsg 438msetrec 440statbld 225

root permissionsconsiderations 40

rule phases 269RuleLoopDetect 455

Ssaved state 433scripts

setup_env.bat 466setup_env.csh 467setup_env.sh 467

sections, configuration file 198selecting

events with a severity level 431separator parser

description 514server parameters 455

CellErrorEvents 455CellEventEnable 455CellMetricstEnabled 455CellTickInterval 455ConnectionPortRange 441, 445ConnectionPortReuse 441, 445ProcessingLimitPercentage 46, 445RuleLoopDetect 455

server parameters (continued)ServerDirectoryName 445ServerPort 445

ServerAllInterfaces 445ServerDirectoryName 445ServerPort 445service impact management

cell functions 37how it works 241process flow diagram 242

service model developmentdescribed 241

ServiceContact.cfg 273services

starting cells with 42stopping cells with 41

settinga value in a global record 439cell-specific configuration up 46

setup_env.bat script 466setup_env.csh script 467setup_env.sh script 467SIM cell

functions 37production 37test 37

Slot Quick Filter 248slots

assignments, map files 478functions, map files 479

sorting 251, 252source event 238specific parameters 200starting cells

specific cell 386UNIX platforms 40, 41using mcell 40Windows 41with net start 42with services 42

statbld return codes 225statbld.conf file 224, 231statbld.exe file 224statbld.trace file 224, 233state configuration parameters 455

ExportConfigFileName 225ExportDiscarded 225ExportTriggerArguments 225ExportTriggerProgram 225StateHistoryCount 225

state files, extracting 434state parameters 455

StateBuildAtTerminate 460StateBuildConfigFileName 460StateBuildInterval 460StateBuildRunTimeOut 460StateBuildSize 460

Index 565


StateBuildAtTerminate 460StateBuildConfigFileName 460StateBuilder 224, 460

configuration parameters for event data export 225StateBuildInterval 460StateBuildRunTimeOut 460StateBuildSize 460StateHistoryCount 225static collectors 364stopping cells

on Windows 41UNIX platforms 41using the mkill command 42with mkill 40, 417with net stop 42with services 42

stopping msend and mposter processes 420structure, map files 475subcollector node 363support, customer 3suppression policy, creating 311SynchronizedTimeOut 447syntax

mccomp 385mcell 386mcfgtrace 389mclassinfo 391mcollinfo 396mcontrol 398mcrtcell 403mdelcell 407mgetinfo 408mgetrec 413mkb 414mkill 417, 420mlogchk 419mposter 422, 423mquery 427mrecover 433mrextract 435mrmerge 436msetmsg 437msetrec 439

SystemLogDirName parameterdescribed 445used to specify log and trace file directories 41

SystemTmpDirName parameterdescribed 445used to specify trace and log file directories 41

TTCP client adapter

description 491diagnostics 493


TCP Server adapterdescription 494diagnostics 495

TCP server Adapterconfiguration parameters 494

technical support 3telnet adapter

configuration parameters 497description 496diagnostics 500

terminating a cell 400test cells

described 37test certificate, digital 220TextTranslation.cfg 273threshold policy, creating 313, 314Timeframe Edit dialog 275timeframes

creating 274Timeframes window 274timeout policy, creating 317tool tips

BIX, enabling and disabling 221toolbar

in dynamic data editor 248trace configuration file 73

configuring 73parameters 74

Trace parameter 461trace parameters

list of 461trace, disable encryption to 66TraceConfigFileName parameter 461TraceDefaultFileName parameter 461TraceFileAppend parameter 463TraceFileHistory parameter 463TraceFileSize parameter 463TraceRuleLevel parameter 461TraceRuleToXact parameter 462TraceSrc parameter 461tracing parameters

configuring 77Trace 461TraceConfigFileName 461TraceDefaultFileName 461TraceFileAppend 463TraceFileHistory 463TraceFileSize 463TraceRuleLevel 461TraceRuleToXact 462TraceSrc 461


UUDP Client adapter

configuration parameters 500description 500diagnostics 502

UDP Server adapterconfiguration parameters 503diagnostics 504

UNIXpermissions required to start cells 41root user permissions 40starting cells 40, 41stopping cells 41

UNIX platformsenvironment variables 467

updating the Knowledge Base 414

Wwidgets, defined 363Windows

starting a cell with services 42starting cells 41starting cells with net start 42stopping a cell with mkill command 42stopping a cell with services 42stopping cells 41stopping cells with net stop 42stopping with mkill 42

Windows platformsenvironment variables 466

Xxact transaction file 224

Index 567

*83747**83747**83747**83747*

*83747*