PATROL Knowledge Module For Event Management User Guide - 2.7

PATROL® KM ® for Event
Management
User Guide
Supporting
PATROL KM for Event Management 2.7
PATROL Configuration Manager 1.6
January 2005
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 INC Telephone 713 918 8800 or Fax 713 918 8000
2101 CITYWEST BLVD 800 841 2031
HOUSTON TX 77042-2827
USA
Outside United States and Canada
Telephone (01) 713 918 8800 Fax (01) 713 918 8000
Copyright March 8, 2005 BMC Software, Inc., as an unpublished work. All rights reserved.
BMC Software, the BMC Software logos, and all other BMC Software product or service names are registered trademarks
or trademarks of BMC Software, Inc.
IBM is a registered trademark of International Business Machines Corporation.
DB2 is a registered trademark of International Business Machines Corporation.
Oracle is a registered trademark, and the Oracle product names are registered trademarks or trademarks of Oracle
Corporation.
All other trademarks belong to their respective companies.
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 legend

U.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.
Customer support
You can obtain technical support by using the Support page on the BMC Software website or by contacting Customer
Support by telephone or e-mail. To expedite your inquiry, please see “Before Contacting BMC Software.”
Support website
You can obtain technical support from BMC Software 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 Software offers
■ find the most current information about BMC Software products
■ search a database for problems similar to yours and possible solutions
■ order or download product documentation
■ report a problem or ask a question
■ subscribe to receive e-mail notices when new product versions are released
■ find worldwide BMC Software 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 support@bmc.com. Outside the United States and Canada, contact your local support center for
assistance.
Before contacting BMC Software

Before you contact BMC Software, have the following information available so that Customer Support can begin working
on your problem 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 problem
■ 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
PATROL® KM ® for Event Management 3

4 PATROL Knowledge Module for Event Management User Guide
Contents
Chapter 1 Product Components and Capabilities 15
Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Typical Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Notification Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Rules Stored as Pconfig Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Notification Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Sending Notification: Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Sending Alerts to an Enterprise Console: Process Flow . . . . . . . . . . . . . . . . . . . . . 20
Sending Pages using AlarmPoint: Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Using the PATROL Configuration Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
PATROL Configuration Manager Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Tasks that Must be Completed Using PATROL KM for Event Management . . . 22
Application Classes and Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Application Class Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Application InfoBox Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Chapter 2 Installing and Migrating PATROL KM for Event Management 25

Installation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Virtual Machine Support Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Preparing for Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Backing up the Notification Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Checking for Product Patches or Fixes Before Installing. . . . . . . . . . . . . . . . . . . . . 30
Determining How to Install Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Installation Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Determining Where to Install the PATROL Agent. . . . . . . . . . . . . . . . . . . . . . . . . . 32
Determining Where to Install KMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
PATROL Security Levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Checking Security Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Assessing and Implementing a Different Security Level . . . . . . . . . . . . . . . . . . . . 34
Typical and Custom Installation Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Installing into a PATROL 3.3.x or 3.4.x Unix Environment . . . . . . . . . . . . . . . . . . 36
First-Time Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Installing For the First Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Installing on AS/400 (iSeries) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Upgrading from an Earlier Version. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5
Remove Customized KM Files From the PATROL_CACHE . . . . . . . . . . . . . . . . . 43
Remove Existing Menu Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Considerations for Using Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Browser Version Required for Viewing PATROL Console for Unix Help . . . . . . 44
Additional Considerations for Using Online Help for Unix . . . . . . . . . . . . . . . . . . 44
Uninstalling PATROL KM for Event Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Determining the Version of the Installation Utility . . . . . . . . . . . . . . . . . . . . . . . . . 47
Uninstalling PATROL KM for Event Management on Windows . . . . . . . . . . . . . 47
Chapter 3 Using the PATROL KM for Event Management 49

Preparing to Use the PATROL KM for Event Management . . . . . . . . . . . . . . . . . . . . . 51
Loading and Preloading KMs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Determining Which KMs to Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
KM Files Preloaded on Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Loading and Unloading KMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Loading Knowledge Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Verifying that PATROL KM for Event Management KM is Loaded . . . . . . . . . . . 55
Unloading Knowledge Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Configuration Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Defining Notification Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Defining Notification Targets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Defining Availability Monitors and Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Deciding Where to Place Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Configuring Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Recommended Configuration Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Using Notification Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Testing Notification Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Configuring Notification Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Configuring Remote Agents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Configuring Alert Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Rewording Notification Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Setting Notification Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Testing Notification Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Disabling Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Configuring Availability Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Configuring an Availability Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Configuring a Backup Availability Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Configuring the Availability Monitor Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Specifying an Availability Monitoring Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Changing the Ping Command Used for Availability Monitoring . . . . . . . . . . . . . 93
Integrating with AlarmPoint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
AlarmPoint Benefits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Notification Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Installing and Configuring AlarmPoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Installing the AlarmPoint Java Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Configuring the AlarmPoint Java Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Testing the Java Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Using Action Scripts for AlarmPoint 5.2.01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Configuring Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Testing Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Managing Parameter Thresholds and Poll Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Benefits of Using the PATROL KM for Event Management. . . . . . . . . . . . . . . . . 104
Setting Collector Poll times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Using Wildcards to Represent PATROL Instance Names. . . . . . . . . . . . . . . . . . . 107
Activating and Deactivating Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Applying Thresholds and Poll Time Changes to the Agent . . . . . . . . . . . . . . . . . 111
Disabling the use of PATROL KM for Event Management Thresholds and Poll
Times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Specifying What to Monitor or Exclude from Monitoring . . . . . . . . . . . . . . . . . . . . . 112
Selecting Application Instances to Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Excluding Application Instances from Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 114
Configuring Blackout Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
About Notification Blackout Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Configuring Notification Blackouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Configuring Availability Blackouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Configuring Recovery Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
About Recovery Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Enabling PATROL KM for Event Management Recovery Actions . . . . . . . . . . . 121
Specifying a Recovery Action Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Specifying a Recovery Action Command Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Using PSL Recovery Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Chapter 4 Usage Scenarios 127

Sending E-mail Notification When Disk Space is Low . . . . . . . . . . . . . . . . . . . . . . . . 128
Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Selecting a Mail Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Loading the PATROL KM for Event Management . . . . . . . . . . . . . . . . . . . . . . . . 130
Defining the Notification Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Configuring the Remote Agent NT1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Specifying an E-mail Target for Low Disk Space . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Rewording the Notification Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Sending E-mail Notification for CPU Usage that Includes Parameter Annotations 140
Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Overview of Annotated Data Points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Enabling Recovery Actions and Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Creating Recovery Action Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Creating Notification Command Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Configuring a Recovery Action that Runs Under a Specified Account . . . . . . . . . . . 144
Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Testing Recovery Action Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Enabling Recovery Actions for ArchFreeSpace on Agent Computer . . . . . . . . . 146
Defining the Recovery Action Type for Agent Computer . . . . . . . . . . . . . . . . . . 146
7
Storing the Encrypted Password as a Pconfig Variable . . . . . . . . . . . . . . . . . . . . . 147
Configuring the PSL Recovery Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Summary of Rules Created. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Testing the Recovery Action. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Chapter 5 Rules and Configuration Variables 151

PATROL Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Example: PATROL Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Example: Rule Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Example: PATROL KM for Event Management E-mail Rule . . . . . . . . . . . . . . . . 154
NOTIFY_EVENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
How the NOTIFY_EVENT and REMOTE_NOTIFY_EVENT are Triggered . . . 156
Event Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Order of Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Empty Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Using the Variable userdefined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Event Size Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
NOTIFY_EVENT Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Alert Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
arsAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
alertSystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
allowOverrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
loginDeniedIgnoredUsers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
useEnvOnlyForCmds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
allowInfoRecoveryActions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
spoolDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
setParameterValue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Local Alert Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
alertResend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
alertLocalCommand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
arsCommand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
arsCmdType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
alertResetOnInit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Remote Alert Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
NOTIFICATION_SERVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
RemoteAgentCommSettings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Notification Target Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
emailTargets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
pagerTargets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
customTargets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
ttTargets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Blackout Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
blackoutPeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
__OVERRIDE__ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Notification Server Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
nsRemoteTargetSetting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Custom Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
msgText . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
msgBody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

CustomId1 and CustomId2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
allowOperator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
appClassSettingsStatusFlag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
disableNotifyAnnotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
maxEventsToReport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
snmpSettings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
snmpOid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Updated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Primary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Blackout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
pingCmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
pingOkString . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
pingPacketSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
pingAttempts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
pingArgs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
checkerAccount.defaultAccount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Parameter Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
THRESHOLDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
paramSettingsStatusFlag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
processWildcards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Instance Filtering Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
FilterList Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
FilterType Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Chapter 6 Parameters 191

Parameter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Parameter Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Chapter 7 Troubleshooting PATROL KM for Event Management 197

Configuration Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Cannot Send E-mail Notifications to Multiple Targets . . . . . . . . . . . . . . . . . . . . . 198
Parameters are Unavailable or are Not Being Updated. . . . . . . . . . . . . . . . . . . . . 200
Too Many E-mail Alerts Are Being Generated . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Parameters Show a Negative Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Parameter Annotations Show Incorrect Targets or Other Errors . . . . . . . . . . . . . 203
AgentLoginDenied Parameter is in Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
The Availability Monitor is Not Pinging Frequently Enough . . . . . . . . . . . . . . . 205
NOTIFY_EVENTS not Generated when Parameter is in Alarm . . . . . . . . . . . . . 205
Parameters Setting Lost After Agent Restart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Notification Message not Sent from OpenVMS Server . . . . . . . . . . . . . . . . . . . . . 207
AS_AVAILABILITY Application Not Displayed . . . . . . . . . . . . . . . . . . . . . . . . . . 207
When Using event_trigger2() Statements, Notifications Sent to Wrong Target 207
Gathering Diagnostic Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Where to Find Diagnostic Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
9
Installation Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Determining PATROL KM for Event Management Version Number. . . . . . . . . 209
Appendix A Accessing Menu Commands, InfoBoxes, and Online Help 211

Accessing KM Commands and InfoBoxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Accessing Online Help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Index 215

Figures
Typical PATROL KM for Event Management Architecture . . . . . . . . . . . . . . . . . . . . . 17
Select Products and Components to Install - Typical Install . . . . . . . . . . . . . . . . . . . . 39
Quick Config - Notification Server Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Notification Server Settings Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Primary Notification Server Settings Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Selecting / to Represent all PATROL Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Set Event Management Alert Variables/Rules Dialog Box . . . . . . . . . . . . . . . . . . . . . 81
Selecting Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Selecting Application Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Selecting Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Set Event Management Alert Variables/Rules Dialog Box . . . . . . . . . . . . . . . . . . . . . 83
What If Results Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Availability Monitor Add Target Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Choose Primary Monitor Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Rules to Apply to the Availability Checker Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Java Client Status Displayed in Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
SET EVENT MANAGEMENT VARIABLE:arsAction Dialog Box . . . . . . . . . . . . . . 101
SET EVENT MANAGEMENT ALERT VARIABLES/RULES Dialog Box . . . . . . . . 102
Configure Thresholds Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Choose the target classes Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Set Event Management Blackout Variables/Rules Dialog Box . . . . . . . . . . . . . . . . . 117
Set Event Management Blackout Variables/Rules Dialog Box . . . . . . . . . . . . . . . . . 119
Availability Monitor Add Target Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Network Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
QUICK CONFIG - NOTIFICATION SERVER Dialog Box . . . . . . . . . . . . . . . . . . . . . 131
NOTIFICATION SERVER SETTINGS Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
EVENT MANAGEMENT ALERT VARIABLE:emailTargetsRemoteALARM Dialog
Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Message Rewording Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
SET EVENT MANAGEMENT VARIABLE: alertLocalCommand dialog box . . . . . 200
11
Tables
E-mail Notification Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Sending Alerts to Enterprise Console Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Sending Pages using AlarmPoint Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Application Classes and KM File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
AS_EVENTSPRING InfoBox Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
AS_AVAILABILITY InfoBox Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
System Requirements for Installing and Using PATROL KM for Event Management
26
System Role Packages Available for Product Components . . . . . . . . . . . . . . . . . . . . . 38
EVENT_MANAGEMENT.kml File and Associated KM Files) . . . . . . . . . . . . . . . . . . 53
Notification Target Configuration Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Recommended Rule Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Recommended Configuration Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Notification Script Location on Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Requirements for Using Scripts on Unix Notification Server . . . . . . . . . . . . . . . . . . . . 65
Notification Script Location on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Requirements for Notification Server When Using Windows e-mail Clients . . . . . . 66
Editing Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Notification Script Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Quick Config - Notification Server Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Notification Server Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
REMOTE AGENT COMMUNICATION SETTINGS dialog box . . . . . . . . . . . . . . . . . 79
Message Length Limitations by Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Availability Target Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Threshold Setting Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Wildcard Usage in Threshold Rules: Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Blackout Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
PATROL KM for Event Management Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Sending E-mail Notification for Low Disk Space: Configuration Overview . . . . . . 129
Sending E-mail Notification for Low Disk Space: Configuration Overview . . . . . . 145
Rules Created: Oracle Recovery Action Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
PATROL Objects Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Example: PATROL Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Example: Rule Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
PATROL KM for Event Management Variable Definition . . . . . . . . . . . . . . . . . . . . . 155
NOTIFY_EVENT Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Notification Server Message Replacement Variables . . . . . . . . . . . . . . . . . . . . . . . . . 160
Notification Server Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
arsAction Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
alertSystem Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
13
Notification System Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
allowOverrides Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
LoginDeniedIgnoredUsers Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
useEnvOnlyForCmds Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
useEnvOnlyForCmds Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
SpoolDirectory Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
SetParameterValue Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
alertResend Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
alertLocalCommand Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
arsCommand Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
arsCmdType Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
alertResetOnInit Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Remote Alert Settings: Configure Notification Servers Configuration Variable . . . 170
Remote Alert Settings: Configure Notification Servers Configuration Variable . . . 170
Remote Alert Settings: Remote Communication Settings Configuration Variable . 170
Notification Targets: Email Target Configuration Variable . . . . . . . . . . . . . . . . . . . . 172
Notification Targets: Pager Target Configuration Variable . . . . . . . . . . . . . . . . . . . . 172
Notification Targets: Custom Target Configuration Variable . . . . . . . . . . . . . . . . . . 173
Notification Targets: TT Targets Configuration Variable . . . . . . . . . . . . . . . . . . . . . . 173
Blackout Periods Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Overrides Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Notification Server Settings: Remote Target Setting Configuration Variable . . . . . 175
msgText Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
msgBody Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Custom Configuration Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
allowOperator Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
active Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
appClassSettingsStatusFlag Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
disableNotifyAnnotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
disableNotifyAnnotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Add Target Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Add Target: Updated Flag Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Primary Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Blackout Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
PingCmd Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
pingOKString Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
pingPacketSize Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
pingAttempts Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
pingArgs Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Checker Account Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Parameter Settings: Thresholds Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Understanding the THRESHOLDS Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Parameter Settings: poll times Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Parameter Settings: Status Flags Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Parameter Settings: poll times Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Filter List Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Filter Type Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
PATROL KM for Event Management Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
PATROL KM for Event Management Parameter Defaults . . . . . . . . . . . . . . . . . . . . . 194

Chapter
1
Product Components and
1
Capabilities
This chapter provides an overview of the PATROL Knowledge Module for Event
Management (also referred to as PATROL KM for Event Management).
Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Typical Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Notification Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Rules Stored as Pconfig Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Notification Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Sending Notification: Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Sending Alerts to an Enterprise Console: Process Flow . . . . . . . . . . . . . . . . . . . . . 20
Sending Pages using AlarmPoint: Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Using the PATROL Configuration Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
PATROL Configuration Manager Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Tasks that Must be Completed Using PATROL KM for Event Management . . . 22
Application Classes and Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Application Class Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Application InfoBox Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Chapter 1 15
Features
Features
PATROL KM for Event Management provides event notification, message
rewording, and centralized alert management features. With the PATROL KM for
Event Management, you can:
■ configure notification (e-mail, paging, trouble-ticket, or custom) for PATROL alerts
■ configure PATROL to send notifications to an enterprise console
■ configure recovery actions for PATROL alerts
■ reword notification messages and customize message content
■ configure PATROL to monitor the availability of hosts
■ manage PATROL parameter thresholds and polling schedules
■ configure blackout periods for notification and for availability monitoring
■ integrate with any command line e-mail client, paging solution, compiled
executable, or script. Sample scripts are provided.
■ integrate with AlarmPoint enterprise notification software using provided scripts
Architecture
The PATROL KM for Event Management architecture consists of monitored hosts
(remote agents) and notification servers. Notification servers collect and process
events from monitored systems according to notification rules that you define.
Notification rules specify:
■ who gets notified

■ when they get notified
■ the content of the notification message
Both the monitored hosts and the notification servers require a PATROL Agent and
the PATROL KM for Event Management. Figure 1 on page 17 shows an PATROL KM
for Event Management environment with several monitored hosts and two
notifications servers (a primary and a backup).

Architecture
Typical Configuration
In the typical configuration, monitored hosts forward events to a primary notification
server. The backup notification server is used only when the primary notification
server is unavailable. Failover is automatic. If the primary and the backup notification
servers are unavailable, the monitored host queues its events. When communication
is restored, the monitored host forwards queued events to the notification servers.
Figure 1 Typical PATROL KM for Event Management Architecture
Primary Backup
Notification Server 1 Notification Server 2
Agent 1 Agent 2 Agent 3
Notification Servers
BMC Software recommends the use of notification servers. The PATROL KM for
Event Management architecture does not require a notification server to perform
notifications. Any monitored host running the PATROL KM for Event Management
can be configured to perform its own notifications, event filtering, and alert control.
However, there are advantages to using a notification server. For more information,
see “Why use a Notification Server?” on page 58.
Rules Stored as Pconfig Variables

PATROL KM for Event Management rules are stored in pconfig variables, not in the
KM. Pconfig variables override KM settings. Thus, if you upgrade a KM, you don’t
need to reconfigure the rules. The pconfig variable settings are retained.
Chapter 1 17
Notification Process
The following diagrams show how notification occurs in the following configuration:
■ e-mail notification using a notification server

■ alert notification using the PATROL Enterprise Manager (PEM)
■ paging notification using AlarmPoint
The PATROL KM for Event Management rules that apply at each step are shown. For
detailed rule descriptions, see Chapter 5, “Rules and Configuration Variables”.

Sending Notification: Process Flow

Table 1 shows how a notification is processed by the PATROL KM for Event
Management when the notification server sends an e-mail notification. The same
process applies to paging, trouble-ticket, or custom notification.
Table 1 E-mail Notification Process

Step Rule or Variable
1. Alert occurs on remote agent - NA
parameter exceeds threshold and enters
WARN/ALARM state, generating
PATROL standard event 11 or 39.
2. Recovery action initiated (if configured) arsAction
arsCommand
arsCmdType
3. The remote agent triggers a PATROL arsAction
NOTIFY_EVENT (if arsAction = 4 or 6)
4. CustomID values are set (if configured) customId1
customId2
5. Notification message reworded (if msgText
configured) msgBody
6. PATROL determines if a blackout blackoutPeriod
period applies. If so, NOTIFY_EVENT
is not sent to the notification server.
7. The alert is queued. alertResetOnInit
alertResend
8. Determine whether notification is local alertSystem
or remote. If local, notification sent from
remote agent. If remote, notification
sent from notification server.
9. Determine the notification targets. emailTargets
10. Remote agent NotifiedEvent parameter NA
is annotated with alert information.
11. A REMOTE_NOTIFY_EVENT is sent to NA
notification server (if arsAction = 4 or 6)
12. The notification server parses NA
REMOTE_NOTIFY_EVENT event
details, which contains the same
information as the original
NOTIFY_EVENT.
13. Repeat steps 4 through 10 on the Multiple. See steps 4
notification server (except step 7). through 10.
14. The notification server executes the emailTargets
script to send e-mail message to targets. alertLocalCommand
Chapter 1 19
Sending Alerts to an Enterprise Console: Process Flow

Table 2 shows how an alert processed by the PATROL KM for Event Management is
sent to the PATROL Enterprise Manager (PEM). The PATROL KM for Event
Management rules associated with each step are shown.
Table 2 Sending Alerts to Enterprise Console Process

Step Rule
1. Alert occurs on remote agent NA
(parameter exceeds defined
threshold and enters WARN or
ALARM state, generating PATROL
event 11 or 39)
2. Notification processing occurs on arsAction
the remote agent as previously arsCommand
discussed in Table 1 on page 19. msgText
msgBody
The message rewording (msgText) blackoutPeriod
must be done on the remote agent alertResetOnInit
so that when the PATROL Event alertResend
Translator (PET) pulls the event, alertSystem
the event contains the host specific
information.
3. The NOTIFY_EVENT is sent to the NA
notification server.
4. The notification server process the arsAction
REMOTE_NOTIFY_EVENT as arsCommand
previously discussed in Table 1 on blackoutPeriod
page 19. alertSystem
5. PATROL Event Translator (PET) NA

pulls REMOTE_NOTIFY_EVENT
from the notification server
6. The PET processes the NA
REMOTE_NOTIFY_EVENT and
sends it to the PATROL Enterprise
Manager.
You can also send events to

third-party enterprise consoles,
such as Tivoli.
7. The event is received by the NA
PATROL Enterprise Manager.

Sending Pages using AlarmPoint: Process Flow

The following diagram shows how a page is processed by the PATROL KM for Event
Management. This process assumes the use of the enterprise notification software
AlarmPoint. However, you can use any third-party paging software that has a
command-line interface. The PATROL KM for Event Management rules associated
with each step are shown
Table 3 Sending Pages using AlarmPoint Process

Step Rule
1. Alert occurs on remote agent NA
(parameter exceeds defined
threshold and enters WARN or
ALARM state, generating PATROL
standard event 11 or 39)
2. Notification processing occurs on arsAction
the remote agent as previously arsCommand
discussed in Table 1 on page 19. msgText
blackoutPeriod
alertResetOnInit
alertResend
alertSystem
customTargets
3. The NOTIFY_EVENT is sent to the
4. The notification server process the arsAction
REMOTE_NOTIFY_EVENT as arsCommand
previously discussed in Table 1 on blackoutPeriod
page 19. alertSystem
customTargets
5. The notification server executes the
script that calls the AlarmPoint Java
client.
6. The AlarmPoint java client sends
the paging request to the
AlarmPoint server.
7. The AlarmPoint server processes
the paging request and sends the
page request to the paging device.
The paging device could be a
paging server, the internet, or
whatever your enterprise is using
for paging.
8. The paging device sends the page
to the defined target.
Chapter 1 21
Using the PATROL Configuration Manager
Using the PATROL Configuration Manager

The PATROL KM for Event Management is designed to be used with the PATROL
Configuration Manager, which allows you to manage and globally deploy agent
configuration settings.
PATROL Configuration Manager Tasks

You can accomplish many of the tasks described in this manual using either the
PATROL KM for Event Management or the PATROL Configuration Manager. In this
manual, only the PATROL KM for Event Management method is described.
However, for some tasks, the PATROL Configuration Manager method is more
efficient. For example, configuring multiple agents at one time. Rather than configure
each agent individually, you can configure one agent and then use the PATROL
Configuration Manager to copy the agent settings to the other agents. Tasks such as
these that are easier to accomplish with the PATROL Configuration Manager are
denoted by an icon in the margin (shown at left).
Usage Examples
For a brief example of how to use the PATROL Configuration Manager to copy
settings, see “Sending E-mail Notification When Disk Space is Low” on page 128.
For detailed instructions on using PATROL Configuration Manager, see the PATROL
Configuration Manager User Guide.
Tasks that Must be Completed Using PATROL KM for Event

Management
Tasks that you must complete using the PATROL KM for Event Management, and
cannot be completed using the PATROL Configuration Manager, are also noted.
These tasks are listed below.
■ “Configuring Notification Servers” on page 71

■ “Configuring Remote Agents” on page 73
■ “Specifying an Availability Monitoring Account” on page 92

Application Classes and Instances

The PATROL KM for Event Management contains two application classes:
■ AS_EVENTSPRING
■ AS_AVAILABILITY
Table 4 describes the PATROL KM for Event Management application classes, icons
and KM files.
Table 4 Application Classes and KM File

Application Class KM File Description
AS_EVENTSPRING.km menu commands, parameters, and InfoBox
items for managing and reporting on events
managed by the KM
AS_AVAILABILITY.km instances, menu commands, parameters, and

InfoBox items for monitored hosts and agents
Application Class Hierarchy

The AS_EVENTSPRING application class icon resides at the application level beneath
the computer icon. The AS_EVENTSPRING application class has only a single
instance which is Event Management.
The AS_AVAILABILITY icon represents the Availability application class and resides
at the application level beneath the computer icon. All monitored hosts appear
beneath the Availability container and are accessed by double-clicking the
AS_AVAILABILITY icon.
NOTE
The AS_AVAILABILITY application class icon is not displayed in the PATROL
Console until availability targets are added.
Chapter 1 23
Application InfoBox Items

The status of an application instance can be reviewed by accessing the application
instance InfoBox. To view an InfoBox, use the following procedure.
To View the InfoBox on the PATROL Console for Unix

1 Double click the application instance icon under the computer icon.
2 Using the middle mouse button, click the instance icon.
To View the InfoBox on the PATROL Console for Windows

1 Double click the application instance icon under the computer icon.
2 Right-click the instance icon to display a pop-up menu.
3 Choose InfoBox.
Table 5 shows the InfoBox items for the AS_EVENTSPRING application class.
Table 5 AS_EVENTSPRING InfoBox Items

Item Description
KM Version the version of the PATROL KM for Event Management
Spool directory used to store output files generated by parameter reports and
Directory recovery actions executed by the PATROL KM for Event Management
Table 6 shows the InfoBox items for the AS_AVAILABILITY application instances.
Table 6 AS_AVAILABILITY InfoBox Items

Item Description
Primary Monitor agent with primary responsibility for performing availability
monitoring
Ping Command command used to perform ping checks
Ping Host (ICMP)? whether the host is being pinged using the ICMP protocol
Ping whether the PATROL Agent is being monitored for availability
PATROLAgent?
Ping SNMP Agent? whether the SNMP agent is being monitoring for availability
Blacked Out? indicates whether the selected instance is currently being
blacked out
KM Version the version of the PATROL KM for Event Management

Chapter
2
Installing and Migrating PATROL KM
2
for Event Management

This chapter provides the information that you need to install PATROL KM for Event
Management. For additional information about the PATROL installation process, see
the PATROL Installation Reference Manual or the PATROL for Microsoft Windows Servers
Getting Started. The following topics are discussed in this chapter:
Installation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Virtual Machine Support Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Preparing for Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Backing up the Notification Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Checking for Product Patches or Fixes Before Installing. . . . . . . . . . . . . . . . . . . . . 30
Determining How to Install Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Installation Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Determining Where to Install the PATROL Agent. . . . . . . . . . . . . . . . . . . . . . . . . . 32
Determining Where to Install KMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
PATROL Security Levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Checking Security Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Assessing and Implementing a Different Security Level . . . . . . . . . . . . . . . . . . . . 34
Typical and Custom Installation Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Installing into a PATROL 3.3.x or 3.4.x Unix Environment . . . . . . . . . . . . . . . . . . 36
First-Time Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Installing For the First Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Installing on AS/400 (iSeries) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Upgrading from an Earlier Version. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Remove Customized KM Files From the PATROL_CACHE . . . . . . . . . . . . . . . . . 43
Remove Existing Menu Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Considerations for Using Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Browser Version Required for Viewing PATROL Console for Unix Help . . . . . . 44
Additional Considerations for Using Online Help for Unix. . . . . . . . . . . . . . . . . . 44
Uninstalling PATROL KM for Event Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Determining the Version of the Installation Utility . . . . . . . . . . . . . . . . . . . . . . . . . 47
Uninstalling PATROL KM for Event Management on Windows . . . . . . . . . . . . . 47
Chapter 2 25
Installation Overview
This chapter contains instructions for installing PATROL KM for Event Management.
For additional installation instructions, see the following documents:
Information Document
You are installing the PATROL KM for Event ■ PATROL for Microsoft Windows Servers
Management along with many other PATROL Getting Started
components and you need information about ■ PATROL for Unix Getting Started
migrating customizations or using the Distribution ■ PATROL for OpenVMS Installation Guide
Server (DS). ■ PATROL for AS/400 Getting Started
You need more technical details about how to use PATROL Installation Reference Manual
the installation program.
You need more information on distributing the Distribution Server Getting Started Guide
PATROL KM for Event Management or other
PATROL components using the Distribution Server.
System Requirements
Before installing the PATROL KM for Event Management, verify
■ the target computer meets the system requirements noted in Table 7 on page 26,
including supported OS platforms and PATROL product versions.
NOTE
For a current list of the supported operating systems, see the release notes for the
PATROL solution. For example, the PATROL for Microsoft Windows Servers Release
Notes.
■ the account that you use to install the product has sufficient privileges
Table 7 System Requirements for Installing and Using PATROL KM for Event Management
(Part 1 of 2)
Resource Requirements Comments
operating For a current list of the supported operating systems, see the
systems release notes for the PATROL solution. For example, the
PATROL for Microsoft Windows Servers Release Notes.
PATROL For a current list of the supported PATROL products, see
products the release notes for the PATROL solution. For example, the
PATROL for Microsoft Windows Servers Release Notes.

Table 7 System Requirements for Installing and Using PATROL KM for Event Management
(Part 2 of 2)
Resource Requirements Comments
security levels For information on security, see “PATROL Security Levels” On iSeries, only
on page 34. security levels 0 and
1 are supported.
The PATROL Security Level is set during the installation of
the PATROL infrastructure components. If your product
contains the PATROL Agent, you have an opportunity to
select the security level. Make sure that the level that you
select/accept is compatible with the rest of your enterprise’s
PATROL installation.
license You must have a valid demonstration license (typically
good for 30 days) or a permanent license to run your
PATROL products. If you do not have a permanent license,
contact your BMC Software sales representative or the BMC
Software Contract Administration department.
ports If you are installing an agent or console with PATROL KM The default port
for Event Management, you must specify the port number number is 3181 for
to connect to all the agent computers. agents.
(Unix only) Use Netscape Navigator version 3.01–4.78 to use online “Browser Version
browser to Help with PATROL for Unix. Required for
support online Viewing PATROL
Help for Console for Unix
PATROL for Help” on page 44
Unix Console
browser This product uses Common Installer 7.5.20, which requires
a browser. For a list of supported browser, see the PATROL
Installation Reference Manual.
Accounts
This section describes how to set up a PATROL installation account for Windows and
Unix platforms.
Windows Environment
PATROL requires a dedicated user account, known as the PATROL default account,
in the Windows environment. The PATROL default account must be created before
you install PATROL. The PATROL default account can be either a local or a domain
account:
Chapter 2 27
■ Stand-alone workgroup servers must use a local user account as a PATROL default
account.
■ Servers that are trusted members of a domain may use either a local or domain
account.
■ PATROL default accounts on domain controllers should be only domain accounts.
Administrative Rights
BMC Software recommends that you make the PATROL default account a member of
the local Administrators group of the computer where the agent will reside. On a
domain controller, BMC Software recommends that you make the account a member
of the domain Administrators group. However, you can choose to remove the
PATROL default account from the Administrators group. If you do so, the PATROL
Agent may not be able to perform all of its administrative tasks. For example, the
PATROL Agent may not be able to execute recovery actions or perform other
activities that requires administrative rights on the monitored machine.
Creating a Separate Account
Although you can use an existing Windows user account, BMC Software
recommends that you create a separate Windows user account for PATROL.
WARNING
Do not use a built-in Windows domain or local Administrator account as the
PATROL default account. Such account usage causes files created by PATROL to be
owned by the Administrator, which could result in security or file access problems.
Console Connection Accounts

BMC Software recommends that you create a separate account, in addition to the
PATROL default account, for PATROL console operators who don’t need
administrative privileges. Operators can use this account to connect the console to the
agent. To configure KMs from the console, however, you need to give the console
connection account administrative rights.
Unix Environments
BMC Software recommends that if you require a Unix account, the account that you
create should meet the following conditions:

■ The account .login, .profile, .cshrc, and .kshrc files should contain as little user
customization as possible. Specifically, be sure that the account has no aliases and
that no commands in these files can change the unmask setting. The recommended
umask setting for the installation account is 022. In addition, verify that the prompt
is set to the default.
■ Do not use the root account to install PATROL products because this may create
security risks.
■ Ensure that the account has permission to create directories in the directory where
you will install PATROL products.
■ Ensure that the computers on which you want to install PATROL have ftp and
telnet enabled.
PATROL configuration requires permissions usually reserved for the system

administrator. These permissions include access to a root account on the computer
where you want to install PATROL.
BMC Software recommends that you install PATROL on local partitions, not on
NFS-mounted partitions. If you do install PATROL on NFS-mounted partitions, the
root account must have been granted root access permissions on the NFS server.
The account that you use to install PATROL must have permission to write the
installation logs to the $HOME and /tmp directories on the computer where you are
installing products.
Your PATROL product may have other restrictions with regard to the logon accounts
and the default PATROL account. Check with your developers for text that more
fully describes the logon and PATROL account requirements for your product. Many
products require, for example, that the default PATROL account have the same rights
as the third-party product that your KM monitors.
Virtual Machine Support Limitation

VMware provides technology that creates virtual infrastructures by providing a layer
of abstraction between the computing, storage, and networking hardware, and the
software that runs on it. This technology enables customers to run additional
operating systems in multiple windows called virtual machines.
BMC Software does not anticipate problems with the PATROL product families in
virtual infrastructure implementations, but these products have not been specifically
tested in this scenario. Therefore, BMC Software will provide support only for
problems that are reproducible without these complementary technologies.
Chapter 2 29
Preparing for Installation

BMC Software recommends that you first install PATROL KM for Event
Management on a limited number of development or test machines, then configure
and test PATROL KM for Event Management before installing it onto production
machines.
Before you install, you must
■ back up the notification script, if upgrading (see page 30)

■ check for product patches (see page 30)
■ determine how to install products (see page 31)
■ ensure you are using the appropriate version of the installation utility (see page 31)
■ understand where to install the PATROL Agent and KMs (see page 32)
■ choose between Typical and Custom installation options (see page 35)
■ understand PATROL security options (page 34)
Backing up the Notification Script

If you are upgrading, make sure you have copied your notification script to a
directory outside of the installation directory. This action prevents the script from
being overwritten during a new install or upgrade.
Checking for Product Patches or Fixes Before Installing

Product fixes or patches are often available through the BMC Software Web site.
Patches correct problems that are found after a product is released. BMC Software
recommends that you check the PATROL for Microsoft Windows Servers product
page on the BMC Software Customer Support Web site to determine whether a patch
is available before you begin installing a product.

Determining How to Install Products

You can install products on the computer on which you are running the installation
utility (local installation), or you can create an installable image of products so that
you can install them at a later time using the Distribution Server (remote installation
functionality). An installable image is a fully configured product image that you can
use to install products to multiple computers. With an installable image, you can
create one product image with one pass through the installation utility and then use
that image to install to remote computers in your environment.
Local Installation
If you install locally, you must install PATROL KM for Event Management and a
PATROL Agent on each computer that you want to monitor, and PATROL KM for
Event Management and a PATROL Console for Windows or Unix on each computer
from which you want to view results. If you install locally in a PATROL 7.x
environment, you must install PATROL KM for Event Management on the computer
that hosts the PATROL Console Server.
Details for installing products locally are contained in this chapter.
Remote Installation
If you create an installable image, the product configuration information that you
enter, such as the BMC Software products installation directory, account names,
passwords, PATROL Agent port number, and security options, must be the same for
all computers on which the image is to be installed. To specify different settings for
different computers, you must either create a separate image for each set of values
that you want to implement or edit the variables in the image’s control file by using
the ctltool.
For more information about creating, distributing, and installing installable images,
and about using the ctltool, see the PATROL Installation Reference Manual.
Installation Utility
The installation instructions contained in this book pertain to version 7.5.20 of the
installation utility. This version of the installation utility might be different from the
version included on another product CD or from a version that you downloaded
from the BMC Software Electronic Product Download (EPD) site. If you use a version
of the installation utility other than version 7.5.20, the instructions in this book may
not accurately describe what you see on your screen.
Chapter 2 31
Determining Where to Install the PATROL Agent

Install the PATROL Agent on each computer that you want to monitor.
When installing the PATROL Agent, select Managed System as the system role during
the installation.
Determining Where to Install KMs

Where KMs are installed depends on which system roles you have assigned to a
computer and which PATROL infrastructure components are installed on that
computer.
This section explains where KMs must be installed.
PATROL 3.x
In a PATROL 3.x environment, you must install KMs on the following computers:
■ Computers hosting the PATROL Agent—Select Managed Systems as the System

Role in the installation utility when installing KMs. This selection installs KM files
that run on the PATROL Agent.
■ Computers hosting the PATROL Console for Windows or PATROL Console for
Unix—Select Console Systems as the System Role in the installation utility when
installing KMs on computers hosting the PATROL Console for Windows or
PATROL Console for Unix. This selection installs KM files for use by the console.
PATROL 7.x
In a PATROL 7.x environment, you must install KMs on the following computers:
■ Computers hosting the PATROL Console Server—Select Common Services Systems

as the System Role in the installation utility. This selection installs KM icons, Help
files, and resource files used by PATROL Central Operator – Microsoft Windows
Edition and PATROL Central Operator – Web Edition.
NOTE
If you do not install each KM on the computer hosting the PATROL Console Server
and select Common Services Systems as the System Role in the installation utility, no
KM icons or KM Help files will be available in either PATROL Central
Operator – Microsoft Windows Edition or PATROL Central Operator – Web Edition.

■ Computers hosting the PATROL Agent—Select Managed Systems as the System

Role in the installation utility. This selection installs KM files that run on the
PATROL Agent.
When using PATROL Central Operator – Web Edition, install KMs on computers
hosting the PATROL Console Server using the Common Services Systems role and
computers hosting the PATROL Agent using the Managed Systems role.
If you are using older versions of the following components:
■ PATROL Console Server prior to version 7.2.36

■ PATROL Central Operator – Web Edition prior to version 7.1.10
You must also install KMs on the computer hosting the PATROL Central
Operator – Web Edition web server using the Common Services Systems role.
For more information about the PATROL 7.x architecture, see the PATROL
Infrastructure Planning Guide.
Additional Information
For more information about the PATROL consoles and PATROL Console Server or
RTserver, see the product’s respective online help systems and the following
documents:
■ PATROL Central Operator - Web Edition Getting Started

■ PATROL Central Operator - Microsoft Windows Edition Getting Started
■ PATROL Console Server and RTserver Getting Started
■ PATROL Configuration Manager User Guide
■ PATROL Console for Microsoft Windows User Guide - Understanding the Basics of
PATROL, Volume 1
■ PATROL Console for Unix User Guide
Chapter 2 33
PATROL Security Levels
PATROL Security Levels

You can secure the data passed between PATROL components and restrict
unauthorized users from accessing your data by implementing PATROL security.
You can select from five security levels when you install PATROL.
WARNING
The PATROL Agent, console server, and consoles must operate at the same security
level to communicate with each other. When you install agents, console servers, or
consoles that need to communicate with previously installed versions of these
components, check the security level of the previously installed components and be
sure to install the new ones at the same level.
Checking Security Levels

To check the security level of a previously installed agent, console server, or console,
perform the following steps:
1 From the command line switch to the path on the computer that you want to check:
%BMC_ROOT\..\common\security\bin\OS
2 Run the following command to display the security policy of the current machine:
esstool policy -a
The security level is displayed in the “security level” field of the output.
Assessing and Implementing a Different Security Level

Review the security level definitions in the PATROL Security User Guide before
installing PATROL to determine the appropriate security level for your components.
To implement a new security level after having previously installed PATROL
security, see the PATROL Security User Guide for instructions.

Typical and Custom Installation Types

The installation utility may prompt you to select one of the following installation
types:
■ The Typical installation type uses defaults values for all optional configuration
information. It prompts you only for mandatory configuration information. This
type is for any or all of the following situations:
— You are new to the PATROL product that you are installing and you have an
agent or console already installed in the default directories.
— You are performing a first-time installation (you are not upgrading), and you
are installing into the default product installation directories.
NOTE
If you are installing PATROL KM for Event Management to an existing PATROL
Agent or Console environment that is not in the default installation directory, use
Custom. Do not use Typical. Typical will automatically install the agent or console with
PATROL KM for Event Management and overwrite your existing installation.
■ With the Custom installation type, you can install individual components of the
product. It requires that you specify all configuration information. This type is for
any or all of the following situations:
— You want to install individual components rather than the entire product.
— You want to specify
■ the port numbers that components use to communicate with each other
■ a security level greater than basic security
■ any other product settings that a user might want to change
— You are upgrading PATROL KM for Event Management from a previously

installed version.
— You are installing into an existing PATROL environment that is not in the
default installation directory.
The Custom installation type installs the KMs that you select.
With each installation type, you can deselect any components that you don’t want
to install.
NOTE
If you choose the typical installation type, the PATROL KM for Event Management is
automatically installed when you select the operating system KM. For example, if you
select the PATROL KM for Windows Operating System, the PATROL KM for Event
Management is automatically installed.
Chapter 2 35
Installing into a PATROL 3.3.x or 3.4.x Unix Environment

If you are installing PATROL KM for Event Management into a Unix environment
that has PATROL 3.3.x or PATROL 3.4.x installed, you must launch the installation
utility from the command line using the -releaseversion option as described in
“Upgrading from an Earlier Version” on page 43.
If you have a PATROL Agent installed on the computer where you are installing
PATROL KM for Event Management–Preload component, the installation script
designates PATROL KM for Event Management as a preloaded KM in the agent
configuration file. When a KM is designated as a preloaded KM on a PATROL Agent,
it automatically loads and begins to monitor resources and applications whenever the
agent is started.
If you have a PATROL Console installed on the computer where you are installing
the PATROL KM for Event Management–Preload component, the installation script
loads the PATROL KM for Event Management into the console.
For more information about preloading, see the PATROL Agent Reference Manual.

First-Time Installation
The installation utility offers two types of installations: Typical and Custom. For a
description of the two types of installations, see “Typical and Custom Installation
Types” on page 35.
If you are installing on AS/400 (iSeries), see “Installing on AS/400 (iSeries)” on

page 42.
Installing For the First Time

You can install PATROL KM for Event Management using either the Typical or
Custom installation type. Regardless of the type of installation you choose, you must
repeat this installation process for each computer on which you want to install
PATROL KM for Event Management.
NOTE
By default, the Typical installation type configures the PATROL Agent to connect
through port 3181. To connect the agent from a different port, you must use the
Custom installation type.
Before You Begin
■ You first should install on a limited number of computers in the test environment,
test the installation thoroughly, and then install in your production environment.
■ You must have created the PATROL default account.
To Install Using the Typical Installation Type
1 Close the Service Control Manager window and the Control Panel window.
2 From the PATROL for Microsoft Windows Servers CD or from an installation

image that has been electronically downloaded from an EPD site and extracted,
run setup.exe.
3 In the Welcome to the Installation Utility window, click Next to begin your
installation.
4 Review the license agreement, select Accept, and click Next to continue.
Chapter 2 37
5 In the Select Installation Option window, select I want to install products on this
computer now and click Next to continue.
6 In the Select Type of Installation window, select Typical and click Next to continue.
7 In the Specify Installation Directory window, accept the default directory and click
Next to continue.
8 In the Select System Roles window, select any or all of the following roles to
indicate the components that you want to install and click Next:
■ If you are installing to a computer that hosts or will host a (Windows only)
PATROL Console for Window (Unix only) PATROL Console for Unix, select
Console Systems.
■ If you are installing to a computer that hosts or will host a PATROL Agent,
select Managed Systems.
■ If you are installing to a computer that hosts or will host the PATROL Central
Operator – Web Edition (PATROL 7.x architecture) Web server, the PATROL
Console Servers, or the RTservers, select Common Services.
Table 8 System Role Packages Available for Product Components

System Role to Select
Console System Managed Common
Product Component/Selectable Entity PCO-Winb PATROL 3c System Servicesa
PATROL Knowledge Module for Event no yes yes yes
Management
a
PATROL Central Operator – Web Edition. This console is available when you select the common services
role.
b
PATROL Central Operator – Microsoft Windows Edition. This console is available when you select the
console system role.
c
PATROL Console for Windows and PATROL Console for Unix are PATROL 3 console systems. They are
available when you select the console system role.
Fore more information, see “Determining Where to Install the PATROL Agent” on
page 32.

9 From the Select Products and Components to Install window, select components
that you want to install (see Figure 2 on page 39) and click Next.
NOTE
If you choose the typical installation type, the PATROL KM for Event Management is
automatically installed when you select the operating system KM. For example, if you
select the PATROL KM for Windows Operating System, the PATROL KM for Event
Management is automatically installed.
Figure 2 Select Products and Components to Install - Typical Install
NOTE
The actual selectable components may be different that what is shown in Figure 2.
For example, components that you are installing with the PATROL KM for Event
Management will also be shown.
10 In the PATROL Default Account Properties window, enter the user name and
password that you want to use for your PATROL default account and click Next.
You should have created this account manually before you began to install
PATROL. (For more information about the PATROL account, see “Accounts” on
page 27.) This window is displayed only when you are installing a product that
requires a PATROL logon.
11 In the Confirm BMC Product Startup Information window, specify whether to

restart the PATROL Agent after installation. This window is displayed only if you
are installing to a PATROL Agent system.
Chapter 2 39
12 In the Review Selections and Install window, review the selections carefully to
ensure that they are correct:
■ To change your selections, click Back and make those changes.

■ If the selections are correct, click Start Install to start installing.
A status window opens that contains current messages, current milestones, and
percentage complete.
13 When the status window reports that the installation is 100% complete, click Next
to view the results window. (Next does not appear until the installation is 100%
complete.)
14 Click Finish to close the installation utility.
To Install Using the Custom Installation Type
1 Close the Service Control Manager window and the Control Panel window.
2 From the PATROL for Microsoft Windows Servers CD or from an installation

image that has been electronically downloaded from an EPD site and extracted,
run setup.exe.
3 In the Welcome to the Installation Utility window, click Next to begin your
installation.
4 In the Review License Agreement window, review the license agreement, select
Accept, and click Next to continue.
5 In the Select Installation Option window, select I want to install products on this
computer now and click Next to continue.
6 From the Select Type of Installation Window, select Custom and click Next.
7 In the Specify Installation Directory window, enter the directory where the
products you select will be installed and click Next.
The PATROL product directory is appended to the path that you enter in this step.
You will specify the PATROL product directory in step 10 on page 41.
8 In the Select System Roles window, select any or all of the following roles to
indicate the components that you want to install and click Next:
■ If you are installing to a computer that hosts or will host a PATROL Console,
select Console System.

■ If you are installing to a computer that hosts or will host a PATROL Agent,
select Managed System.
■ If you are installing to a computer that hosts or will host the PATROL Central
Operator – Web Edition (PATROL 7.x architecture) Web server, the PATROL
Console Servers, or the RTservers, select Common Services.
For more information, see “Determining Where to Install the PATROL Agent” on
page 32.
For more information about the PATROL consoles and PATROL Console Server or
RTserver, see the following documents:
■ PATROL Central Operator – Web Edition Getting Started

■ PATROL Central Operator – Microsoft Windows Edition Getting Started
■ PATROL Console Server and RTserver Getting Started
9 From the Select Products and Components to Install window, select the items that
you want to install and click Next.
10 In the Provide the PATROL 3.x Product Directory window, enter in the PATROL
3.x Product Directory field the directory in which you want to install PATROL KM
for Event Management as appropriate for your installation scenario. For more
information, see the instructions displayed on the PATROL 3.x Product Directory
window.
This directory is appended to the base directory path that is shown in the BMC
Products Installation Directory field. The installation directory was entered in
step 7 on page 40.
11 If the PATROL Default Account Properties window appears, enter the user name
and password that you want to use for your PATROL default account and click
Next. You should have created this account manually before you began to install
PATROL. (For more information about the PATROL Account, see “Accounts” on
page 27.) This window is displayed only when you are installing a product that
requires a PATROL logon.
12 If the Complete the Confirm BMC Startup Information window appears, perform
the following steps:
A In the Specify the Current Agent Port Number field, enter the port number that
you want the PATROL Agent to use. The default is 3181.
NOTE
If your previous installation used a different port number, change the default to
the current port number for the PATROL Agent.
Chapter 2 41
B In the Restart the PATROL agent automatically? field, select the appropriate
option:
■ If you want the installation utility to restart the PATROL Agent after the
installation is complete, select Yes.
■ To restart the PATROL Agent manually after the installation is complete,

select No.
■ This window may not be displayed if you are not installing into a managed
system.
13 In the Review Selections and Start Install window, review the selections carefully
to ensure that they are correct:
■ To change your selections, click Back and make those changes.
■ If the selections are correct, click Start Install to start installing.
A status window opens that contains current messages, current milestones, and
percentage complete.
14 When the status window reports that the installation is 100% complete, click Next
to view the results window. (Next does not appear until the installation is 100%
complete.)
15 Click Exit to close the installation utility.
Installing on AS/400 (iSeries)

On AS/400 (iSeries), the PATROL KM for Event Management is installed with the
PATROL Agent. For more information about installing the PATROL Agent on
AS/400 (iSeries), see the PATROL for AS/400 Getting Started.

Upgrading from an Earlier Version
Upgrading from an Earlier Version

The PATROL KM for Event Management 2.7 has no migration path from versions
prior to 2.7. Migration of the PATROL KM for Event Management is not required
because the configuration information is stored in the PATROL Agent configuration
database. If you have customized .kml or PSL files or created KMs in previous
versions of the PATROL KM for Event Management and you want to migrate those
to the new version, see the migration instructions in the PATROL for Microsoft
Windows Getting Started.
While there is no migration for the PATROL KM for Event Management, there are
some steps you must take if you install version 2.7 on a system that had a previous
version of the KM. The following sections describe the actions that you must perform
to upgrade from a previous version of PATROL KM for Event Management.
Remove Customized KM Files From the PATROL_CACHE

Before upgrading from a previous version of this KM, you must backup and remove
all Event Management and PATROL KM for Event Management customized files
from the PATROL_CACHE (including the StdEvent.ctg file).
Remove Existing Menu Commands

Before upgrading from a previous version of this KM, you must remove existing
menu commands that are installed in the ALL_COMPUTERS.KM.
Windows Consoles
1 From the PATROL Classic Developer Console main window, select the KM tab.
2 Expand the following folders in the KM tree view:
Knowledge Module => Computer Classes => ALL_COMPUTERS => Global => Menu
Commands
3 Right-click EVENTSPRING or Event Management.
4 Select Delete.
5 When asked to confirm the deletion, click Yes.
6 Save your changes before you exit the PATROL Console.
Chapter 2 43
Considerations for Using Online Help

If you plan to install the Unix version of PATROL KM for Event Management on a
PATROL Console for Unix, you must install the supported version of the Help
browser separately if it is not already installed.
Browser Version Required for Viewing PATROL Console for

Unix Help
The appropriate one of the following browsers is required to view PATROL Help in
PATROL version 3.x:
■ Unix: Netscape Navigator version 3.01 through 4.78
■ Red Hat Linux: Netscape Navigator version 4.x
PATROL Help does not support Netscape Navigator 6.0.
Installation Requirement
You must install Netscape Navigator on the computer where the PATROL console
resides. You can install Netscape anywhere on your Unix computer as long as the
binary is in the path.
Download Location
Netscape Navigator is supplied by Netscape Communications Corp. You can locate
the browser at http://home.netscape.com/download.
Additional Considerations for Using Online Help for Unix

When you select Help from the PATROL Console for Unix, it may take a few seconds
for the Help browser to launch. Two windows will be displayed. First, the Netscape
Navigator window is displayed as an icon, and then a browser window that contains
the Help is displayed.
In addition, you must be aware of the following restrictions:

■ Netscape Navigator displays warning messages when it is invoked multiple times

within the same user account because of its file-locking mechanism. It will,
however, continue functioning.
■ By default, when Netscape Navigator starts, it uses a private color map. As a

result, you might experience color flashing on your workstation. If so, you can set
the value of PATROL_BROWSER so that the colormap option is not specified.
However, some subsequent color requests might fail and the online Help will be
improperly displayed.
■ The Exceed for Windows NT X Window Server product by Hummingbird

Communication Ltd. may not always display the Help files properly.
Consult your Netscape Navigator documentation for specific platform requirements

and restrictions.
Required Environment Variables Settings for the Browser

The LANG, PATH, and PATROL_BROWSER environment variables must be set for
the Help browser to run properly. The following sections describe these variables.
LANG Variable
The Unix LANG environment variable must be set to C so that Netscape Navigator
will work properly. Otherwise, you might experience product failures.
Type of Shell Export Command for LANG Variable

Bourne LANG=C
export LANG
Korn export LANG=C
C setenv LANG=C
PATH Variable
The PATROL user account PATH variable must contain the location of the directory
containing the Netscape files. If the directory containing the Netscape files is not in
the path, add the directory to the PATROL user account path.
This requirement applies only to the PATROL user account on the PATROL console
computer.
Chapter 2 45
Type of Shell Export Command for PATH Variable

Bourne PATH=$PATH:/netscape_location
export PATH
Korn export PATH=$PATH:/netscape_location
C setenv PATH=$PATH:/netscape_location
PATROL_BROWSER Variable
When PATROL starts the Help browser, it uses the command in the
PATROL_BROWSER environment variable. As a default, the PATROL_BROWSER
environment variable contains the following command:
Type of Shell Export Command for PATROL_BROWSER Variable

Bourne PATROL_BROWSER=netscape -display $DISPLAY -install
-iconic
export LANG
Korn export PATROL_BROWSER=netscape -display $DISPLAY
-install -iconic
C setenv PATROL_BROWSER=netscape -display $DISPLAY
-install -iconic
To use different arguments, set the value of PATROL_BROWSER to the appropriate

string.
Example
For a Korn shell, use the following command:
export PATROL_BROWSER=/usr/local/bin/netscape -raise

Uninstalling PATROL KM for Event Management
Uninstalling PATROL KM for Event

Management
To uninstall PATROL KM for Event Management you must use the same version of
the installation utility that you used to install the product. Run the installation utility
in uninstall mode to uninstall PATROL KM for Event Management from your
system.
WARNING
If you use a different version of the installation program to uninstall, you might
remove files needed to perform uninstallation of other BMC Software products.
Determining the Version of the Installation Utility

To determine the version of the installer, perform the following procedure.
1 Access a command prompt and navigate to the appropriate location:
(Windows) BMC_ROOT\Uninstall
(Unix) BMC_ROOT/Uninstall
2 Type the following command and press ENTER.
(Windows) uninstall.exe -v
(Unix) ./uninstall.sh -v
Uninstalling PATROL KM for Event Management on Windows

You can use the option that is appropriate for what you want to uninstall to uninstall
PATROL KM for Event Management. The following procedures describe how to
uninstall products from a Windows environment and all related log files.
Chapter 2 47
Where to Go from Here
To Uninstall Individual Products
1 From the Uninstall directory in your BMC Software product installation directory,
double-click uninstall.exe to launch the installation utility in uninstall mode.
NOTE
As an option, you can launch the installation utility in uninstall mode by choosing
Start => Settings => Control Panel => Add/Remove Programs and double-clicking
BMC Software Tools in the Add/Remove Programs Properties dialog box.
2 Select the installation directory from which you want to remove a product, and
click Next.
3 Select the product or products that you want to uninstall, and click Next.
4 Review your selections and click Uninstall.
After the uninstallation is complete, a window is displayed that tells you whether the
uninstallation was successful.
For more information about advanced uninstallation options, such as uninstalling the
KM but retaining log files, which contain history for future analysis and
configuration files for redeployment, see the PATROL Installation Reference Manual.
Where to Go from Here

The following table lists other topics and where you can find them:
Topic Source of Information

overview of the PATROL KM for Event Chapter 1, “Product Components and
Management features Capabilities.”
setting up and configuring PATROL KM for Chapter 3, “Using the PATROL KM
Event Management for Event Management.”
information on usage scenarios Chapter 4, “Usage Scenarios.”
information about PATROL KM for Event Chapter 5, “Rules and Configuration
Management configuration variables Variables.”
parameter descriptions Chapter 6, “Parameters.”
troubleshooting information Chapter 7, “Troubleshooting PATROL
KM for Event Management,”
step-by-step procedures and detailed PATROL KM for Event Management
descriptions of the applications, menu component online Help
commands, parameters, and InfoBoxes

Chapter
3
Using the PATROL KM for Event
3
Management
This chapter provides information on using the PATROL KM for Event Management
to perform notification, availability checking, and parameter threshold management.
Preparing to Use the PATROL KM for Event Management . . . . . . . . . . . . . . . . . . . . . 51

Loading and Preloading KMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Determining Which KMs to Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
KM Files Preloaded on Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Loading and Unloading KMs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Loading Knowledge Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Verifying that PATROL KM for Event Management KM is Loaded. . . . . . . . . . . 55
Unloading Knowledge Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Configuration Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Defining Notification Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Defining Notification Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Defining Availability Monitors and Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Deciding Where to Place Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Configuring Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Recommended Configuration Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Using Notification Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Testing Notification Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Configuring Notification Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Configuring Remote Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Configuring Alert Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Rewording Notification Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Setting Notification Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Testing Notification Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Disabling Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Configuring Availability Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Configuring an Availability Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Configuring a Backup Availability Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Configuring the Availability Monitor Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Specifying an Availability Monitoring Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Changing the Ping Command Used for Availability Monitoring . . . . . . . . . . . . . 93
Chapter 3 49
Integrating with AlarmPoint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
AlarmPoint Benefits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Notification Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Installing and Configuring AlarmPoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Installing the AlarmPoint Java Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Configuring the AlarmPoint Java Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Testing the Java Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Using Action Scripts for AlarmPoint 5.2.01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Configuring Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Testing Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Managing Parameter Thresholds and Poll Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Benefits of Using the PATROL KM for Event Management . . . . . . . . . . . . . . . . . 104
Setting Collector Poll times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Using Wildcards to Represent PATROL Instance Names . . . . . . . . . . . . . . . . . . . 107
Activating and Deactivating Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Applying Thresholds and Poll Time Changes to the Agent . . . . . . . . . . . . . . . . . 111
Disabling the use of PATROL KM for Event Management Thresholds and Poll
Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Specifying What to Monitor or Exclude from Monitoring . . . . . . . . . . . . . . . . . . . . . . 112
Selecting Application Instances to Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Excluding Application Instances from Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 114
Configuring Blackout Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
About Notification Blackout Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Configuring Notification Blackouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Configuring Availability Blackouts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Configuring Recovery Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
About Recovery Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Enabling PATROL KM for Event Management Recovery Actions . . . . . . . . . . . 121
Specifying a Recovery Action Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Specifying a Recovery Action Command Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Using PSL Recovery Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Preparing to Use the PATROL KM for Event Management
Preparing to Use the PATROL KM for Event

Management
Before configuring the PATROL KM for Event Management, verify that the following
requirements are met:
■ The PATROL console version 3.4.x or later and the PATROL KM for Event
Management are installed on the computer that you want to use for the PATROL
console.
■ The PATROL Agent version 3.4.x or later and the PATROL KM for Event
Management are installed on the computer that you want to monitor and manage.
■ If you are using PATROL Central Operator – Microsoft Windows Edition or

PATROL Central Operator – Web Edition, the PATROL KM for Event
Management must be installed on the computer hosting the PATROL Console
Server.
Loading and Preloading KMs

When you load a KM from the PATROL console, the KM files are loaded on all the
PATROL Agents to which your console is connected. The KM icons appear in your
console, usually under each agent icon, during discovery. Each PATROL Agent then
collects data based on the instructions defined in the KM.
Preloading KMs is a PATROL Agent feature that causes KM files to continue to run
on the agent when no consoles are connected. KMs that are not preloaded collect data
only while a PATROL console is connected to the PATROL Agent.
Determining Which KMs to Load

Before you can use the KMs that you have installed, the KM files must be loaded into
the PATROL console so that the product’s applications, commands, and parameters
appear in the PATROL console. Table 9 on page 53 lists the KML and KM files in this
product that you can load. You can find the steps for loading KM files in “Loading
Knowledge Modules” on page 52.
Chapter 3 51
Loading and Unloading KMs
KM Files Preloaded on Agent

The following PATROL KM for Event Management KM files are automatically
preloaded on the PATROL Agent as part of the installation process. They are added
to the preloadedKMs agent configuration variable.
■ AS_EVENTSPRING.km
■ AS_AVAILABILITY.km
■ AS_EVENTSPRING_ALL_COMPUTERS.km
Preloaded KMs collect data as long as the PATROL Agent runs, even when no
PATROL console is connected. When you view a preloaded KM’s data collection
history, you do not see any gaps that would otherwise occur (because of the console’s
absence).

Installing PATROL KM for Event Management places the application files into the
PATROL directory. You can load the files into the PATROL console so that the
PATROL KM for Event Management applications, commands, and parameters
appear in the PATROL console.
If you no longer want to use an application class that you previously loaded, you can
use the unload instructions to unload the .km file so that its application class no
longer appears in your console.
Loading Knowledge Modules

Before you can begin using Knowledge Modules (KMs) that you have installed, you
must first load them with a PATROL Console. In this section, follow the instructions
that apply to your console.
To Load KMs with PATROL Central - Windows Edition
PATROL Central - Windows Edition has a Loading KMs wizard that enables you to
control which KMs are loaded on which computers.
1 On the Common Tasks tab of the taskpad, click the Load Knowledge Modules icon.
PATROL Central - Windows Edition displays the wizard.
2 Click Next to start the wizard.

The wizard lists each computer on which a PATROL Agent has been installed.
3 Select the check boxes for the computers on which you want to load KMs, and click
Next.
The wizard displays a list of available .kml files for each computer selected in the
previous step. Each .kml file is listed once for each computer. You can display .km
files by changing the filter.
The KMs available in this product are listed in Table 9.
NOTE
Unless you are an advanced PATROL user, use the .kml files to load product
component files. Loading individual .km files can break the interdependencies
between the .km files, while loading .kml files preserves these dependencies.
Table 9 EVENT_MANAGEMENT.kml File and Associated KM Files)

Product (.kml file) Components (KM files) Description
EVENT_MANAGEMENT.kml AS_AVAILABILITY The AS_AVAILABILITY
application class icon is not
displayed in the PATROL
Console until availability
targets are added.
AS_EVENTSPRING When loaded, this KM is
displayed on the console as
Event Management.
AS_EVENTSPRING_ALL_COMPU This KM file never appears
TERS on the console as a loaded
KM; it is merged with the
ALL_COMPUTERS.
4 Select the check boxes for the KM and computer pair that you want to load.
5 Click Next and click Finish.
PATROL loads the selected KMs on the selected computers.
To Load KMs with PATROL Central - Web Edition
PATROL Central - Web Edition has a Loading KMs feature that enables you to
control which KMs are loaded on which computers.
Chapter 3 53
1 From the Monitored Systems page, click the Load/Unload KMs button.
The Load KMs page opens, listing each computer on which a PATROL Agent has
been installed.
2 Select the computers on which you want to load KMs, and click Next.
The Load KMs page displays a list of available .km and .kml files.
If you selected more than one computer, the only .km and .kml files that are listed
are the ones that have been installed on all of the selected computers. If a particular
.km or .kml file was installed only on one computer, you must choose that
computer by itself to load the file.
The KMs available in this product are listed in Table 9 on page 53.
NOTE
3 Select the .km or .kml files that you want to load.
4 Click Finish.
PATROL loads the selected KMs on the selected computers.
NOTE
To load a .km or .kml file that was not listed in Step 2, ensure that the KM is
installed on the appropriate computer and select only that computer in Step 2.
To Load KMs with the PATROL Console for Windows
1 From the PATROL Console for Windows menu bar, choose File => Load KM.
The Load KMs dialog box displays a list of available .kml files. The KMs available
in this product are listed in Table 9 on page 53.
NOTE
2 Select one or more of the .kml files, and click Open.

PATROL loads the selected KMs on all of the computers listed under
PATROLMainMap.
To Load KMs with the PATROL Console for Unix
1 From the PATROL Console for Unix menu bar, choose File => Load KM.
The Load KMs dialog box displays a list of available .kml files. The KMs available
in this product are listed in Table 9 on page 53.
NOTE
2 Select one or more of the .kml files and click Open.
PATROL loads the selected KMs on all of the computers to which your console is
connected.
Verifying that PATROL KM for Event Management KM is

Loaded
To verify that the PATROL KM for Event Management application is loaded on the
managed systems, ensure that each managed system displays the Event Management
application class icon when viewed with a PATROL Console that has the PATROL
KM for Event Management loaded.
NOTE
The AS_AVAILABILITY application class icon is not displayed in the PATROL
Console until availability targets are added.
Unloading Knowledge Modules

If you no longer want to use an application class that you previously loaded, you can
unload the .km file so that its application class no longer appears in your console. In
some consoles, unloading is referred to as deleting. When you unload or delete a .km
file using a console, the file is not deleted from the patrol\knowledge directories on
the PATROL Console or the PATROL Agent computers.
Chapter 3 55
To Unload KMs with PATROL Central - Windows Edition
PATROL Central - Windows Edition has a wizard that enables you to unload
specified .km files from specified computers.
1 On the Common Tasks tab of the taskpad, click the Unload Knowledge Modules icon.
PATROL Central - Windows Edition displays the wizard.
2 Click Next to start the wizard.
The wizard lists each computer on which a PATROL Agent has been installed.
3 Select the check boxes for the computers from which you want to unload .km files,
and click Next.
The wizard displays a list of application class names (that correspond to .km file
names) for each computer selected. Each application class name is listed once for
each computer.
4 Select the check boxes for the .km and computer pair that you want to unload, and
click Next.
5 Click Finish.
The console removes the selected .km files from the current management profile.
To Unload KMs with PATROL Central - Web Edition
PATROL Central - Web Edition has a feature that enables you to unload specified .km
files from specified computers.
1 From the Managed Systems page, click Unload Knowledge Modules.
The Unload Knowledge Module Wizard starts.
2 Select the computers from which you want to unload .km files, and click Next.
The Load KMs page displays a list of .km files. Currently loaded .km files are
highlighted in the list.
3 Select the .km files that you want to unload and click Next.
4 Click Finish.
The console removes the .km files that you specified. These .km files are no longer in
the current management profile.

To Unload KMs with the PATROL Console for Windows
Unloading a KM is also referred to as deleting a KM in the PATROL Console for

Windows.
1 From the KM tab of the tree view, right-click the application class name that you
want to delete and choose Delete from the pop-up menu.
The console displays a dialog box that asks if you want to delete the selected
application.
2 Click Yes to delete the application class.
The application class is removed from your cache directory and your console
session file.
3 Repeat Step 1 and Step 2 until you have deleted all of the application classes
associated with the KM that you want to delete.
4 From the console menu bar, choose File => Save KM to save your changes.
To Unload KMs with the PATROL Console for Unix
Unloading a KM is also referred to as deleting a KM in the PATROL Console for

Unix.
1 From the PATROL Main window, choose Attributes => Application Classes.
2 Click the name of the application class that you want to delete.
The console highlights the application class name.
3 From the List of Application Classes menu bar, choose Edit => Delete.
The application class is removed from your cache Directory and your console
session file. The PATROL Console for Unix removes the application class name
from the List of Application Classes.
4 Repeat Step 2 and Step 3 until you have deleted all of the application classes
associated with the KM that you want to delete.
5 From the List of Application Classes menu bar, choose File => Save KM to save
your changes.
Chapter 3 57
Configuration Planning
Before you can use PATROL KM for Event Management, you must gather
information and plan your configuration. You should gather the following
information:
■ the servers that will send notifications (act as notification servers)

■ to whom e-mail or paging notifications are sent (targets)
■ the servers that will monitor the notification servers for availability
■ the notification servers that will be monitored for availability
■ where to place notification rules (notification server or monitored agent)
Defining Notification Servers

A notification server is the managed system that performs notification and event
collection on behalf of other PATROL Agents.
Why use a Notification Server?

With a notification server, you can centrally manage your event filtering and
notification rules. For example, if you need to modify a notification script or change
notification rules, you make the change only on the notification servers and not on
each agent. For more information on the advantages and disadvantages of locating
notification rules on the notification server, see “Deciding Where to Place Rules” on
page 61.
Notification servers also provide redundancy when you use a primary and backup
Using Primary and Backup Notification Servers

To ensure availability, you should assign both a primary and a backup notification
for each remote agent. A notification server could be a primary notification server for
some remote agents and a backup notification server for other remote agents. Hence,
a server that acts as a backup notification server does not need to be idle.
What Happens During Failover?

When a primary notification server fails and a backup notification server takes its
place, an alert is generated on the remote agent that sent the event to the notification
server. In addition, a message is displayed in the console system output window.

To assure availability in critical environments, the backup notification server should

be on a separate machine and network segment.
Once you have configured a primary and backup notification server, you can use the
PATROL Configuration Manager to copy the settings to the other notification servers.
If you use this method, make sure that you use the same notification script file name
and directory path on all notification servers.
Using Enterprise Consoles to Send Notifications

If you are using an enterprise console, such as PATROL Enterprise Manager (PEM) or
Tivoli, to send e-mail messages or pages, you can configure the notification server to
route notification events to the enterprise console. Even though the notification server
does not actually perform notification, you must still configure each remote agent to
send notification events to a notification server and configure the notification server
to route those events to the enterprise console. For a process flow that describes this
scenario, see “Sending Alerts to an Enterprise Console: Process Flow” on page 20.
Notification Server Connectivity

When identifying a notification server, make certain that there are no connectivity
problems between the notification server and the agents that it serves.
Providing Security
To improve security, create an operating system account on the notification server
systems to be used specifically for remote notification. This configuration enables you
to avoid using the more commonly used PATROL account. You can configure the
notification server so that it is unable to fully login to the notification server system by
using the operating system. For example, on Unix, give the notification server login
an invalid login shell, such as /bin/false.
Configuring a Notification Server

For more information on configuring a notification server, see “Configuring
Notification Servers” on page 71.
NOTE
You must install the PATROL Agent and the PATROL KM for Event Management on
the notification server system.
Chapter 3 59
Defining Notification Targets

For alert notifications, you define a default e-mail account that is the default target for
all PATROL objects that do not have a specific target defined. This e-mail account
receives notification messages when the PATROL objects generate alerts.
To further configure and customize the PATROL KM for Event Management, you can
specify e-mail targets for each PATROL object. For example, you may want Unix
related alerts to go to your Unix administrator and Windows related alerts to go to
your Windows administrator.
Create a notification table similar to the one in Table 10 to identify who to notify for
each type of alert. For more information, see “Setting Notification Targets” on
page 82.
Table 10 Notification Target Configuration Information

PATROL Object E--mail Target Paging Target
/ patrol@any.co.com none
/CPU unixadmin@any.co.com unixadmin
/NT_CPU ntadmin@any.co.com ntadmin
Defining Availability Monitors and Targets

You can monitor the PATROL Agents to verify that they are up and running by using
the availability monitoring feature. You must specify the servers that monitor and the
notification servers that are monitored. The following section provides some
guidelines on availability monitoring.
Providing Redundancy
You should configure both a primary and a backup availability monitor. The backup
availability monitor monitors only the availability of the primary availability
monitor. If the primary availability monitor becomes unavailable, the backup
availability monitor assumes monitoring until the primary availability monitor is
available.
Using Availability Monitors to Monitor Notification Servers

Do not make a notification server an availability monitor. The availability monitor
should be a separate agent that only monitors the notification servers. In this
arrangement, the notification server is considered an availability-monitoring target,
which means that it is being monitored for availability.

Dedicated Computer Not Required

While the PATROL agent running on the availability monitoring machine should be
dedicated to availability monitoring, the availability monitoring machine can
perform other functions.
Maximum Number of Agents to Monitor

An availability monitor can monitor a maximum of 100 agents. If the availability
monitor monitors more than 100 agents, it may not be able to ping with the frequency
specified by the parameter AvailabilityMonitorColl.
Improving Performance
To improve the availability monitor performance, you should apply certain agent
rules to the availability monitor. For more information, see“Configuring the
Availability Monitor Agent” on page 91.
TIP
Availability checkers perform best on Unix machines and allow easier management
of multiple agents running availability checkers on one machine.
Grouping Targets Logically

When setting up availability monitoring in your enterprise, group availability
monitoring targets and monitors in a logical fashion. For example, you may want to
group targets by geographical location so that when the availability monitor detects
that a notification server is unavailable, you know immediately which servers are
affected.
For more information about configuring availability monitoring, see “Configuring

Availability Monitoring” on page 87.
Deciding Where to Place Rules

The PATROL KM for Event Management rules specify parameter and notification
settings. Rules can exist on either the remote agents you are monitoring or the
notification server or on both. Some rules must exist only in one place. Table 11 on
page 62 discusses the advantages and disadvantages of rule locations.
Chapter 3 61
Table 11 Recommended Rule Location (Part 1 of 2)

Recommended
Rule Type Location Advantage Disadvantage
Targets (notification notification ■ Easier to manage More processing is
recipients) server performed at the
■ Less processing at notification server
managed nodes reduces
PATROL resource
consumption
Alert Messages remote agent ■ Reduces the number of More difficult to manage
(wording and content rules at the notification the rules on multiple
of notification server remote agents
messages)
■ Since messages are
reworded before arriving
at the notification server,
you don’t need a second
level of notification
servers to properly send
messages to an enterprise
console.
Blackouts remote agent ■ Reduces network traffic More difficult to manage
the rules on multiple
■ Reduces processing at remote agents
the notification server
Alert Action (what to remote agent The alert action must be defined on the remote agent
do when an alert only where PATROL alerts are generated.
occurs)
Parameter Settings remote agent The parameter settings must be defined on the remote
(thresholds and poll only agent where PATROL alerts are generated.
times)
Alert Resend (whether remote agent The alert resend settings must be defined on the remote
to resend outstanding only agent where the PATROL alerts are generated.
alerts)
Notification Command notification The notification script must be defined on a notification
(the script used to send server only server that sends notifications.
notifications)
If you are not using notification servers, the remote
agent, in effect, acts as the notification server. In this
case, the notification command rule resides on the
remote agent.
Send Reset on Init remote agent The Send Reset on Init setting must be defined on the
(whether to close old only remote agent where PATROL alerts are generated.
events when agent
restarts)

Configuring Notification
Table 11 Recommended Rule Location (Part 2 of 2)

Recommended
Rule Type Location Advantage Disadvantage
Custom Identifiers remote agent Custom identifiers must be defined on the remote agent
only where message rewording is taking place.
Recovery Actions remote agent Recovery actions settings must be defined on the remote
only agent where PATROL events are generated and where
you expect the recovery action to occur.
This sections describes how to configure the PATROL KM for Event Management to
perform notification.
Recommended Configuration Order

When using the PATROL KM for Event Management to configure notification and
availability checking, use the order suggested in Table 12.
Table 12 Recommended Configuration Process (Part 1 of 2)

Step Configuration Task Topic(s) Page
1 Identify, edit, and test the notification “Using Notification Scripts” 64
script. “Testing Notification Scripts” 70
2 Configure a notification server. “Configuring Notification Servers” 71
3 Reword default notification message “Rewording Notification Messages” 79
for the notification server.
4 Use PATROL Configuration Manager For an example of how to use the PATROL 134
to copy the notification server settings Configuration Manager, see “To Assign
(rules) to the other notification servers. Notification Servers for NT2 and NT3.” For
more detailed instructions on using the
PATROL Configuration Manager, see the
PATROL Configuration Manager User Guide.
5 Configure remote agents to use a “Configuring Remote Agents” 73
Chapter 3 63
Table 12 Recommended Configuration Process (Part 2 of 2)

to copy agent notification server rules Configuration Manager, see “To Assign
to other like agents. Notification Servers for NT2 and NT3” on
page 134. For more detailed instructions on
For example, copying the settings to using the PATROL Configuration Manager,
other agents that use the same see the PATROL Configuration Manager User
notification server. Guide.
7 Configure notification rules and “Setting Notification Targets” 82
parameter settings for the agents. “Managing Parameter Thresholds and Poll 104
Times”
“Configuring Alert Settings” 76
to copy agent notification rules and Configuration Manager, see “To Assign
parameter settings to other like agents. Notification Servers for NT2 and NT3” on
page 134. For more detailed instructions on
For example, you may want to set up a using the PATROL Configuration Manager,
notification rule for a parameter related see the PATROL Configuration Manager User
to Oracle. You would then copy that Guide.
rule to all other agents that are
monitoring Oracle.
9 Configure availability monitoring. “Configuring Availability Monitoring” 87
Using Notification Scripts

The PATROL KM for Event Management provides sample notification scripts that
call command-line utilities to initiate notification (such as e-mail and page). This
section describes the sample scripts, their locations, requirements for use, and editing
guidelines. Editing is required on most platforms.
Unix and Linux Scripts

On Unix and Linux, the following script options are available:
■ a Unix shell script that sends e-mail notification using mailx (Unix) or mail (Linux)
■ a Perl script that sends e-mail notification using mailx (Unix) or mail (Linux)
NOTE
The PATROL KM for Event Management Perl script has been tested with Perl 5.

Default Location on Unix
The scripts that run on Unix, shown in Table 13, are located in
$PATROL_HOME$/lib/psl
Table 13 Notification Script Location on Unix

Script Name
Unix Script AS_EVSLocalAlertNotify.sh
Perl Script AS_EVSLocalAlertNotify.pl
Unix Requirements
To use the Unix scripts, the server sending the notification must meet the
requirements shown in Table 14.
Table 14 Requirements for Using Scripts on Unix Notification Server

Script Requirements
Unix If mailx is installed in a directory other than /usr/bin/mailx, you must move
mailx to this directory or edit AS_EVSLocalAlertNotify.sh to execute mailx
from the directory where it is installed.
On Linux, you must edit the script and change any mailx references to mail.
Perl Associate the .pl extension with Perl. Otherwise, you must call the script
using the syntax shown below:
perl PATROL3-4/lib/psl/AS_EVSLocalAlertNotify.pl
On Linux, you must edit the script and change any mailx references to mail.
Windows Scripts
On Windows, the following script options are available:
■ a Windows batch file that you must edit before use, which can send any of the
following types of notification:
— SMTP e-mail message by means of a Visual Basic (VB) script (provided)

— MAPI e-mail message by means of a VB script (provided)
— SMTP e-mail message by means of Blat (not provided)
Blat is a free command-line e-mail client, that you can download from the Web.
You can also use any other SMTP-based, command-line e-mail client if you edit the
batch file accordingly. For more information, see “Editing Scripts” on page 67.
■ a Perl script that sends e-mail notification by means of Blat
Chapter 3 65
NOTE
The PATROL KM for Event Management has been tested with Blat version 1.7.
Default Location on Windows
The Windows scripts are located in the %PATROL_HOME%\lib\psl\ directory and

are named as shown in Table 15.
Table 15 Notification Script Location on Windows

Script Name
Batch File Script AS_EVSLocalAlertNotify.bat
SMTP VB Script sendmail.vbs
This VB script is called from AS_EVSLocalAlertNotify.bat.

This script uses an ActiveX control.
MAPI VB Script send_mapi.vbs
This VB script is called from AS_EVSLocalAlertNotify.bat.

This script uses an ActiveX control.
Perl Script AS_EVSLocalAlertNotify.pl
Windows Requirements
To use these Windows scripts, the server sending the notification must meet the
requirements shown in Table 16.
Table 16 Requirements for Notification Server When Using Windows e-mail Clients
Script Requirement
Batch File Script If Blat is installed in a directory other than C:\Blat, you must
move Blat to this directory or edit AS_EVSLocalAlertNotify.bat
to execute Blat from the directory where it is installed.
Perl Script The Perl script assumes the use of Blat. If Blat is installed in a
directory other than C:\Blat, you must move Blat to this directory
or edit the Perl script, AS_EVSLocalAlertNotify.pl, to execute
Blat from the directory where it is installed.
Associate the .pl extension with Perl. Otherwise, you must call the
script using the following syntax:
perl C:\PATROL3-4\lib\psl\AS_EVSLocalAlertNotify.pl

Table 16 Requirements for Notification Server When Using Windows e-mail Clients
Script Requirement
SMTP VB Script The SMTP service must be running.
This VB script is not supported on Windows NT Workstation.

MAPI VB Script Microsoft Outlook must be installed.
This VB script is not supported on Windows NT Workstation.
AS/400 (iSeries) Scripts

On AS/400 (iSeries), the script AS_EVSLocalAlertNotify is provided. By default, this
script sends e-mail notifications using the AS/400 SNDDST (Send Distribution)
utility. If you use this mail utility, no script modifications are required.
OpenVMS Scripts
On OpenVMS, the script AS_EVSLocalAlertNotify.com is provided. By default, this
script sends e-mail notifications using the native OpenVMS utility MAIL. If you use
this mail utility, no script modifications are required.
Editing Scripts
Before using the sample scripts, you may have to edit them, as described in Table 17
on page 68.
Chapter 3 67
Table 17 Editing Scripts

Script Platform Editing Required
Unix If you use Linux, you must change any mailx references to mail.
If you use mailx and mailx is not installed in the /usr/bin/mailx

directory, you must edit the script to indicate the appropriate path.
Windows If you use AS_EVSLocalAlertNotify.bat, you must remove the
REM comments from the mail client that you want to use. For more
information, see “Editing the Windows Batch File” on page 68.
If you use the Perl script, minor editing is needed. For details, see
“Editing Perl Script for use on Windows” on page 69.
If you use Blat and Blat is not installed in the C:\Blat directory, you
must edit the script to indicate the appropriate path.
If you use the SMTP VB script, you must edit the script to indicate
the name of your mail server and the SMTP port number. For more
information, see “Editing the SMTP VB Script” on page 3-69.
AS/400 No edits required if using native mail utility. If you use a different
(iSeries) mail utility, you must edit the script to call the desired utility.
OpenVMS No edits required if using native mail utility. If you use a different
mail utility, you must edit the script to call the desired utility.
Editing the Windows Batch File
If you use AS_EVSLocalAlertNotify.bat, remove the REM comments from the mail
client that you want to use. The script provides sections for MAPI-based e-mail,
SMTP-based e-mail, and Blat. For example, to use Blat, in the script shown below,
remove the REM comments beginning with the line that starts with set and ending
with the line that reads goto BYE.
:EMAIL
rem --
rem -- BLAT based eMail
rem --
rem set email_file=c:\blat\mtext%AS_PARAMETER_NAME%_%AS_SSTIME%.txt
rem if ."%AS_USERDEFINED%"==."" echo "%nmsg%" > %email_file%
rem if not ."%AS_USERDEFINED%"==."" echo "%AS_USERDEFINED%" > %email_file%
rem if .%email_file%==. set email_file=c:\blat\default.txt
rem if exist c:\blat\blat.exe c:\blat\blat %email_file% -t %ntargets% -s %nmsg%
rem goto BYE

If you use a third-party command-line e-mail client or if you want to use the script to
perform other types of notification, such as paging or trouble tickets, you must add
the code to the script that calls the e-mail client or appropriate notification utility.
Editing Perl Script for use on Windows
On Windows, you must edit the Perl script before you can use it to send e-mail
notifications with Blat. Find the following line in the Perl script and remove the
comment (# ):
#system("c:\\blat\\blat.exe $email_file -t \"$ntargets\" -s \"$nmsg\"");
Editing the SMTP VB Script
To use the SMTP VB Script (sendmail.vbs), you must edit the script to add the
following information:
■ name of the e-mail server

■ the SMTP server port
Add this information in the script as shown below.
' Enter the Mail Server name [FQDN/IP Address]

iConf.Fields("http://schemas.microsoft.com/cdo/configuration/smtpserver") ="mail.bmc.com"
' Enter the SMTP Server Port number
iConf.Fields("http://schemas.microsoft.com/cdo/configuration/smtpserverport") = 25
Backing up and Renaming the Notification Script

Before configuring notification servers, copy the notification script from the default
installation location, %PATROL_HOME%\lib\psl\, to another location. This action
prevents the script from being overwritten during a new installation or upgrade.
Place the notification script in the same location on both the primary and backup
notification servers.
Other Types of Notification

In addition to e-mail, the notification scripts that are included with the PATROL KM
for Event Management can also be used to send the following types of notifications:
■ pages
■ trouble tickets
■ custom notifications
Chapter 3 69
The PATROL KM for Event Management notification scripts have clearly marked
sections where you can add scripting to support these notification types.
NOTE
You must supply the notification software. For example, you can use the notification
script to issue a trouble ticket notification, but to actually create a trouble ticket, you
must have a trouble ticket application, such as Remedy.
Testing Notification Scripts

Before you continue configuring the PATROL KM for Event Management, you
should test your notification script to verify that e-mail and any other notification
services are properly initiated.
To perform a test, run the appropriate notification script as shown in the following
example:
AS_EVSLocalAlertNotify.ext type “targets” “message”
NOTE
Replace ext with the file extension of your notification script (bat, sh, or pl).
The notification script arguments are described in Table 18.
Table 18 Notification Script Arguments

Argument Description
type The notification type that you are testing. The following notification
types are supported:
■ email–sends an e-mail notification

■ page–sends a page notification
■ tt–sends a trouble ticket notification
■ custom–sends a custom notification
If you use the page, tt, and custom notification types, you must
customize the notification script.
targets A comma-separated list of notification message recipients (e-mail
addresses, page numbers, trouble-ticket inboxes, or custom addresses).
Spaces within the list are converted to commas by the notification script.
message the notification or test message that is sent to the targets

The following example shows a test of the AS_EVSLocalAlertNotify.bat script on

Windows:
AS_EVSLocalAlertNotify.bat email "patrol@bmc.com" "This is a test."
Configuring Notification Servers

This section describes the purpose of a notification server and describes how to
configure a server as a notification server.
NOTE
You must use the PATROL KM for Event Management to complete this task. This
functionality is not available in PATROL Configuration Manager. However, once you
configure one notification server, you can use the PATROL Configuration Manager to
copy your configuration to other notification servers.
To Configure a Notification Server
1 From the PATROL console, access the managed system you are using as your
notification server and display the KM menu commands as described in
“Accessing KM Commands and InfoBoxes” on page 212.
2 Choose the KM menu command Event Management => Quick

Config => Notification Server.
The Quick Config - Notification Server dialog box opens as shown in Figure 3.
Figure 3 Quick Config - Notification Server Dialog Box
Chapter 3 71
Use the Quick Config - Notification Server dialog box to specify the notification
server properties. The notification server properties are described in Table 19:
Table 19 Quick Config - Notification Server Properties

Property Description
Default Email Account the default e-mail address (notification target) that receives e-mails when
an object goes into an alarm or warning state
All events for PATROL objects that do not have defined notification
targets are sent to this e-mail address. See “Configuring Recovery
Actions” on page 120 for information on setting notification targets.
If you don’t want any notifications sent until you configure notification for
specific PATROL applications or parameters, enter NONE as your default
e-mail account or leave this field empty.
Notification Command the complete path and filename of the notification script or command used
to send notifications
Perform Alert Test specifies whether you want to perform an alert test after the changes are
accepted
If this is your first time using the PATROL KM for Event Management,
you should perform an alert test and verify that the notifications are
received.
3 Define the notification server properties and click Accept.
4 Repeat this task for the server you are using as the backup notification server.
Specifying Where to Send Notifications From

You can send notifications from the local machine on which the alerts occur or you
can send notifications from a notification server. This setting is stored in the rule
alertSystem and can be specific for each PATROL object. For example, you could send
notifications locally for one parameter, while for another parameter you could
forward the event to a notification server and configure the notification server to send
the notification message.
To Specify Where to Initiate Notifications
1 For the agent that you want to configure, access the KM menu commands as
described in “Accessing KM Commands and InfoBoxes” on page 212.
2 Choose the KM menu command Event Management => Alert Settings => Notification
System.

3 Select the PATROL object (application, class, and parameter) that you want to
configure. To configure all PATROL objects, select Set For Classes and then select /.
4 Select the appropriate alert options as described in Table 40 on page 163.
5 To save your changes, click Accept.
Configuring Remote Agents

You should assign a notification server for each remote agent that will generate
notifications. Assign both a primary and a backup notification server.
NOTE
Notification servers are not required. Remote agents can send their own notifications.
However, there are considerable benefits to using notification servers. For more
information, see “Why use a Notification Server?” on page 58.
Before You Begin
You should configure and test the notification servers before configuring the remote
PATROL Agents served by the notification servers.
NOTE
configure one notification server, you can use the PATROL Configuration Manager to
copy your configuration to other notification servers. The configuration settings are
stored in the following variables:
■ AS/EVENTSPRING/NOTIFICATION_SERVER1.defaultAccount (primary)
■ AS/EVENTSPRING/NOTIFICATION_SERVER2.defaultAccount (backup)
■ AS/EVENTSPRING/NOTIFICATION_SERVER1 (primary)
■ AS/EVENTSPRING/NOTIFICATION_SERVER2 (backup)
To Assign Notification Servers to Remote Agents
1 From the PATROL console, access the remote agent menu commands, as described
in “Accessing KM Commands and InfoBoxes,”.
2 Choose the KM menu command Event Management => Quick Config => Remote
Agent.
The Notification Server Settings dialog box opens as shown in Figure 4 on page 74.
Chapter 3 73
Figure 4 Notification Server Settings Dialog Box

.
3 Click PRIMARY NOTIFICATION SERVER SETTINGS.
The Primary Notification Server Settings (Figure 5) is displayed.
Figure 5 Primary Notification Server Settings Dialog Box

Use the Primary Notification Server Settings dialog box to specify the properties of
the primary notification server for the managed system. The properties are
described in Table 20:
Table 20 Notification Server Properties

Notification Server the hostname or IP address of the primary notification
Hostname server for the selected managed system
To avoid DNS resolution problems, use the IP address.

Notification Server Agent the port number of the notification server that the
Port selected managed system will use
Notification Server User the user name that the selected managed system will
Name use to connect to the notification server
Notification Server the password that the selected managed system will
Password use to connect to the notification server
Verify Password verify the password that the selected managed system
will use to connect to the notification server
Make Connection indicates that the remote agent maintains a persistent
Persistent connection with the notification server agent so that the
remote agent does not need to create a new connection
each time it sends an event to the notification server
4 Define the primary notification server properties, and click Accept.
5 Click BACKUP NOTIFICATION SERVER SETTINGS.
Use the Backup Notification Server Settings dialog box to specify the properties of
the backup notification server for the managed system. The properties are
described in Table 20 on page 75.
6 Enter the backup notification server properties, and click Accept.
Repeat this task for each remote agent.
You use the PATROL Configuration Manager to quickly configure all remote agents
at one time. See the PATROL Configuration Manager User Guide for more information
on the PATROL Configuration Manager.
Chapter 3 75
Configuring Alert Settings

The following section describes how to configure alert settings and includes the
following tasks.
Topic Page
Specifying Where to Initiate Notifications 76
Preventing False Alerts 77
Changing the Number of Times Alerts are Resent 78
Defining Agent-to-Notification Server Protocol Settings 79
Specifying Where to Initiate Notifications

You can send notifications from the local machine on which the alerts occur or you
can send notifications from a notification server. This setting is stored in the rule
alertSystem and can be specific for each PATROL object. For example, you could send
notifications locally for one parameter, while for another parameter you could
forward the event to a notification server that sends the notification. For more
information, see “Deciding Where to Place Rules” on page 61.
To specify Where to Initiate Notifications
1 From the PATROL console, access the host KM menu commands as described in
System.
3 Select the PATROL object (application, class, and parameter) that you want to
configure. To configure all PATROL objects, select the menu command Set For
Classes and then select / as shown in Figure 6 on page 77.

Figure 6 Selecting / to Represent all PATROL Objects
4 From the SET EVENT MANAGEMENT VARIABLE: alertSystem dialog box, select
the appropriate alert option, described in Table 40 on page 163.
Preventing False Alerts

This procedure describes how to reduce the number of false alerts sent from the
notification server to an enterprise console after an agent restart. For more general
information on reducing the number of alerts, see “Too Many E-mail Alerts Are Being
Generated” on page 201.
Why False Alerts Occur upon an Agent Restart
If an agent or an agent machine goes down, there may be outstanding events open at
the enterprise console. These events can be considered false alerts because after the
agent or the agent machine restarts, these events are no longer relevant. You can
configure PATROL to determine which events are no longer relevant and close those
events upon an agent restart. The settings for this option are stored in the rule
alertResetOnInit.
Chapter 3 77
To Prevent False Alerts upon an Agent Restart
2 Choose the KM menu command Event Management => Alert Settings => Local Alert
Settings => Send Reset on Init.
3 From the SEND RESET NOTIFICATION ON AGENT INITIALIZATION dialog

box, select Yes.
The value of the variable /AS/EVENTSPRING/ALERT/alertResetOnInit is set to 1,

which indicates that alerts are sent to close the open events.
Changing the Number of Times Alerts are Resent

This procedure describes how to change the number of times that alerts are resent if
they remain in a warning or alarm state in consecutive polling periods. As with other
PATROL KM for Event Management variables, you can configure this setting at the
PATROL object level (application, instance, or parameter). This setting is stored in the
rule alertResend.
To Change the Number of Times Alerts are Resent
Settings => Alert Resend.
3 Select the PATROL object (application, instance, or parameter) that you want to
configure.
The SET EVENT MANAGEMENT VARIABLE: alertResend dialog is displayed.
4 In the ALARM Resends and WARN Resends fields, enter the number of times alarm
alerts and warning alerts are resent.
To resend alerts continuously until the PATROL object is no longer in a warning or

alarm state, enter –1.
The variable /AS/EVENTSPRING/ALERT/object/alertResend is updated.

Defining Agent-to-Notification Server Protocol Settings

This procedure describes how to define the protocol settings used by remote agents
when performing the following activities:
■ sending NOTIFY events to the notification server

■ checking the notification server for availability
These protocol settings are stored in the variable RemoteAgentCommSettings.
To Define Protocol Settings
2 Choose the KM menu command Event Management =>Alert Settings => Remote
Alert Settings => Remote Comm Settings.
3 From the REMOTE AGENT COMMUNICATION SETTINGS dialog box, select the
appropriate protocol settings, described in Table 21.
Table 21 REMOTE AGENT COMMUNICATION SETTINGS dialog box

Setting Explanation
TCP/UDP Protocol protocol used for agent to notification server communication
UDP Timeout (ms) when using the UDP protocol, the length of time in
milliseconds to wait for a response before retrying
UDP Retries when using the UDP protocol, the number of times to retry a
failed communication
The variable /AS/EVENTSPRING/RemoteAgentCommSettings is updated.
Rewording Notification Messages

You can use the PATROL KM for Event Management to customize or reword
notification messages. You can reword the default message that is used for all
notification messages or you can reword the notification messages for a specific
PATROL object. You can reword the message subject line and the body text.
Chapter 3 79
Where Reworded Messages are Displayed

When you reword a notification message, the reworded message is displayed in an
e-mail, a page, in an event that is sent to an enterprise console, or in some other type
of custom notification. The notification format depends on how you configure the
notification server to process notification events.
Where to Reword Notification Messages

You can reword messages at the notification server or at the remote agent. However,
BMC Software recommends that you reword messages at the remote agent because
this practice reduces the number of rules on the notification server and makes it easier
to properly send messages to an enterprise console. For more information, see
“Deciding Where to Place Rules” on page 61.
Including Subject Line Only

To include only a subject line, and no body, in the notification message, edit the
notification script and change the value of the Send_Body variable to 0. By default, it
is set to 1, which includes the message body in the notification message.
Message Length Limitations

When you reword messages, verify that the message length is within the limitations
noted in Table 22.
Table 22 Message Length Limitations by Platform

Platform Message Length Limitations
Unix Subject line is limited to 100 characters. No known limit on the
message body.
Windows No known limit on the subject line. Message body is limited to 2035
characters.
If limits are exceeded, the message is truncated.

AS/400 When using the native SNDDST mail utility, the subject line is limited
(iSeries) to 44 characters and the message body is limited to 5000 characters.
OpenVMS Subject line is limited to 80 characters. The message body is limited to
255 characters.
If limits are exceeded, message is not sent.

To Reword the Default Notification Message
1 From the PATROL console, access the host you are rewording the message for as
described in “Accessing KM Commands and InfoBoxes” on page 212. The host
may be the notification server or a remote agent.
2 Choose the KM menu command Event Management => Alert Settings => Alert
Messages => Default Message Format.
The Set Event Management Alert Variables/Rules dialog box opens as shown in
Figure 7:
Figure 7 Set Event Management Alert Variables/Rules Dialog Box
3 Enter your reworded message subject line and message body and then click Accept.
You can use a mix of variables and text to create a reworded message. For a
description of the available message replacement variables, click MESSAGE
REWORDING OPTIONS. For a complete description of the message replacement
variables that are provided, see “NOTIFY_EVENT Fields” on page 157
If a Problem Occurs
■ In OpenVMS, the subject line is limited to 80 characters and message body is

limited to 255 characters. If you exceed these limits, messages may not be sent.
■ If you don’t specify message body text, the message text that you enter for the
message subject is also used for the message body.
■ Back slashes may be replaced with a front slash or a space on some platforms.
Chapter 3 81
Setting Notification Targets

You should set up specific targets for the PATROL KM for Event Management
notifications to ensure that the proper people are notified when alerts occur. The
following procedure describes how to set the notification target for a parameter alert.
To Set Notification Targets
1 From the PATROL console, access the host KM menu commands, as described in
2 Choose the KM menu command Event Management => Alert

Settings => Notification Targets => Email => Local Targets ANY STATUS => Set For
Parameters.
The Set Event Management KM Variables/Rules dialog box opens as shown in

Figure 8.
Figure 8 Selecting Applications
3 Select the application class of the parameter and click Accept.

Figure 9 on page 83.

Figure 9 Selecting Application Instances
4 Select the application instance of the parameter, and click Accept.

Figure 10.
Figure 10 Selecting Parameters
5 Select the parameter and click Accept.

Figure 11.
Figure 11 Set Event Management Alert Variables/Rules Dialog Box
6 Enter the e-mail address of the target for this alert and click Accept.
Chapter 3 83
You can set other notification targets using the same procedure, but you choose a
different menu command in Step 2. For example, you may choose Paging instead of
Email.
If a Problem Occurs
If you specify multiple targets but only the first target receives the e-mail message,
see “Cannot Send E-mail Notifications to Multiple Targets” on page 198.
For other problems, see Chapter 7, “Troubleshooting PATROL KM for Event

Management”.
Testing Notification Rules

You can use the What If? feature of the PATROL Configuration Manager to
determine which rules are triggered when a parameter enters a specified state, such
as ALARM or WARN. You can use this information to determine whether you have
configured the notification rules correctly.
Before You Begin

Before using the What If? feature to test your notification rules, configure the agent as
desired. Then, from the PATROL Configuration Manager, perform a get on the agent
to obtain the latest configuration.
To Test Rules Using the What If? Feature

1 From the left pane of the PATROL Configuration Manager, right-click the remote
agent or notification server that you want to test and choose the menu command
Event Management => What If.
2 From the What If dialog box, click Browse and then select the parameter that you
want to test.
3 In the Status field, select the event that you want to test (INFORMATION, WARN,
or ALARM).
4 If necessary, specify the day of the week and the time. This may be necessary if you
have configured blackout periods when notification is disabled.
5 To perform the test, Click OK.

The What If Results dialog box is displayed as shown in Figure 12. It shows the rules
that would be triggered and their associated values.
Figure 12 What If Results Dialog Box
Disabling Notification
You can disable, turn off, or limit notification using the instructions provided below.
To disable notification for a finite period only and then enable it, use the blackout
feature. For more information, see “Configuring Blackout Periods” on page 115.
To Disable all Notification

To disable all notification, use the following rule on the remote agent that is
generating events: /AS/EVENTSPRING/arsAction = 0. You can use the PATROL
Configuration Manager to create this rule.
To Disable Notification for Specific PATROL Objects

To disable notification for certain PATROL objects, such as an application class, set
the arsAction rule to 0 only for that application class. For example, to disable
notification for all parameters in the NT_CPU application class, use the following rule
on the remote agent generating events: /AS/EVENTSPRING/NT_CPU/arsAction =
0. You can use the PATROL Configuration Manager to create this rule.
Chapter 3 85
To Disable Notification at the Notification Server

To disable notification at the notification server, you can set the alertSystem rule to
NONE and then set it to LOCAL for those parameters for which you want to receive
notifications. For more information on configuring the alertSystem rule, see
“Specifying Where to Send Notifications From” on page 72.
Limiting Notifications by Adjusting Parameter Settings

If you are receiving too many notifications, review your e-mail messages (or pages)
and adjust the parameter settings to stop the alerts that you don’t want to receive.
You can accomplish this by adjusting the thresholds, deactivating threshold ranges,
or deactivating parameters.
If you use the PATROL KM for Event Management to make these changes, you can
make the change on one agent and then deploy the changes to all of your agents using
the PATROL Configuration Manager. For more information about deploying settings
using the PATROL Configuration Manager, see the PATROL Configuration Manager
User Guide.
Overriding Rules
You can also limit notification by overriding a rule. For example, if you don’t want a
remote agents to generate notify events, you can disable the arsAction rule on that
remote agent.
To Override Rules
1 Access the host KM menu commands as described in “Accessing KM Commands

and InfoBoxes” on page 212.
2 Choose the KM menu command Event Management => Alert Settings => Overrides.
3 From the Rule Override dialog box, select the PATROL KM for Event Management
rule that you want to override.
The rules listed are the rules that are currently configured on the agent. For more
information about the PATROL KM for Event Management rules, see Chapter 5,
“Rules and Configuration Variables”.
4 Click Accept.

Configuring Availability Monitoring

This section describes how to configure PATROL to monitor the availability of your
notification servers and alert you when a notification server is down.
Configuring an Availability Monitor

An availability target defines a managed system, such as a notification sever, that is
monitored for availability. In this task you specify an availability target for an
availability monitor.
Before You Begin
You should define the availability monitor machines and the managed systems that
you want to monitor for availability. For more information, see “Defining Availability
Monitors and Targets” on page 60.
To Configure an Availability Monitor
1 From the PATROL console, access the KM menu commands of the managed
system that you want to use as an availability monitor.
2 Choose the KM menu command Event Management => Availability => Add Target.
The Availability Monitor Add Target dialog box opens as shown in Figure 13 on
page 88:
Chapter 3 87
Figure 13 Availability Monitor Add Target Dialog Box
Use the Availability Monitor - Add Target dialog box to specify the properties of
the agent that you want to monitor for availability. Table 23 describes the
availability target properties.
Table 23 Availability Target Properties (Part 1 of 2)

Hostname the host name or IP address of the managed system you are
monitoring
To avoid DNS resolution problems, use the IP address.

PATROL Agent Port the port number of the PATROL Agent on the managed
system that you are monitoring
SNMP Port the SNMP port number of the PATROL Agent on the
managed system that you are monitoring
If you are using SNMP to monitor a managed system, the

HostPingFailures parameter is not used and remains grayed
out. Instead, the SnmpPingFailure parameter is used.
SNMP Community the SNMP community string of the managed system you are
monitoring

Table 23 Availability Target Properties (Part 2 of 2)

SNMP Timeout the SNMP connection timeout for the managed system you
are monitoring
SNMP Retries the number of times the PATROL Agent tries to connect to
the managed system that you are monitoring before it fails
SNMP Object ID the SNMP object ID on the managed system that you are
monitoring for availability
PATROL uses the SNMP object ID only when checking the

availability of the remote agent on the managed system. It
uses the object ID when making an SNMP call to the agent
and checking for a response. You can use the default object
ID or provide any other valid SNMP object ID.
3 Define the availability target properties and click Accept.
4 Repeat this task for each managed system you want to monitor for availability. For
example, if you are using the availability monitor to monitor multiple notification
servers, repeat this task for all notification servers.
You use the PATROL Configuration Manager to copy the availability monitoring
settings to the other managed systems. For more information on the PATROL
Configuration Manager, see the PATROL Configuration Manager User Guide.
Configuring a Backup Availability Monitor
Be sure that the machine you are using as the backup availability monitor has the
same availability targets as the primary availability monitor. The easiest way to
accomplish this is to use the PATROL Configuration Manager to copy the primary
availability monitor settings to the backup availability monitor. For more
information, see the PATROL Configuration Manager documentation. Alternatively,
you can manually add the same targets to the backup availability monitor.
Configuring Availability Failover

This procedure describes how to specify which availability monitor is the backup
availability monitor.
Chapter 3 89
Before You Begin
Before you configure availability monitoring failover, ensure that
■ you have configured the availability monitoring servers as described in

“Configuring an Availability Monitor” on page 87.
■ each pair of machines that you want to configure as primary and backup
availability monitors has the same availability targets.
To configure failover, you must access the machine that you want to use as the backup
availability monitor, run the Identify Primary menu command, and then select the
primary availability monitor. For more details, see the following procedure.
To Configure Failover
1 From the PATROL console, access the KM menu commands, as described in

“Accessing KM Commands and InfoBoxes” on page 212, for the managed system
that you want to use as the backup availability monitor.
2 Choose the KM menu command Event Management => Availability => Failover
Settings => Identify Primary.
The Choose Primary Monitor dialog box opens as shown in Figure 14.
Figure 14 Choose Primary Monitor Dialog Box
3 Select the primary availability monitor and click Accept.
The following changes are made:
■ the managed system you selected in Step 3 is set as the primary availability
monitor
■ the managed system that you executed the Identify Primary command from in Step
2 is set as the backup availability monitor

Configuring the Availability Monitor Agent

To make the availability monitor work effectively, you should apply the rules
highlighted in Figure 15 to the availability monitor machine. These rules are provided
with the PATROL Configuration Manager and are located in the
Shipped\ESG\Availability folder. They perform the following functions:
■ preloads the AS_AVAILABILITY.km on the availability monitoring agent

■ improves the ability of the availability monitoring agent to schedule pings
effectively. This feature is especially important if the availability monitor is
monitoring a large number of agents.
Figure 15 Rules to Apply to the Availability Checker Agent
To Apply Rules to the Availability Monitor
1 Select (highlight) the rules shown in Figure 15 and move them to the availability
monitor agent in the left pane. For example, the agent bhunter-HOU-0 in Figure 15.
2 Apply the rules to the agent by clicking the apply configuration icon .
Chapter 3 91
Specifying an Availability Monitoring Account

This procedure describes how to specify the account used by the availability monitor
when checking the availability of PATROL Agents. This account is optional. If you
don’t enter an account, the availability checker can still detect whether the PATROL
Agent is available, but it generates an invalid login event at the PATROL Agent
machine. If this is a concern in your environment, follow these steps to specify a valid
account.
NOTE
specify the account information for one availability checker, you can use the PATROL
Configuration Manager to copy your configuration to other availability checkers.
Before You Begin
The availability monitoring account that you specify must be valid on all of the agents
that the availability monitor is configured to monitor. If you must use different
accounts for different agents, you must configure multiple availability monitors.
To Specify an Availability Monitoring Account
1 From the primary availability monitor host, access the KM menu commands as
described in “Accessing KM Commands and InfoBoxes” on page 212.
2 Choose the KM menu command Event Management => Availability => Checker
Account.
3 From the CONFIGURE CHECKER ACCOUNT dialog box, enter the account used
by the availability monitor. The account you enter is used for all availability
targets.
4 To test whether the account is valid, enter the hostname and PATROL Agent port
of one of the availability targets.
5 Click Accept.
PATROL displays a message in the console system output window indicating

whether the test was successful.
6 Repeat steps 1-5 for the backup availability monitor.

If a Problem Occurs
If you receive invalid login events at the PATROL Agent machine, see
“AgentLoginDenied Parameter is in Alarm” on page 203.
Changing the Ping Command Used for Availability Monitoring

This topic describes how to change the path to the ping command used by the
availability monitor to check the availability of PATROL agent machines. You can
also specify arguments for the ping command.
To Change the Ping Command used for Availability Monitoring
1 Access the availability monitor host menu commands as described in “Accessing

KM Commands and InfoBoxes” on page 212.
2 Choose the KM menu command Event Management => Availability => Ping
Command.
3 From the Set Ping Command dialog box, enter the absolute path to the ping
command executable on the availability monitor machine.
The ping command is stored in the configuration variable pingCmd. To apply your
changes to the PATROL Agent, you must restart the PATROL Agent.
To Specify Ping Command Arguments
You can append the ping command with arguments by specifying the arguments in
the configuration variable pingArgs. To assign a value to this variable, you must use
the PATROL Configuration Manager.
Example
To use the following ping command, use the configuration variables described below:
ping host -n 2 -|32
Chapter 3 93
Integrating with AlarmPoint
Configuration Variable Value Comments

pingCmd ping Depending on where you are executing the ping
command from, you may have to also specify
the full path to the ping command. For example,
/usr/patrol/ping.
pingArgs -n 2 -| 32 None
Example
ping abc.bmc.com -n 2 -l 32
To Specify Ping Command Arguments on OpenVMS
When defining ping commands on OpenVMS, use the host macro to represent host
names.
Example
To use the following ping command, set the configuration variables described below:
ping -c 2 -s 99 host
Configuration
Variable Value Comments
pingCmd ping None
pingArgs -c 3 -s 99 host This command syntax is defined below:
■ -c 3 — specifies 3 ping attempts

■ -s 99 — specifies a ping packet size of 99 bytes
■ host — a macro that inserts the actual host name

You can use the PATROL KM for Event Management with the AlarmPoint products
that provide a wide range of notification options: e-mail, paging, two-way paging,
fax, and voice (phone).
BMC Software recommends AlarmPoint, but you could also choose to use any other
enterprise paging software that can be called from a command line.

AlarmPoint Benefits
AlarmPoint selects the notification option based on the personal preferences of the
recipients. For example, a user can configure AlarmPoint to send an e-mail message
during normal working hours but send a voice notification during nights and
weekends. By allowing AlarmPoint users to maintain their own contact and schedule
information, AlarmPoint administrators are freed from maintaining this information.
To use AlarmPoint for notification, you configure the notification server to execute a
script that calls the AlarmPoint java client. The java client then sends the notification
request to the AlarmPoint server. For an overview of the notification process when
using the PATROL KM for Event Management and AlarmPoint, see “Sending Pages
using AlarmPoint: Process Flow” on page 21.
Configuration Overview
To integrate the PATROL KM for Event Management with AlarmPoint, you must
complete the following steps:

1 Install AlarmPoint on a Windows “Installing and Configuring AlarmPoint” 96
server.
2 Configure AlarmPoint and define users “Installing and Configuring AlarmPoint” 96
(notification targets).
3 Install AlarmPoint java client. “Installing the AlarmPoint Java Client” 96
4 Configure AlarmPoint java client “Configuring the AlarmPoint Java Client” 96
5 Test the AlarmPoint Java client. “Testing the Java Client” 97
6 Download AlarmPoint scripts (only if “Using Action Scripts for AlarmPoint 98
using AlarmPoint 5.2.01). 5.2.01”
7 Configure notification. “Configuring Notification” 99
8 Test notification. “Testing Notification” 103
Chapter 3 95
Installing and Configuring AlarmPoint

To use AlarmPoint with the PATROL KM for Event Management, you must install
AlarmPoint on a Windows server and define AlarmPoint users (notification targets)
and their notification information, such as e-mail addresses, phone numbers, and
schedules.
For detailed instructions on installing and configuring AlarmPoint, see the

AlarmPoint User Guide and Manual available on the BMC Software support web site.
Installing the AlarmPoint Java Client

You must install the AlarmPoint java client on the notification server. Versions of the
java client are available for both Windows and various Unix platforms. For more
information about installing the AlarmPoint java client, see the AlarmPoint User Guide
and Manual available on the BMC Software support web site.
Configuring the AlarmPoint Java Client

You must configure the AlarmPoint java client to communicate with the AlarmPoint
server.
To Specify the AlarmPoint Server
1 On the notification server that has the java client installed, open the APAgent.xml
file in a text editor.
2 Enter the IP address or host name of the primary AlarmPoint server in the address
variable as show below in bold.
<?xml version="1.0" encoding="UTF-8" ?>

- <alarmpoint-agent version="1.0">
- 
<server type="primary" address="172.23.0.26" />
3 To apply your changes, restart the AlarmPoint java client.
You may need to configure other elements of the AlarmPoint java client service. For
example, if you are using java client version 1.5, you may need to change the java
client default restart properties. For more information, see the AlarmPoint User Guide
and Manual available on the BMC Software support web site.

Testing the Java Client

You can test the AlarmPoint java client to determine if it has access to the AlarmPoint
server.
To Test the Java Client
From the notification server on which you installed the AlarmPoint java client, open a
browser and enter the following URL. If the default port number was changed,
replace 2010 with the port number you used.
http://localhost:2010/agent/status.html
The browser indicates the status of the connection to the AlarmPoint server. A
successful connection appears as shown in Figure 16 on page 97.
Figure 16 Java Client Status Displayed in Browser
Chapter 3 97
If a Problem Occurs
If the AlarmPoint java client is unable to connect with the AlarmPoint server, verify
that you entered the correct IP address or host name of the AlarmPoint server. Next,
verify that you can ping the AlarmPoint server from the notification server.
Using Action Scripts for AlarmPoint 5.2.01

If you are using AlarmPoint 5.2.01, you need to download action scripts that enable
integration with the PATROL KM for Event Management.
Downloading Action Scripts

Download the following scripts:
■ AP_PATROL_EmailActionScriptV521-01.ppx —AlarmPoint e-mail action script

■ AP_PATROL_FaxActionScriptV521-01.ppx —AlarmPoint fax action script
If you are using AlarmPoint 5.2.02 or later, you don’t need to download these action
scripts.
You can download the action scripts required for AlarmPoint 5.2.01 from the
following locations:
Unix
ftp://ftp.bmc.com/pub/patrol/patches/PKM_Event_Management/2.5.00/UNIX/p
kmforem_alarmpointv521.tar
Windows
ftp://ftp.bmc.com/pub/patrol/patches/PKM_Event_Management/2.5.00/NT/pk
mforem_alarmpointv521.exe
Importing the Action Scripts for AlarmPoint 5.2.01

After you download and extract these scripts, you must import and promote them in
the AlarmPoint server. For more information, see “Exporting and Importing Scripts
and Recordings” and “Action Script Versions” in the AlarmPoint User Guide and
Manual. This step is required only if you are using AlarmPoint 5.2.01.

The following section describes how to configure the notification server to issue
notifications that are sent through the AlarmPoint server.
Using the Custom Notification Type

To use AlarmPoint, you must use the custom notification event type when
configuring the PATROL KM for Event Management rules.
Using AlarmPoint Notification Scripts

To integrate with AlarmPoint, use the following AlarmPoint notification scripts that
are provided with PATROL KM for Event Management:
■ AS_EVSLocalAlertNotifyAP.bat — PATROL KM for Event Management notification

script for Windows
■ AS_EVSLocalAlertNotifyAP.sh —PATROL KM for Event Management notification

script for Unix
NOTE
You should backup and rename these scripts prior to configuring the notification
server to use them. For more information about managing notification scripts, see
“Using Notification Scripts” on page 64.
Using PATROL KM for Event Management Notification Rules

The next step is to create PATROL KM for Event Management rules so that when a
PATROL object enters an alarm state, the notification server calls the AlarmPoint
notification script and passes a notification target that matches an AlarmPoint user
ID. The rules you need are shown below:
■ /AS/EVENTSPRING/object/arsAction — use this rule to specify that notification

is enabled for the PATROL object.
■ /AS/EVENTSPRING/ALERT/object/alertLocalCommand — use this rule to

specify the path to the notification script on the notification server.
■ /AS/EVENTSPRING/ALERT/CUSTOM/object/customTargetsLocalALARM —
use this rule to specify the ID of the AlarmPoint user or user group. This rule is a
local target rule, rather than a remote target rule, because the rule is located on the
notification server and the notification server is performing the notification. Thus,
notification is performed locally.
Chapter 3 99
In these rules, object refers to a PATROL object, which can be an application class, an
application instance, or a parameter. For example, a PATROL object could be the
NT_CPU\CPU_0\CPUprcrProcessorTimePercent parameter.
You can set these rules using the PATROL KM for Event Management or the
PATROL Configuration Manager. The following topics describe how to set the rules
using the PATROL KM for Event Management. For more information on using the
PATROL Configuration Manager, see the PATROL Configuration Manager User Guide.
Before You Begin
Before you set the notification rules, you must define notification servers and assign
notification servers to the remote agents. For more information, see “Configuring
Notification Servers” on page 71 and “Configuring Remote Agents” on page 73.
To Set the arsAction Notification Rule
1 From the PATROL console, access the managed system you are using as the
Actions => Set For Parameters.
3 From the next series of dialog boxes, choose the application class, instance, and
parameter. For example, NT_CPU\CPU_0\CPUprcrProcessorTimePercent. After
you choose the desired parameter, the dialog box shown in Figure 17 on page 101
is displayed.

Figure 17 SET EVENT MANAGEMENT VARIABLE:arsAction Dialog Box
4 From the SET EVENT MANAGEMENT VARIABLE: arsAction dialog box, verify
that the following options are selected:
■ Trigger NOTIFY_EVENT (Perform Notification) — this option enables notification

for the selected parameter.
■ Make persistent (update config db) — this option ensures that any changes you
make on this dialog box persist after an agent restart.
The following configuration variable value is set to 4, which enables notification:
/AS/EVENTSPRING/NT_CPU/CPU_0/CPUprcrProcessorTimePercent/arsAction
To Set the alertLocalCommand Notification Rule
Actions => Notification Command => Set For Parameters.
3 From the next series of dialog boxes, choose the same parameter selected in the
previous task: NT_CPU\CPU_0\CPUprcrProcessorTimePercent.
Chapter 3 101
4 From the SET EVENT MANAGMENT ALERT VARIABLE: alertLocalCommand

dialog box, enter the full path name of the AlarmPoint notification script on the
notification server computer. For example, /us/p/AS_EVSLocalAlertNotifyAP.sh.
The following configuration variable is set as /us/p/AS_EVSLocalAlertNotifyAP.sh:
/AS/EVENTSPRING/ALERT/NT_CPU/CPU_0/CPUprcrProcessorTimePercent/a
lertLocalCommand
To Set the customTargetsLocalALARM Notification Rule
Targets => Custom => Local TargetsALARM=> Set For Parameters.
3 From the next series of dialog boxes, choose the same parameter selected in the
previous task: NT_CPU\CPU_0\CPUprcrProcessorTimePercent.
4 From the SET EVENT MANAGMENT ALERT VARIABLE:

customTargetsLocalALARM dialog box, enter the ID of the AlarmPoint target, as
shown in Figure 18.
Figure 18 SET EVENT MANAGEMENT ALERT VARIABLES/RULES Dialog Box
The following configuration variable is set as administrator:
/AS/EVENTSPRING/ALERT/NT_CPU/CPU_0/CPUprcrProcessorTimePercent/c
ustomTargetsLocalALARM

When the NT_CPU\CPU_0\CPUprcrProcessorTimePercent parameter enters an

alarm state on the notification server or on any remote agent configured to send
events to the notification server, the notification server calls the AlarmPoint
notification script and passes the AlarmPoint ID (administrator). The AlarmPoint
script calls the AlarmPoint server, which notifies administrator according to his or
her AlarmPoint user settings. For example, an e-mail message may be issued during
the day and a page at night.
Testing Notification
To verify that the notification rules are working correctly, you can set the PATROL
object into an alarm state and verify that the notification is sent.
To Test Notification Using the setParameterValue Rule
You can set the value of a PATROL object using the setParameterValue rule.
1 Create the rule shown below:
"/AS/EVENTSPRING/setParameterValue" = { REPLACE =
"/NT_CPU/CPU_0/CPUprcrProcessorTimePercent=ALARM" }
2 Use the PATROL Configuration Manager to apply this rule to the agents that you
want to test.
When you apply this rule to an agent, the rule assigns the parameter a value that is
within the specified alarm range. This action causes an alarm condition and generates
an alert.
To Test Notification Using a PSL Command
You can also use a PSL command to set a parameter value and generate an alert.
When the default parameter thresholds are being used, the following command
causes the CPUprcrProcessorTimePercent parameter to generate an alert:
%PSL set("/NT_CPU/CPU_0/CPUprcrProcessorTimePercent/value",99);
If a Problem Occurs
If the notification is not sent when the parameter enters an alarm state, see Chapter 7,
“Troubleshooting PATROL KM for Event Management”.
Chapter 3 103
Managing Parameter Thresholds and Poll Times
Managing Parameter Thresholds and Poll

Times
You can use the PATROL KM for Event Management to set PATROL parameter
thresholds and poll times for any parameter on a managed system. By default this
ability is enabled.
Benefits of Using the PATROL KM for Event Management
When you set parameter thresholds using the PATROL KM for Event Management,
the thresholds are stored in agent configuration variables, not in the KM files. This
feature makes upgrades easier since your thresholds are stored externally to the KM
files. It also allows you to define the settings on one agent and use the PATROL
Configuration Manager to deploy the settings throughout your environment.
In addition, if a KM is committed to an agent whose thresholds are being set through

the PATROL KM for Event Management, the thresholds stored in the agent
configuration variables are reapplied to the agent. This action prevents the PATROL
KM for Event Management thresholds from being overwritten.
NOTE
When you make thresholds changes using the PATROL KM for Event Management,
these changes are not reflected in the console display because the changes are made at
the agent, not in the console KM files.
To Set Parameter Thresholds Using the PATROL KM for Event Management
2 Choose the KM menu command Event Management => Parameter

Settings => Thresholds.
3 From the next series of dialog boxes, choose the application class, application
instance, and parameter. After you choose the desired parameter, the Configure
Thresholds dialog box is displayed as shown in Figure 19 on page 105.

Figure 19 Configure Thresholds Dialog Box
4 Use the Configure Thresholds dialog box, described in Table 24, to specify the
properties of the selected objects threshold settings and then click Accept.
Table 24 Threshold Setting Properties (Part 1 of 2)

Active indicates that the parameter is active and the settings in the dialog box represent
the current parameter settings
Border Range To enable the border range, click Enable. If you enable the border range, you must
also specify border action properties on the Border Actions tab.
Enable the border range if it is possible for the parameter to return a value outside
of the other alarm range limits. You can use this for information only or as a
third-level alert condition representing either a warning or an alarm state.
Chapter 3 105
Table 24 Threshold Setting Properties (Part 2 of 2)

Alarm Range 1 To enable Alarm1, click Enable and then specify a minimum and maximum range.
Use Alarm1 as a first-level alert condition representing either a warning state or an
alarm state. Alarm1 values:
■ must be less than Alarm2 values

■ cannot overlap the Alarm2 range
■ cannot fall outside the range limits or border range
Alarm Range 2 To enable Alarm2, click Enable and then specify a minimum and maximum range.
Use Alarm2 as a second-level alert condition representing either a warning state or
an alarm state. Alarm2 values:
■ must be greater than Alarm1 values

■ cannot overlap the Alarm1 range
■ cannot fall outside the range limits or border range
Enable makes the range active
Alert State ■ Click OK when the result of the range breach is informational for users or
non-critical (for example, back up a file when it exceeds a certain size).
■ Click Warning or Alarm to have the parameter undergo a state change when the
range is breached.
Min minimum value of acceptable range
Max maximum value of acceptable range
Trigger Alarm determines when an alarm is triggered and can be one of the following values:
■ After an alarm has occurred “n” times — Use this value to discount random
spikes in the return values. You must also specify how many consecutive times
the alarm range can be breached before the parameter alarms.
■ Immediately on alarm — Use this value if the value returned is of concern.
■ After all recovery actions fail — Use this value if you want to be alerted after all
recovery actions fail and the returned value remains within the warning or
alarm range.
N If you selected After an alarm has occurred “n” times for the trigger alarm, specify
how many consecutive times you want the alarm value returned during parameter
execution before the parameter actually alarms.
Apply to makes the selected parameter thresholds apply to the current session
current session
Make makes the selected parameter thresholds persist after the console is disconnected
persistent
If a Problem Occurs
If a problems occurs, see “Parameters Setting Lost After Agent Restart” on page 206.

Setting Collector Poll times

This procedure describes how to set parameter poll times using the PATROL KM for
Event Management.
Before You Begin
■ Before you set collector poll times, determine which application class the standard
or collector parameters reside in.
■ The collector must be active. If the collector is not active, it is not shown in the list
of selectable collectors.
To Set Collector Poll times

Settings =>Polltimes.
3 Choose the application class and instance for the standard or collector parameter.
4 From the SET EVENT MANAGEMENT VARIABLE: interval dialog box, enter the
new poll time and then click Accept.
Using Wildcards to Represent PATROL Instance Names

When you set up parameter threshold or poll time rules, you may want to create one
rule that matches several PATROL instances. For example, you may want to create a
parameter threshold rule for any process that contains the letters WIN. You can do
this using wildcards.
PATROL KM for Event Management uses the following set of characters to identify a
wildcard: {re:*}.
For more information, see the following example.
Wildcard Usage Matches No Match

CPU_{re:*} CPU_03 CP_1
CPU_13 CPU14
HoustonCPU_03
Chapter 3 107
Requirements for Using Wildcards

The following usage rules apply to wildcards:
■ You can use a wilcard only to represent PATROL instance names. You cannot use
wildcards to represent host names, parameter names, or any other PATROL object.
■ You can use wildcards only in threshold and poll time rules. You cannot use
wildcards in notification rules.
■ You can use only one wildcard in an expression.
■ You cannot use wildcards to specify the beginning or ending of an instance name.
For example, CPU_{re:*} matches both HoustonCPU_03 and CPU_03.
■ Rules that use explicit instance names take precedence over rules that contain
wildcard matches.
■ Rules that contain wildcard matches take precedence over rules that use the
__ANYINST__ variable to represent any instance name.
For more information, see the examples shown in Table 25.
Table 25 Wildcard Usage in Threshold Rules: Examples

Processes Running
on the Host Rules Result
■ msdtc Rule # 1: Since rule # 2 did not
■ svchost /AS/EVENTSPRING/PARAM_SETTINGS/THRESH match any of the
■ msv OLDS/NT_PROCESS/__ANYINST__/PROCSTATUS processes running on
the host, rule # 1 is
Rule# 2: applied to all of the
/AS/EVENTSPRING/PARAM_SETTINGS/THRESH instances on the host.
OLDS/NT_PROCESS/pat{re:*}/PROCSTATUS
■ msdtc Rule# 1: Since rule # 1 is an
■ svchost /AS/EVENTSPRING/PARAM_SETTINGS/THRESH exact match for a
■ msv OLDS/NT_PROCESS/msdtc/PROCSTATUS process that is running
on the host, it takes
Rule # 2: precedence over rule
/AS/EVENTSPRING/PARAM_SETTINGS/THRESH # 2.
OLDS/NT_PROCESS/ms{re:*}/PROCSTATUS

Activating and Deactivating Parameters

Using the PATROL KM for Event Management, you can perform the following
parameter configurations:
■ deactivate (make inactive) parameters that are active by default in the KM

■ activate (make active) parameters that are inactive by default in the KM
Deactivating Parameters that are Active by Default in the

KM
When deactivating parameters that are active by default in the KM, you can
deactivate a single instance of a parameter or all instances of a parameter. You can
also use the PATROL Configuration Manager to apply this setting globally across
your enterprise.
To Deactivate a Single Instance of a Parameter

instance, and parameter.
After you choose the desired application, instance, and parameter, the Configure
4 From the Configure Thresholds dialog box, deselect the Active checkbox.
5 To save the threshold properties, click Accept.
To Deactivate all Instances of a Parameter

Chapter 3 109
instance, and parameter. To deactivate all instances of a parameter, select <all
instances> from the instances dialog box. When you select <all instances>, the
__ANYINST__ variable is used to represent any instance of the parameter.
4 From the Configure Thresholds dialog box, deselect the Active checkbox.
The following agent configuration variable is created:
AS/EVENTSPRING/PARAM_SETTINGS/THRESHOLDS/application
class/__ANYINST__/parameter
where application class and parameter represent the application class and parameter
that you chose to deactivate.
To apply this rule to other servers in your enterprise, use the PATROL Configuration
Manager. For more information, see the PATROL Configuration Manager User Guide.
If a Problem Occurs
Activating Parameters that are Inactive by Default in the

KM
When activating parameters that are inactive by default in the KM, you can activate a
single instance of a parameter or all instances of a parameter. You can also use the
PATROL Configuration Manager to apply this setting globally across your enterprise.
To Activate a Single Instance of a Parameter


instance, and parameter.
4 From the Configure Thresholds dialog box, select the Active checkbox.
To Activate all Instances of a Parameter
1 From the PATROL Configuration Manager or the Wpconfig utility, set the agent
configuration variable AS/EVENTSPRING/processWildcards to a value of 1.
2 Create the following rule, using a wildcard symbol, {re:*}, to represent the instance
name.
AS/EVENTSPRING/PARAM_SETTING/THRESHOLDS/application
class/{re:*}/parameter name
3 Assign the rule the desired value. For more information on the syntax of the
THRESHOLDS rule, see “THRESHOLDS” on page 186.
To apply this rule to other servers in your enterprise, use the PATROL Configuration
Manager. For more information, see the PATROL Configuration Manager User Guide.
If a Problem Occurs
Applying Thresholds and Poll Time Changes to the Agent

If you use the PATROL KM for Event Management to change parameter thresholds
and poll times and you want to apply the changes to the agent without waiting until
the agent restarts, set the value of the following configuration variable to 2, 4, or 6:
/AS/EVENTSPRING/PARAM_SETTINGS/STATUSFLAG/paramSettingsStatusFlag
Chapter 3 111
Specifying What to Monitor or Exclude from Monitoring
Then, the next time the AS_EVENTSPRING parameter RefreshParamSettings runs, it

applies the changes and set this variable back to 1. For more information on the
paramSettingsStatusFlag variable, see “paramSettingsStatusFlag” on page 188.
Disabling the use of PATROL KM for Event Management

Thresholds and Poll Times
If you disable the use of PATROL KM for Event Management parameter thresholds
and poll times, you must restart the agent after disabling to ensure that the default
KM parameter settings are used.
To Disable PATROL KM for Event Management Thresholds and Poll Times
In this task, you change the threshold for all instances of a PATROL parameter.
2 Choose the KM menu command Event Management => Parameter Settings => Status
Flags.
3 From the SET EVENT MANAGEMENT VARIABLE: paramSettingsStatusFlag

dialog box, select No to disable PATROL KM for Event Management parameter
settings.
4 To save your changes, select Yes.
5 To apply your changes to the PATROL Agent, restart the PATROL Agent.
Specifying What to Monitor or Exclude from

Monitoring
This section describes how to use the PATROL KM for Event Management to specify
which KM application instances to monitor or exclude from monitoring.
Selecting Application Instances to Monitor

To monitor only a few instances and exclude most instances from monitoring,
perform the following steps:

1. Add the instances that you want to monitor to an exclude filter.
2. Change the exclude filter to an include filter.
This method is not intuitive but it may be faster than adding all of the instances that
you don’t want to monitor to an exclude filter.
Instance monitoring settings are stored in the following agent configuration

variables:
■ AgentSetup/ApplicationClass.FilterList Configuration Variable

■ AgentSetup/ApplicationClass.FilterType Configuration Variable
To Add Instances You Want to Monitor to an Exclude List (Temporarily)
2 Choose the KM menu command Event Management => Instance Filtering => Edit
Filter List.
3 Choose the application class.
4 From the EDIT INSTANCE FILTER LIST dialog box, select Remove and click OK.
5 From the Instance Filter List dialog box, select the application instances that you
want to monitor and then click OK.
To Change the Exclude List to an Include List
2 Choose the KM menu command Event Management => Instance Filtering => Change
Filter Type.
3 Choose the application class you previously configured in “To Add Instances You
Want to Monitor to an Exclude List (Temporarily)” on page 113.
4 From the CHANGE FILTER TYPE dialog box, for the option Change Filter Type to
include, select Yes and then click OK.
Chapter 3 113
The filter is changed to an include filter.
NOTE
PATROL monitors only the instances in the include filter. It does not monitor
instances that are discovered after you create the filter. To monitor a new instance,
you must add it to the include filter.
To Verify Your Configuration
To verify that the filter is working as you expect, you can generate a report that shows
which instances are being monitored.
2 Choose the KM menu command Event Management => Instance Filtering => Filtered
Instance Report.
PATROL displays a report in the console system output window that shows the
■ which application classes have filters defined

■ the type of filter (include or exclude)
■ the application instances in the filter
Excluding Application Instances from Monitoring

This procedure describes how to exclude selected KM application instances from
monitoring. This setting is stored in the PATROL KM for Event Management variable
filterList.
PATROL automatically monitors application instances that are discovered. If you

don’t want to monitor a particular application instance, you need to add it to the
exclude filter.
To Exclude Instances from Monitoring
2 Choose the KM menu command Event Management => Instance Filtering => Edit
Filter List.

Configuring Blackout Periods
3 Choose the application class whose instances you want to exclude from
monitoring.
4 From the EDIT INSTANCE FILTER LIST dialog box, select Remove and click OK.
5 From the Instance Filter List dialog box, select the application instances that you
want to exclude from monitoring and then click OK.
PATROL adds the selected instance to the exclude filter. It is no longer monitored.
To Verify Your Configuration
To verify that the exclude filter is working as you expect, you can generate a report
that shows which instances are being monitored.
2 Choose the KM menu command Event Management => Instance Filtering => Filtered
Instance Report.
PATROL displays a report in the console system output window that shows the
■ which application classes have filters defined

■ the type of filter (include or exclude)
■ the application instances in the filter
TIP
To monitor only a few instances and exclude most instances from monitoring, you
can add those instances that you want to monitor to an exclude list and then change
the exclude list to an include list. This method may be faster than adding all of the
instances that you don’t want to monitor to an exclude list. For more information, see
“Selecting Application Instances to Monitor” on page 112.

You can use the PATROL KM for Event Management to set blackout periods for
PATROL objects (parameters or application classes) and availability targets. During
blackout periods, PATROL objects do not generate notifications and availability
targets are not monitored for availability. This section describes how to set a blackout
period for a PATROL object and an availability target.
Chapter 3 115
About Notification Blackout Periods

Blackout periods are set to prevent notification from taking place during a specified
time period even if an alert condition occurs. Multiple blackout times per day are
allowed.
When you set blackout periods for PATROL objects using the PATROL KM for Event
Management, the data for the PATROL object is still collected and the history is
maintained. However, if the PATROL object enters an alarm state and generates an
alert, notification does not occur.
Blackout periods can be applied to most PATROL objects. Blackout periods can be
defined locally at the system where the alert occurs and at the notification server.
Local Blackout Periods

If you define a blackout locally at the managed system, alerts are generated at the
managed system but they are not forwarded to a remote notification server.
Notification Server Blackout Periods

If you define a blackout period at the notification server, the managed systems
continue to forward alert events to the notification server, but the notification server
does not perform notification.
Configuring Notification Blackouts

You can set a notification blackout for any PATROL object. The following procedure
describes how to set a notification blackout for an application class.
To Set a Notification Blackout for an Application Class
2 Choose the KM menu command Event Management => Alert Settings => Blackout
Periods => Set For Classes.
The Choose the Target Classes dialog box opens as shown in Figure 20 on
page 117.

Figure 20 Choose the target classes Dialog Box
3 Select an application class and click Accept.
The Set Event Management Blackout Variables/Rules dialog box opens as shown
in Figure 21.
Figure 21 Set Event Management Blackout Variables/Rules Dialog Box
Chapter 3 117
Use the Set Event Management Blackout Variables/Rules dialog box to specify the
blackout properties for the selected application class. The blackout properties are
described in Table 26.
Table 26 Blackout Properties

Blackout Start Time the blackout start time
Blackout End Time the blackout end time
Blackout Days the days that you would like the blackout
to occur
Merge Selected Blackout Periods with merges the current blackout out period
Pre-Existing Settings with existing blackout periods for this
object
Replace Existing Blackout Periods with replaces all existing blackout periods with
Current Selection the defined blackout period
Example
To set a blackout from Friday at 19:00 pm until Sunday at 9:00 requires you to create
three blackout periods and merge them as you create each one:
1. Blackout Start Time -->19:00:00

Blackout Stop Time --> 23:59:59
Blackout Days-->Fri

Blackout Days-->Sat

Blackout Days-->Sun
4 Define the blackout properties, and click Accept.
You can set blackout periods for other PATROL objects by selecting the Set for
Instances or Set for Parameter menu command in Step 2.

Configuring Availability Blackouts

You can set an availability blackout period, during which availability monitoring is
not performed. You may want to create an availability monitoring blackout period to
prevent managed systems from being monitored when they are undergoing regularly
scheduled maintenance.
To Configure Availability Monitoring Blackouts
2 Choose the KM menu command Event Management => Availability => Blackout
Periods.
in Figure 22.
Figure 22 Set Event Management Blackout Variables/Rules Dialog Box
3 Select one or more targets and then click Accept.
in Figure 23 on page 120.
Chapter 3 119
Configuring Recovery Actions
Figure 23 Availability Monitor Add Target Dialog Box
Use the Set Event Management Blackout Variables/Rules dialog box to specify the
blackout properties for the selected application class. The blackout properties are
described in Table 26 on page 118.
NOTE
The availability blackout options do not include the option to merge the blackout
periods.
4 Define the blackout period properties, and click Accept.

This section describes how to configure PATROL KM for Event Management
recovery actions. These recovery actions are executed at the PATROL Agent and are
associated with a PATROL object status change, such as a parameter going from an
OK state to an ALARM state.

About Recovery Actions

The PATROL KM for Event Management recovery actions are distinct recovery
actions that are unrelated to the recovery actions you can define in a KM using the
PATROL Console for Windows or the PATROL Console for Unix. For the sake of
discussion, the recovery actions that you define in the KM using the PATROL console
are referred to as PATROL native recovery actions. The following sections explain the
differences between PATROL native recovery actions and PATROL KM for Event
Management recovery actions.
PATROL Native Recovery Actions

When you define PATROL native recovery actions in the PATROL console, you
associate the recovery actions with alarm and border ranges. These recovery actions
run when the PATROL parameter value enters the specified range. The parameter
may be in an OK, WARN, or ALARM state when the recovery action runs, depending
on how you configure the parameter.
PATROL KM for Event Management Recovery Actions

Unlike PATROL native recovery actions, the PATROL KM for Event Management
Recovery actions run only when a parameter changes status. For example, when a
parameter goes from an OK state to a WARN or ALARM state, or even when a
parameter goes from an ALARM to an OK state.
If you don’t want the parameter to alarm until recovery actions have been attempted,
you must use PATROL native recovery actions, rather than PATROL KM for Event
Management recovery actions. However, you can use both types. For example, you
could define PATROL native recovery actions and specify that the parameter enters a
WARN or ALARM state only after all recovery actions fail. Then you could create a
PATROL KM for Event Management recovery action that runs only if the PATROL
native recovery actions fail.
Enabling PATROL KM for Event Management Recovery Actions

Before configuring PATROL KM for Event Management to execute a PATROL KM
for Event Management recovery action for a PATROL object, verify that the recovery
action is enabled for that object. To execute recovery actions, the PATROL KM for
Event Management rule arsAction must be set to 2, 4, or 6. For more information
about arsAction, see “arsAction” on page 161.
To use the PATROL KM for Event Management interface to set the value of
ArsAction (and enable recovery actions), use the following procedure.
Chapter 3 121
To Enabled Recovery Actions
Actions.
3 Select the PATROL object (application, instance, or parameter) that you want to
configure.
The SET EVENT MANAGEMENT VARIABLE: arsAction dialog box is displayed.
4 To allow recovery actions to be associated with this PATROL object, select Allow
Recovery Actions.
5 To enable notification for this PATROL object, select Trigger NOTIFY_EVENT.
6 If you want your changes to apply only until the agent is restarted, select Apply to
current session. To apply your changes to future sessions, select Make persistent.
7 To save your settings, click Accept.
Recovery actions are enabled for WARNING and ALARM events. To enable recovery
actions for INFORMATION events, you must set the configuration variable
allowInfoRecoveryActions to 1.
Specifying a Recovery Action Script

This procedure describes how to specify the recovery action script.
Before you begin
Before specifying a recovery action script, you should have completed the following
steps:
■ Configured the PATROL KM for Event Management to allow recovery actions. For
more information, see “Enabling PATROL KM for Event Management Recovery
Actions” on page 121.
■ Specified the type of recovery action command (arsCmdType). For more

information, see “Specifying a Recovery Action Command Type” on page 123.
■ Created and tested a recovery action script. For more information, see “Using PSL
Recovery Actions” on page 124.

■ On the PATROL Console, open the agent system output window so that you can
view any status messages generated during this procedure.
To Specify a Recovery Action Script
Settings => Recovery Action Commands.
3 Choose the application class, instance, or parameter that you want to associate
with the recovery action.
The SET EVENT MANAGEMENT VARIABLE: arsCommand dialog box is

displayed.
4 From the SET EVENT MANAGEMENT VARIABLE: arsCommand dialog box,

enter the full path and file name of the recovery action script.
PATROL displays a message in the console system output window indicating if the
script was found.
Specifying a Recovery Action Command Type

To execute a recovery action, you must specify a command type. You can specify the
command type for all PATROL objects or for any individual PATROL application,
instance, or parameter. If all of your recovery actions are of one type, for example
PSL, you should specify that command type for all PATROL objects, as shown in Step
4 in the procedure below.
The command type is stored in the rule arsCmdType. For more information about the
arsCmdType rule, see “arsCmdType” on page 168.
To Specify a Recovery Action Command Type
Settings => Recovery Action Command Type.
Chapter 3 123
3 Choose the application class, instance, or parameter that you want to associate
with the recovery action. To select all PATROL objects, select Set For Classes and
then choose the forward slash /.
4 From the SET EVENT MANAGEMENT VARIABLE: arsCmdType dialog box,

enter the command type.
PATROL has two built-in command types: PSL and OS. If you use a command
type other than PSL or OS, the command type must be defined for the application
class. For more information on defining command types, see the PATROL console
documentation.
In addition to specifying the command type, you need to specify the full path and file
name of the recovery action script. For more information, see “Specifying a Recovery
Action Script” on page 122.
Using PSL Recovery Actions

If you use PSL recovery actions, you can use the PATROL KM for Event Management
variables shown in Table 27 in your recovery action. Each variable contains a double
underline (__) at the beginning and end of the variable name.
Table 27 PATROL KM for Event Management Variables

Variable Description
__appl_class__ application class name
__param__ parameter name
__param_status__ parameter status (ALARM, WARN, OK)
__param_value__ parameter value
__instance__ instance name
__src_event_id__ Source event id. This is the event ID of the event that began the
notification process, typically a threshold exceeded event
(Standard Event 9, 11 or 39).
__nfile__ A generated file that a PSL recovery action can write output to.
The file name appears as the AS_NOTIFICATION_FILE
environment variable in your notification script. You do not need
to write to this file directly. You can also use the __output__
variable, described below.

Table 27 PATROL KM for Event Management Variables

Variable Description
__output__ When you assign a value to this variable, the data is
automatically saved to the notification output file, __nfile__. This
file name is accessible from the notification script as the
environment variable AS_NOTIFICIATION_FILE.
__udefvar__ When you assign a value to this variable, the variable is
automatically assigned to the message replacement token
%USERDEFINED% and the environment variable
AS_USERDEFINED, which is accessible to the notification script.
For an example of how to use this variable, see “Sending E-mail
Notification for CPU Usage that Includes Parameter
Annotations” on page 140.
Getting Host Information
To obtain other information, such as hostname or IP address, you need to use a get()
command. For example, to get the hostname, use the following command:
hostn = get("/hostname");
For more information about using PSL, see the PATROL PSL documentation.
Chapter 3 125

Chapter
4
4 Usage Scenarios
The following section contains typical scenarios for using the PATROL KM for Event
Management and the PATROL Configuration Manager. Detailed instructions are
included. The following scenarios are described.
Sending E-mail Notification When Disk Space is Low . . . . . . . . . . . . . . . . . . . . . . . . 128

Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Selecting a Mail Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Loading the PATROL KM for Event Management . . . . . . . . . . . . . . . . . . . . . . . . 130
Defining the Notification Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Configuring the Remote Agent NT1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Specifying an E-mail Target for Low Disk Space . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Rewording the Notification Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Sending E-mail Notification for CPU Usage that Includes Parameter Annotations 140
Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Overview of Annotated Data Points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Enabling Recovery Actions and Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Creating Recovery Action Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Creating Notification Command Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Configuring a Recovery Action that Runs Under a Specified Account . . . . . . . . . . . 144
Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Testing Recovery Action Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Enabling Recovery Actions for ArchFreeSpace on Agent Computer . . . . . . . . . 146
Defining the Recovery Action Type for Agent Computer . . . . . . . . . . . . . . . . . . 146
Storing the Encrypted Password as a Pconfig Variable. . . . . . . . . . . . . . . . . . . . . 147
Configuring the PSL Recovery Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Summary of Rules Created . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Testing the Recovery Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Chapter 4 127
Sending E-mail Notification When Disk Space is Low
Sending E-mail Notification When Disk Space

is Low
You may want to configure e-mail notification when a PATROL parameter goes into
a warning or alarm state. For example, if disk space is low, you may want to send an
e-mail message to the storage administrator.
In the following scenario, PATROL is running on two Solaris computers and three
Windows Servers computers, as shown in Figure 24. You will configure the Solaris
computers, NS1 and NS2, to send e-mail notification when the disk space is low on
the Windows Servers computers.
To achieve this goal, you will configure the Solaris computers as notification servers
and the Windows Servers computers as remote agents.
Figure 24 Network Configuration
Primary Backup
Notification Server Notification Server
NS1 NS2
NT1 NT2 NT3
Assumptions
For this scenario, assume the following:
■ A PATROL console is running on NT1. This console is connected to all of the

servers shown in Figure 24. This console could be any of the following consoles:
PATROL Developer Console, PATROL Central Operator - Windows Edition,
PATROL Central Operator - Web Edition. You could also use a PATROL Operator
Console if you applied the rule allowOperator.

■ The PATROL KM for Event Management and the PATROL KM for Windows OS
are installed on all of the remote agent and notification server computers.
■ There is a dedicated PATROL agent for each notification server. This is the BMC
Software recommended configuration.
■ All PATROL Agents used for monitoring are running on port 3181.
■ Except where otherwise noted, you will use the PATROL KM for Event
Management to create and configure the notification rules. For some tasks, you
could also choose to use the PATROL Configuration Manager to create and
configure rules. For more information, see Table 28 on page 129.
To configure e-mail notification for low disk space, you complete the following tasks.
The table below shows the location in which step is completed. An alternative
location is also noted. For example, many of the configuration tasks can be completed
within either the PATROL KM for Event Management or the PATROL Configuration
Manager.
Table 28 Sending E-mail Notification for Low Disk Space: Configuration Overview
Alternative PATROL
Step Task PATROL Product Product
1 Selecting a Mail Client NA NA
2 Loading the PATROL KM for PATROL console None
Event Management
3 Defining the Notification Servers PATROL console - (PATROL KM None
for Event Management)
4 Configuring the Remote Agent PATROL console - (PATROL KM None
NT1 for Event Management)
5 Copying notification server PATROL Configuration None
settings to NT2 and NT3 Manager
6 Specifying an E-mail Target for PATROL console - (PATROL KM PATROL
Low Disk Space for Event Management) Configuration Manager
7 Copying e-mail targets from NS1 PATROL Configuration None
to NS2 Manager
8 Rewording the Notification PATROL console - (PATROL KM PATROL
Messagee for Event Management) Configuration Manager
9 Copying reworded notification PATROL Configuration None
message rule from NS1 to NS2 Manager
10 Testing Notification PATROL console or PATROL None
Configuration Manager
Chapter 4 129
Selecting a Mail Client

You can use any e-mail client that has a command-line interface such as Unix mailx or
Blat (shareware) for Windows. For Windows, the PATROL KM for Event
Management provides MAPI and SMTP Visual Basic (VB) scripts that are called from
the notification script.
Since the notification severs are Unix computers, the recommended approach is to
use the default notification script, which sends mail using the built-in Unix mail
client, mailx. If the notification servers were Windows computers, you would need to
edit the notification script to enable the appropriate mail client. For Unix servers, no
editing is required. For more information, see “Using Notification Scripts” on
page 64.
Loading the PATROL KM for Event Management

You must load the PATROL KM for Event Management on a PATROL Developer
Console that has all of the PATROL Agents defined.
To Load the PATROL KM for Event Management
1 From server NT1, start the PATROL console.
2 From the console main menu, load the EVENT_MANAGEMENT.kml as described

in “Loading Knowledge Modules” on page 52.
Defining the Notification Servers

In this task, you configure the Solaris computers, NS1 and NS2, as your primary and
backup notification servers.
You must use the PATROL KM for Event Management to complete this task.
To Define NS1 as the Primary Notification Server
1 From the PATROL console on NT1, right-click NS1 and access the KM menu
commands as described in “Accessing KM Commands and InfoBoxes” on
page 212.

Config => Notification Server.

The QUICK CONFIG - NOTIFICATION SERVER dialog (Figure 25) is displayed.
Figure 25 QUICK CONFIG - NOTIFICATION SERVER Dialog Box
3 Enter the default e-mail account that receives notifications for all events that go
into an alarm or warning state. For this example, use admin@abc.com as the default
e-mail account. Later, you will define the e-mail target for our specific event: low
disk space.
The default e-mail account acts as a catch-all for events that don’t have a specific
e-mail target associated with them. Typically, when e-mail notifications are sent to
the default e-mail account, you determine whether the event is valid and requires
notification. If it is valid, you would associate the appropriate e-mail target to that
event. For example, if the event was related to Microsoft Exchange, you would
assign the e-mail target to the Microsoft Exchange administrator. If the event is not
valid or is not important, you would adjust the alarm thresholds or possibly
deactivate the parameter that spawned the event.
4 Enter the file name of the script that is run for event notification.
To prevent the notification script from being overwritten during upgrades or new
installations, make sure you have copied the notification script from the directory
in which it is installed to another directory outside of the BMC Software directory
structure. For more information, see “Using Notification Scripts” on page 64.
5 Click Accept.
6 Repeat Steps 1 to 6 for NS2, the backup notification server.
In this example, NS1 is the primary notification server for all of the monitored agents.
However, you could configure NS1 as the primary notification sever for some of the
remote agents and as the backup notification server for the other remote agents.
Chapter 4 131
Configuring the Remote Agent NT1

In this step, you assign notification servers to the Windows Servers computers (NT1,
NT2, and NT3). NS1 is the primary notification server and NS2 is the backup
notification server. You must use the PATROL KM for Event Management to
complete this task.
To Assign a Primary Notification Server for NT1

1 From the PATROL console, access the NT1 KM menu commands as described in

Config => Remote Agent.
The NOTIFICATION SERVER SETTINGS dialog box (Figure 26) displays.
Figure 26 NOTIFICATION SERVER SETTINGS Dialog Box
3 Click PRIMARY NOTIFICATION SERVER SETTINGS.
The Primary Notification Server Settings dialog box displays.
4 In the Notification Server Hostname field, type NS1, the host name of the primary

5 In the Notification Server User Name field, type the user ID you want to use for
logging into the notification server. The default is the account you are currently
logged in on.
NOTE
For better security, you should create a unique operating system account that is
used only for remote notification on the notification servers. You can configure the
notification login account to make it unable to fully login to the notification Server.
For example, on Unix you can use an invalid login shell, such as /bin/false for the
notification account.
6 Enter the notification server PATROL Agent port.
7 Enter the notification server account password and then click Accept.
The NOTIFICATION SERVER SETTINGS dialog box is displayed (Figure 26 on

page 132).
To Assign a Backup Notification Server for NT1

The next step is to assign a backup notification server. The backup notification server
sends notification when the primary notification sever is unavailable. For more
information about primary and backup notification servers, see “Defining
Notification Servers” on page 58.
1 From the NOTIFICATION SERVER SETTINGS dialog box, click BACKUP

NOTIFICATION SERVER SETTINGS.
The Backup Notification Server Settings dialog box (similar to Figure 26 on

page 132) displays.
2 In the Notification Server Hostname field, enter NS2, the host name of the backup
3 Enter the NS2 port number and account and password information and click
Accept.
The REMOTE NOTIFICATION SERVER SETTINGS dialog box (Figure 26 on

page 132) is displayed.
4 To perform a notification test for NS1, select Yes under Perform Alert Test?
5 Click Accept.
6 Verify that the e-mail was received by the default e-mail account.
Chapter 4 133
To Assign Notification Servers for NT2 and NT3

You must assign notification servers for each PATROL agent that you want to
monitor. For NT2 and NT3, you can either repeat the configuration steps performed
on NT1 or use the PATROL Configuration Manager to copy the configuration rules
from NT1 to NT2 and NT3. The following instructions describe how to use the
PATROL Configuration Manager to copy the configuration rules.
When using the PATROL Configuration Manager to copy rules, you first get the
configuration (rulesets) for the agent you configured (NT1). Next, you get the rulesets
for the agent you want to update (NT2 or NT3). Then you compare the rulesets and
save the differences. Finally, you copy the differences to the machines that you want
to update. In this case, you would copy the differences to NT2 and NT3.
1 To get the NT1 rulesets, from the PATROL Configuration Manager Agent folder,
right-click the NT1 agent and choose the menu command Configuration => Get.
2 When the Job Status window status changes to OK, click Accept.
A backup of the NT1 rulesets is created under Rulesets\ChangeSpring\backup.
3 To get the NT2 rulesets, right-click the NT2 agent and choose the menu command
Configuration => Get.
A backup of the NT2 rulesets is created under Rulesets\ChangeSpring\backup.
4 Select (highlight) both of the rulesets you just created.
5 Right-click the highlighted rulesets and choose the menu command Compare.
The RuleSet Comparison window is displayed.
6 To display the rulesets that are unique to NT1, select the option First Unique. (If
NT1 was the second ruleset selected, then select the option Second Unique.)
7 Select the unique rules/variables displayed and click Save Selection.
8 From the Save Selected Rules window, enter a ruleset name. For example,
RemoteAgentsNS.
Under the RuleSets folder, a ruleset named RemoteAgentsNS is created. When you
expand the ruleset, it shows the notification server rules.
9 Select (highlight) the RemoteAgentsNS ruleset and drag it to the NT2 and NT3
agents under the Agents folder.
10 To apply the rulesets to NT2 and NT3, click the Apply Configuration icon .

Specifying an E-mail Target for Low Disk Space

Currently, all e-mail notifications are sent to the admin@abc.com e-mail target, which is
the default e-mail account for the notification server. In this procedure, you specify
that e-mail notifications for the LDldFreeSpacePercent parameter are sent to the
e-mail account networkadmin@abc.com. The e-mail address is referred to as the target.
To Specify an E-mail Target for Low Disk Space

1 From the PATROL console, access the remote agent (NT1) host KM menu
commands as described in “Accessing KM Commands and InfoBoxes” on
page 212.
NOTE
The advantage of creating the target rule on the remote agent is reduced
processing at the notification server. However, you could choose to create the rule
on the notification server, which has the benefit of centralizing rules. For more
information, see “Deciding Where to Place Rules” on page 61.
Targets => Email => Remote Targets ALARM => Set For Parameters.
NOTE
Since you decided to create the e-mail target rule on the remote agent, you select
the sub-menu command Remote Targets ALARM, because the notification is
occurring on a computer that is remote from the agent. However, if you were to
create the target rules on the notification server, you would use the menu
command Local Targets ALARM, since the targets are located on the same computer
performing the notification.
3 From the Choose the target CLASS(es) dialog box, select NT_LOGICAL_DISKS and
click Accept.
4 From the Choose target INSTANCE(s) of /NT_LOGICAL_DISKS, select <all

instances> and click Accept.
5 From the Choose target PARAMETER(s) of __ANYINST__, select

LDldFreeSpacePercent and click Accept.
The SET EVENT MANAGEMENT ALERT

VARIABLE:emailTargetsRemoteALARM dialog box is displayed as shown in
Figure 27.
Chapter 4 135
Figure 27 EVENT MANAGEMENT ALERT VARIABLE:emailTargetsRemoteALARM Dialog

Box
6 Enter the e-mail target networkadmin@abc.com and then click Accept.
When you perform this step, the following rule is created:
/NT_LOGICAL_DISKS/__ANYINST__/LDldFreeSpacePercent/emailTargetsRe
moteALARM
The value of this rule is networkadmin@abc.com. For more information on the

emailTargets rule, see “emailTargets” on page 171.
7 Perform Steps 1-6 for the other remote agents (NT2 and NT3) or use the PATROL
Configuration Manager to copy the configuration rules from NT1 to NT2 and NT3.
Rewording the Notification Message

You can choose to use the default notification message text or reword messages on an
individual agent, on a notification server, or on both. For the pros and cons of these
approaches, see “Deciding Where to Place Rules” on page 61. For this scenario,
assume that you want to reword messages at the notification server.
You can set up a generic message format for all alerts on the notification server or you
can create unique messages for specific applications, instances, or parameters. For
this scenario, you will create a generic message for all alerts. You will create the rule
for this message format on the notification servers NS1 and NS2.

To Reword the Default Notification Message

1 From the PATROL console, access the NS1 KM menu commands as described in
2 Choose the KM menu command Event Management => Alert Setting => Alert
Messages => Default Message Format.
The Message Rewording dialog box (Figure 28) displays.
Figure 28 Message Rewording Dialog Box
3 Enter the message subject line and body using the message replacement variables.
For a complete list and description of the message replacement variables provided
by PATROL KM for Event Management, see “NOTIFY_EVENT Fields” on
page 157.
EXAMPLE
%PARAMETER_STATUS%on%HOSTNAME%forparameter%PARAMETER_NAME%=%PARAMETER_VALUE%
PATROL KM for Event Management substitutes real values at run time. The
following example shows how an actual notification message would be displayed
using the message format shown above:
ALARM on NT1 for parameter LDldFreeSpacePercent = 3.50
4 Perform Steps 1-3 for the backup notification server, NS2, or use the PATROL
Configuration Manager to copy the configuration rules from NS1 to NS2.
Chapter 4 137
Next, perform the following tests to verify that notification is working correctly.
Testing the notification script or program

Before testing your configuration, you should test the script or program that you are
using to send notifications. For this scenario, you would log into the notification
servers, NS1 and NS2, using the PATROL default account, and attempt to send an
e-mail message using mailx. After you verify that the e-mail client on the servers can
send e-mail using mailx, you would use the following procedure to test whether
e-mail notification is sent when the LDldFreeSpacePercent parameter enters an
ALARM state.
To Test whether Notification is sent when

LDldFreeSpacePercent alarms
1 Using the PATROL Configuration Manager, create the rule shown below:
"/AS/EVENTSPRING/setParameterValue" = { REPLACE =
"/NT_LOGICAL_DISKS/__ANYINST__/LDldFreeSpacePercent=ALARM" }
2 Use the PATROL Configuration Manager to apply this rule to the remote agents
NT1, NT2, and NT3.
When you apply this rule to an agent, this rule assigns the parameter a value that is
within the specified range. The parameter enters the desired state, ALARM, and
generates an alert.
3 Determine whether the LDldFreeSpacePercent parameter enters an ALARM state

and whether an e-mail notification is sent to networkadmin@abc.com.
You can also use a PSL command to set a parameter value.
To Force LDldFreeSpacePercent into ALARM using a PSL

Command
1 From the PATROL console, access the KM menu commands for one of the remote
agents, NT1, as described in “Accessing KM Commands and InfoBoxes” on
page 212.
2 Choose the KM menu command PSL Command.

3 Enter the PSL command shown below and click Apply.
set("/NT_LOGICAL_DISKS/C:/LDldFreeSpacePercent/value",1);
4 Repeat the PSL command in Step 3 twice.
This PSL command sets the value of LDldFreeSpacePercent on logical disk C: to

1%. Since by default, LDldFreeSpacePercent alarms when the value is 0 to 5%, for 3
consecutive cycles, issuing this PSL command 3 times causes
LDldFreeSpacePercent to enter an ALARM state and issue an alert.
5 Determine whether the LDldFreeSpacePercent parameter enters an ALARM state

and whether an e-mail notification is sent to networkadmin@abc.com.
If a Problem Occurs
If the e-mail notification is not sent correctly, see “Configuration Problems” on
page 198 for troubleshooting help.
Chapter 4 139
Sending E-mail Notification for CPU Usage that Includes Parameter Annotations
Sending E-mail Notification for CPU Usage

that Includes Parameter Annotations
This scenario describes how to configure the PATROL KM for Event Management to
send an e-mail notification that includes annotated data for the parameter
CPUCpuUtil, which monitors the CPU processor utilization.
Assumptions
In this scenario you make the following assumptions:
■ The PATROL KM for Event Management has been installed and the KM has been
loaded in the console.
■ You have already defined the notification server and notification script as
discussed in “Defining Notification Servers” on page 58 and the script successfully
sends notifications.
■ You have already defined notification targets as described in “Defining

Notification Targets” on page 60.
■ The configuration instructions assume the use of the PATROL KM for Event
Management menu commands. Except where noted, you could also use the
PATROL Configuration Manager to perform the configuration tasks.
■ The notification server and the managed nodes are Unix servers. The same result
can be accomplished on a Windows server using a Perl script instead of a Unix
shell script. However, you would need to edit the Perl script to achieve proper
formatting of the notification message.
■ The PATROL KM for Windows OS is installed on the console and on the managed
nodes.
■ To obtain the annotated data for CPUCpuUtil, a PSL (PATROL Scripting

Language) recovery action will be used.

Overview of Annotated Data Points

Some PATROL parameters collect textual data related to events. The textual data is
posted on the associated parameter graph, and is referred to as an annotated data
point. By double-clicking the annotated data point, you can access the textual data.
You may want to include annotated data in notification messages because it provides
administrators with information about the parameters that generated the events.
To create an e-mail notification for a specific parameter that includes annotated data,
you need to perform the following general tasks:
1 Enable recovery actions and notification for the parameter.
2 Create recovery action rules for the parameter.
3 Edit the notification command script for the parameter. (Optional)
Enabling Recovery Actions and Notification

In this task, you enable recovery actions and notification for the CPUCpuUtil
parameter on the managed node. These settings are stored in the arsAction rule.
To Enable Recovery Action and Notification

1 Access the managed node KM menu commands, as described in “Accessing KM
Commands and InfoBoxes” on page 212, and choose the command Event
Management => Alert Settings => Alert Actions => Set For Parameters.
2 Select the application class CPU, instance CPU, and parameter CPUCpuUtil.
3 From the SET EVENT MANAGEMENT VARIABLE: arsAction dialog box, select
Allow Recovery Actions and Trigger NOTIFY_EVENT.
4 To apply your changes, select Make persistent.
Chapter 4 141
Creating Recovery Action Rules

After you enable recovery actions and notification, you need to create the following
recovery action rules.
■ arsCmdType —the type of recovery action command script

■ arsCommand —the notification command script
Since recovery actions execute at the managed node, you create these rules on the
managed node.
About the Recovery Action Command Type (arsCmdType)

You must specify a command type to execute a recovery action. You can specify the
command type for all PATROL objects or for any individual PATROL application,
instance, or parameter. PATROL has two built-in command types, PSL and OS. If you
use a command type other than PSL or OS, the command type must be defined for
the application class. For this example, PSL is the command type.
To Specify the Recovery Action Command Type

1 Access the managed node KM menu, as described in “Accessing KM Commands
and InfoBoxes” on page 212, and choose the command Event Management => Alert
Settings => Local Alert Settings => Recovery Action Command Type => Set For
Parameters.

enter PSL as the command type.
To Specify the Recovery Action Command Script

1 Access the managed node KM menu commands, as described in “Accessing KM
Commands and InfoBoxes” on page 212, and choose the command Event
Management => Alert Settings => Local Alert Settings => Recovery Action Commands
=> Set For Parameters.


enter the following recovery action script:
__udefvar__=annotate_get(\”/\.__appl_class__.\”/\”.__instance__.\”/\”.__param__);
PATROL is now configured to include the annotated data in notification messages

when the parameter CPUCpuUtil alarms. To customize the message format, see the
next step, “Creating Notification Command Scripts” .
Creating Notification Command Scripts

This task describes how to change the notification message format that is defined in
the default notification command script, AS_EVLocalAlertNotify.sh. The default script
is configured to put data from the __udefvar__ variable in the body of the e-mail
message. However, you may want to edit the script to change the body text.
Verify SED Utility Location

To manage carriage returns properly, you may need to edit the SED utility file
location specified in the script.
Refer to Script Comments

The script contains numerous comments. Refer to the comments for specific details.
Using Perl Scripts in Windows

You may be able to generate better formatting in Windows by editing the Perl
notification command script, located in the %PATROL_HOME%/lib/psl directory.
You can verify the notification test by looking at the PATROL KM for Event
Management NotifiedEvents parameter.
Chapter 4 143
Configuring a Recovery Action that Runs Under a Specified Account
To Verify that a Notification is Sent

1 From the PATROL console, double-click the notification server.
The AS_EVENTSPRING application class (Event Management) is displayed.
2 Double-click the AS_EVENTSPRING application class.
3 Double-click the NotifiedEvents parameter.
If the test is successful, an annotated data point is displayed for the notification
server.
Configuring a Recovery Action that Runs

Under a Specified Account
The following scenario describes how to use the PATROL KM for Event Management
to execute a recovery action that runs under a specified OS account. The recovery
action moves archive files when the Oracle parameter ArchFreeSpace enters an
ALARM state.
The example described here is just one of many possible approaches and may not
necessarily be the appropriate approach in your environment. The purpose of this
example is to show one type of recovery action that you can implement.
Assumptions
■ The PATROL KM for Event Management and the PATROL KM for Oracle are
installed and configured on the agent computer.
■ This scenario will consider one agent and, thus, will not address deploying
configurations to multiple remote agents. For more information about deploying
configurations, see the scenario “Sending E-mail Notification When Disk Space is
Low” on page 128.
■ The agent computer is a Unix server running Oracle.
■ The account that you want to run this recovery action under has the proper
permissions to execute the recovery action on the agent computer.
■ The recovery action is executed by means of a PSL command.

■ To encrypt the account password, the PATROL DES encryption is used. However,
you could also choose to use another encryption method as long as the PSL
recovery action is able to decrypt the password. If you use PATROL DES
encryption, the password is decrypted internally.
To configure a recovery action that runs under a specified account, you would
complete the following tasks. The table below shows the location in which step is
completed. An alternative location is also noted. For example, many of the
configuration tasks can be completed within either the PATROL KM for Event
Management or the PATROL Configuration Manager.
Table 29 Sending E-mail Notification for Low Disk Space: Configuration Overview
Alternative PATROL
Step Task PATROL Product Product
1 Testing Recovery Action Script OS (outside of PATROL) NA
2 Enabling Recovery Actions for PATROL console - (PATROL KM PATROL Configuration
ArchFreeSpace on Agent for Event Management) Manager
Computer
3 Defining the Recovery Action PATROL console - (PATROL KM PATROL Configuration
Type for Agent Computer for Event Management) Manager
4 Storing the Encrypted Password PATROL Developer Console None
as a Pconfig Variable
5 Configuring the PSL Recovery PATROL console - (PATROL KM PATROL Configuration
Action for Event Management) Manager
6 Testing the Recovery Action PATROL console None
Testing Recovery Action Script

Test the recovery action script that moves the log files by manually running the script
outside of PATROL using the Unix account that you want the script to run under.
After you verify that the script works, you can automate it with PATROL. For this
example, assume the script is /home/oracle/scripts/arch_backup.ksh.
Chapter 4 145
Enabling Recovery Actions for ArchFreeSpace on Agent

Computer
In this procedure you make sure that recovery actions are enabled for the
ArchFreeSpace parameter on the agent computer. This configuration setting is stored
in the arsAction rule. The following procedure describes how to use the PATROL KM
for Event Management interface to verify that the arsAction rule is configured to
allow recovery actions. You could also use the PATROL Configuration Manager to
create or edit this rule.
To Enable Recovery Actions for ArchFreeSpace on the

Agent Computer
1 From the PATROL console, access the agent computer KM menu commands, as
described in “Accessing KM Commands and InfoBoxes” on page 212, and choose
the command Event Management => Alert Settings => Alert Actions => Set For
Parameters.
2 Select the application class ORACLE_AVAILABILITY, instance Test, and parameter

ArchFreeSpace.
3 From the SET EVENT MANAGEMENT VARIABLE: arsAction dialog box, select
Allow Recovery Actions and Trigger NOTIFY_EVENT.
The following rule is created:
/AS/EVENTSPRING/ORACLE_AVAILABILITY/Test/ArchFreeSpace/arsAction = 6
4 To apply your changes, select Make persistent.
Defining the Recovery Action Type for Agent Computer

The next step is to define the type of recovery action. This setting is stored in the
configuration variable arsCmdType. By default, PATROL supports PSL and OS
command types. The following procedure describes how to set arsCmdType using
the PATROL KM for Event Management interface. You can also create and edit this
variable using the PATROL Configuration Manager.
In this scenario, you need to associate the OS account information with the shell script
that runs the recovery action. To do this, you must use a PSL command. Therefore,
you need to specify arsCmdType as PSL.

To Specify arsCmdType as PSL

the command Event Management => Alert Settings => Local Alert Settings =>
Recovery Action Command Type => Set For Parameters.

ArchFreeSpace.

enter PSL as the command type.
The following rule is created:
/AS/EVENTSPRING/ORACLE_AVAILABILITY/Test/ArchFreeSpace/arsCmdTy
pe = PSL
Storing the Encrypted Password as a Pconfig Variable

For security reasons, encrypt the password of the OS account that is used to execute
the recovery action. You can do this by using PATROL DES encryption and storing
the password as a pconfig variable that you can access from the PSL recovery action.
To Store the Encrypted Password as a Pconfig Variable

1 From the PATROL Developer Console, right-click the managed host and choose
KM Commands => PSL Command.
2 From the PSL Command dialog box, type the following command and click Apply.
encrypted_passwd = encrypt("oracle_password", "DES");

pconfig("REPLACE", "/MYCOMPANY/ORACLE/OSlogin", "oracle ".encrypted_passwd);
The pconfig variable /MYCOMPANY/ORACLE/OSlogin is created and assigned

the value of the encrypted password.
Note that whenever the password is changed, you must update the pconfig variable.
Chapter 4 147
Configuring the PSL Recovery Action

The next step is to assign the PSL recovery action to the arsCommand rule so that
when the ArchFreeSpace parameter enters a WARN or ALARM state, the PSL
recovery action gets the account and encrypted password and uses it to execute the
script located in /home/oracle/scripts/arch_backup.ksh.
To Assign the PSL Recovery Action to the arsCommand Rule

the command Event Management => Alert Settings => Local Alert Settings =>
Recovery Action Commands => Set For Parameters.

ArchFreeSpace.

enter the following PSL code:
oracle_os = nthlinef(pconfig("GET", "/MYCOMPANY/ORACLE/OSlogin"), 2, "");

usern = nthargf(oracle_os, 1, " ", "");
passwd = nthargf(oracle_os, 2, " ", "");
results=execute("OS","/home/oracle/scripts/arch_backup.ksh","",usern,passwd);
print("Results of script follows:\n", results, "\nend...");
;
NOTE
Before entering your own PSL recovery action code, you should test the code for
errors using the testing functionality in the PATROL console.
This PSL recovery action is stored in the following configuration variable:
/AS/EVENTSPRING/ORACLE_AVAILABILITY/test/ArchFreeSpace/arsCommand

Summary of Rules Created

At this point, the following rules have been created.
Table 30 Rules Created: Oracle Recovery Action Example

Rule
/AS/EVENTSPRING/ORACLE_AVAILABILITY/Test/ArchFreeSpace/arsAction = 6
This rule specifies that the ArchFreeSpace parameter associated with the application instance TEST
of the ORACLE_AVAILABILITY application class is enabled for recovery actions. For more
information on the arsAction rule, see “arsAction” on page 161.
/AS/EVENTSPRING/ORACLE_AVAILABILITY/Test/ArchFreeSpace/arsCmdType = PSL
This rule specifies that the ArchFreeSpace parameter associated with the application instance TEST
of the ORACLE_AVAILABILITY application class uses PSL recovery actions. For more information
on the arsCmdType rule, see “arsCmdType” on page 168.
AS/EVENTSPRING/ORACLE_AVAILABILITY/test/ArchFreeSpace/arsCommand =
oracle_os = nthlinef(pconfig("GET", "/MYCOMPANY/ORACLE/OSlogin"), 2, "");

usern = nthargf(oracle_os, 1, " ", "");
passwd = nthargf(oracle_os, 2, " ", "");
results = execute("OS", "/home/oracle/scripts/arch_backup.ksh", "", usern, passwd);
print("Results of script follows:\n", results, "\nend...");
;
This rule specifies the PSL recovery action. For more information on the arsCommand rule, see
“arsCommand” on page 168.
NOTE
To apply these rules to all instances of the ArchFreeSpace parameter on the agent,
replace Test with __ANYINST__.
Testing the Recovery Action

After you assign the PSL recovery action, force the ArchFreeSpace parameter into
alarm and verify that the recovery action script executes.
Chapter 4 149
To Force ArchFreeSpace into ALARM using a PSL Command

2 Choose the KM menu command PSL Command.
3 Enter the PSL command shown below and click Apply.
set("/ORACLE_AVAILABILITY/test/ArchFreeSpace/value",1);
This PSL command sets the value of ArchFreeSpace parameter of the test instance
to 1. This action causes ArchFreeSpace to enter an ALARM state and issue an alert.
4 Determine whether the ArchFreeSpace parameter enters an ALARM state and

whether the recovery action is executed.
If a Problem Occurs
If the PSL editor indicates a syntax problem, see the PATROL Script Language
Reference Summary.

Chapter
5
5 Rules and Configuration Variables
This reference provides a comprehensive listing of PATROL KM for Event
Management settings and rules.
PATROL KM for Event Management allows object-level control (for example,

application of rules) throughout an enterprise. You can deploy these rules using
automation scripting, custom applications, the PATROL Console, or the PATROL
Configuration Manager.
PATROL Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Example: PATROL Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Example: Rule Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Example: PATROL KM for Event Management E-mail Rule . . . . . . . . . . . . . . . . 154
NOTIFY_EVENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
How the NOTIFY_EVENT and REMOTE_NOTIFY_EVENT are Triggered . . . 156
Event Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Order of Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Empty Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Using the Variable userdefined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Event Size Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
NOTIFY_EVENT Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Alert Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
arsAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
alertSystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
allowOverrides. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
loginDeniedIgnoredUsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
useEnvOnlyForCmds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
allowInfoRecoveryActions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
spoolDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
setParameterValue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Local Alert Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
alertResend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
alertLocalCommand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
arsCommand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
arsCmdType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
alertResetOnInit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Chapter 5 151
Remote Alert Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
NOTIFICATION_SERVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
RemoteAgentCommSettings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Notification Target Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
emailTargets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
pagerTargets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
customTargets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
ttTargets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Blackout Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
blackoutPeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
__OVERRIDE__ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Notification Server Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
nsRemoteTargetSetting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Custom Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
msgText . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
msgBody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
CustomId1 and CustomId2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
allowOperator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
appClassSettingsStatusFlag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
disableNotifyAnnotations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
maxEventsToReport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
snmpSettings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
snmpOid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Updated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Primary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Blackout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
pingCmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
pingOkString . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
pingPacketSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
pingAttempts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
pingArgs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
checkerAccount.defaultAccount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Parameter Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
THRESHOLDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
paramSettingsStatusFlag. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
processWildcards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Instance Filtering Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
FilterList Configuration Variable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
FilterType Configuration Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

PATROL Objects
PATROL Objects
Before you use PATROL KM for Event Management, you should have an
understanding of PATROL objects. Table 31 lists the hierarchy and description of
PATROL objects.
Table 31 PATROL Objects Hierarchy

Hierarchy
(1=Highest) Object Description Windows Example Unix Example
1 host host computer of the ntprod1 sunprod1
objects that are being
monitored
2 application type of objects that can NT_LOGICAL_DISKS FILESYSTEM
class be monitored
3 application actual instance of an C: root
instance application class
4 parameter specific parameter of an LDldFreeMegabytes FSCapacity
application instance
Example: PATROL Object

This example assumes an Windows Server with a physical disk partitioned into
multiple logical disks (C: and D:). The logical disk application class contains the
parameter, LDldFreeMegabytes. This parameter shows the number of megabytes of
free space available on the C: logical disk.
Table 32 Example: PATROL Object

Object Example Variable
host the Windows Server /
hosts
application the logical disks /NT_LOGICAL_DISKS
class application class of
the Windows Server
application the logical disk, C: /NT_LOGICAL_DISKS/C:
instance
parameter the parameter /NT_LOGICAL_DISKS/C:/LDldFreeMegabytes
LDldFreeMegabytes
associated with the
logical disk C:
Chapter 5 153
PATROL Objects
Example: Rule Inheritance

You can use PATROL KM for Event Management to define different rules for each
PATROL object. The KM applies inheritance to these rules. Rules defined for objects
at a higher level in the hierarchy are applied to all lower-level objects that do not have
their own rule.
This example contains the following rules:
Rule 1: E-mail User1 for any parameter in alarm on this host (‘/’) that does not have a more
specific rule assigned. User1 is the default e-mail account.
Rule 2: E-mail User2 for any parameter in any instance of the logical disks application class
(/NT_LOGICAL_DISKS) in alarm on this host.
Rule 3: E-mail User3 for any parameter in alarm on this host for the logical disks application
class instance C: (/NT_LOGICAL_DISKS/C:).
Rule 4: E-mail User4 when the parameter LDldFreeMegabytes is in alarm on this host for the
logical disks application class instance C:
(/NT_LOGICAL_DISKS/C:/LDldFreeMegabytes).
Table 33 Example: Rule Inheritance

Object in Alarm Action
/NT_LOGICAL_DISKS/C:/LDldFreeMegabytes User4 receives an e-mail. Rule 4 is specific to
the parameter and instance that are in alarm
/NT_LOGICAL_DISKS/C:/LDldIdleTimePercent User3 receives e-mail. No rule is defined for
the parameter, LDldIdleTimePercent, so the
parameter inherits the rules defined for the
application instance, (logical disk C:), which,
in this case, is Rule 3.
/NT_LOGICAL_DISKS/D:/LDldFreeMegabytes User2 receives an e-mail. No rule is defined
at the instance level for D:, so Rule 2, the
application class rule, applies.
/NT_CPU/CPU_0/CPUprcrProcessorTimePercent User1 receives an e-mail since none of the
lower-level rules apply to this alarm.
Example: PATROL KM for Event Management E-mail Rule

PATROL KM for Event Management uses variables to specify which functions are
performed when events occur for a PATROL object. A variable is defined by a
category, a PATROL object, and a rule.

PATROL Objects
The general variable naming format is the following: category/object/rule
Table 34 PATROL KM for Event Management Variable Definition

Variable Definition
category a grouping of related rules that perform notification
object the PATROL object to which the rule applies
If object is not specified, the rule applies to all objects.

rule the rule to apply to the PATROL object
The following example shows how to send an e-mail when an alarm condition occurs
for a PATROL object:
/AS/EVENTSPRING/ALERT/EMAIL/NT_LOGICAL_DISKS/C:/emailTargetsLocalALARM
category: /AS/EVENTSPRING/ALERT/EMAIL is the category including rules that perform

notification.
object: /NT_LOGICAL_DISKS/C: is the PATROL object, an application instance, to which

the rule is applied.
rule: emailTargetsLocalALARM is the rule indicating who is notified by e-mail when an

alarm condition occurs for the PATROL object /NT_LOGICAL_DISKS/C:
PATROL KM for Event Management uses a special instance name of __ANYINST__

to indicate that a rule for a particular parameter is applied to all instances of the
application class. For example,
/AS/EVENTSPRING/ALERT/EMAIL/NT_SERVICES/__ANYINST__/ServiceStatus/emailTargetsLocal
causes an e-mail to be sent if an alarm occurs for the ServiceStatus parameter on any
monitored service on the Windows Server.
The PATROL object name can also include the hostname when the rule exists on the
notification server but only applies to a particular host. For example, for the
configuration variable
/AS/EVENTSPRING/ALERT/EMAIL/winprod/NT_LOGICAL_DISKS/C:/emailTargetsLocalALARM
the rule only applies for alarm conditions occurring on the Windows Server winprod.
Chapter 5 155
NOTIFY_EVENT
NOTIFY_EVENT
This section describes the event details provided by the NOTIFY_EVENT and
REMOTE_NOTIFY_EVENT.
How the NOTIFY_EVENT and REMOTE_NOTIFY_EVENT are

Triggered
When an agent generates an alert, such as high CPU, it generates a NOTIFY_EVENT
event within it’s own event database. This initial NOTIFY_EVENT event triggers a
corresponding REMOTE_NOTIFY_EVENT event at the Notification Server if the
agent is configured to do so (rule: alertSystem).
Event Details
The event details are collected prior to triggering the initial NOTIFY_EVENT event.
NOTIFY_EVENT events and REMOTE_NOTIFY_EVENT events contain identical
event details.
The alert message is provided as the first NOTIFY_EVENT argument EV_ARG1. The
event details are provided as the second argument, EV_ARG2.
The fields within the event details are comma delimited and are described in
“NOTIFY_EVENT Fields” on page 157.
Order of Fields
The field positioning within the event details does not change. If additional fields are
added, the existing fields remain in the order indicated.
Empty Fields
Some fields, such as custom id or parent instance, may be empty. In addition, if the
NOTIFY_EVENT is triggered from an application class object, fields that relate to the
instance or the parameter appear as __NA__ or are empty.

NOTIFY_EVENT
Using the Variable userdefined

Since the userdefined variable can contain characters that could affect the generation
or processing of a NOTIFY_EVENT, the following changes are made to this variable
prior to triggering the initial NOTIFY_EVENT:
■ the length is limited to 25k

■ new-lines are replaced with -CR-
■ tabs and commas are replaced with spaces
If tabs and commas are needed, you must replace them with non-problematic
characters prior to their use in the PATROL KM for Event Management. For example,
you could replace tabs replaced with -TAB- and then after the event is processed,
insert the tabs back.
Event Size Limitations

If you use the userdefined variable at the remote agent to reword notification
messages, the size of event can exceed PEM (PATROL Event Manager) limit.
NOTIFY_EVENT Fields
This topic describes the NOTIFY_EVENT fields. It also shows the following:
■ the message replacement variables that you can use to reword notification
messages (rule: msgText and msgBody)
■ the environment variables that you can you use in your notifications script (rule:
alertLocalCommand)
Table 35 NOTIFY_EVENT Fields (Part 1 of 4)
Message
Field Replacement Variable Environment Variable Description
Hostname %HOSTNAME% AS_HOSTNAME Hostname of affected
system (e.g., glamis)
IP Address %IPADDRESS% AS_IPADDRESS IP Address for hostname
(e.g., 192.168.1.1)
TCP Port %TCP_PORT% AS_TCP_PORT Affected agent TCP
listening port (e.g., 3181)
UDP Port %UDP_PORT% AS_UDP_PORT Affected agent UDP
listening port (e.g., 3181)
Chapter 5 157
NOTIFY_EVENT

Message
Application Class %APPCLASS% AS_APPCLASS Application Class name
(e.g., ORACLE,
FILESYSTEM,
NT_SERVICES)
Instance Name (sid) %APPINSTANCE% AS_APPINSTANCE Internal instance name (e.g.,
oracle_db1)
Icon Name %ICON_NAME% AS_ICON_NAME Name of the instance as it
appears on the PATROL
console (e.g., oracle_db1)
Parent Instance %PARENT_INSTAN AS_PARENT_INSTAN Instance name that is the
CE% CE parent container of instance
(e.g., /CPU/CPU)
Parameter Name %PARAMETER_NA AS_PARAMETER Parameter name (e.g.,
ME% CPUCpuUtil)
Parameter Status %PARAMETER_STA AS_PARAMETER_STA Parameter status at time of
TUS% TUS alert (e.g., ALARM)
Parameter Value %PARAMETER_VAL AS_PARAMETER_VAL Parameter value at the time
UE% UE of alert (e.g., 99)
Alert Date %DATE% AS_DATE Date the alert occurred. This
is the local date on
hostname.
For example, Sun June 27

2004.
Alert Time %TIME% AS_TIME Time the alert occurred.
This is the local time on
hostname.
Time Zone %TIMEZONE% AS_TIMEZONE Time zone the affected
system is set to (e.g.
US/Eastern/EDT (Unix) or
Eastern Daylight Time
(NT))
Last10 Parameter %LAST10% AS_LAST10 Last 10 parameter values
Values preceding and including
current value, if available.
Values are space delimited.
(e.g., 98.11 97.14 95.87 etc.)
Average of Last 10 %AVE10% AS_AVE10 Average of the last 10
parameter values. (e.g.,
97.21)

NOTIFY_EVENT

Message
Last10 Timestamps %LAST10TS% AS_LAST10TS Times the last 10 parameter
values were collected. These
map directly with the
Last10 values. (Time in
seconds since epoch.)
Last10 Total Period %LAST10TP% AS_LAST10TP Length of time, in minutes,
from the first parameter
value and the last
Event Id %EVENT_ID% AS_EVENT_ID Event id on hostname,
which triggered the
notification. This is the
originating event id such as
from Standard Event 11
(e.g., 5343)
User defined %USERDEFINED% AS_USERDEFINED User defined variable. This
contains the information
stored in the variable
/_my_APPCLASS_APPINS
TANCE_PARAMETER at
the time of the alert
condition
This variable can be set by

any KM or any PSL code
prior to the PATROL object
exceeding a threshold and
generating a
NOTIFY_EVENT event.
OS Type %OS_TYPE% AS_OS_TYPE Operating system type of
hostname (e.g., NT 5.0
Service Pack 1) (V2.4.02 and
later)
Alarm Min %ALARM_MIN% AS_ALARM_MIN Lower threshold of current
alarm range
(V2.4.02 and later)

Alarm Max %ALARM_MAX% AS_ALARM_MAX Upper threshold of current
alarm range
(V2.4.02 and later)
Chapter 5 159
NOTIFY_EVENT

Message
Custom Id1 %CUSTOM_ID1% AS_CUSTOM_ID1 Custom identifier assigned
to object
(V2.4.02 and later)

Custom Id2 %CUSTOM_ID2% AS_CUSTOM_ID2 Custom identifier assigned
to object
(V2.4.02 and later)

PATROL Agent %AGENT_VERSION AS_AGENT_VERSION The version of the PATROL
version % Agent running on the host.
PATROL Home %PATROL_HOME% AS_PATROL_HOME The PATROL installation
directory.
Event catalog %EVENT_CATALO AS_EVENT_CATALOG The PATROL event catalog
G% file.
Event class %EVENT_CLASS% AS_EVENT_CLASS The event class of the event.
For example, 9 or 11.
Event status %EVENT_STATUS% AS_EVENT_STATUS The status of the event. For
example, Open.
Event severity %EVENT_SEVERITY AS_EVENT_SEVERITY The event severity. For
% example, 4.
Event type %EVENT_TYPE% AS_EVENT_TYPE The type of event. For
example, ALARM.
The following variables are not available from event details; they are provided as
message placement and environment variables only at a notification server.
Table 36 Notification Server Message Replacement Variables

Message Replacement Variable Environment Variable Description
%NOTIFY_EVENT_ID% AS_NOTIFY_EVENT_ID Event Manager event id for the
NOTIFY_EVENT (e.g., 5439)
%EVENT_TYPE% AS_EVENT_TYPE Event Manager event type of the
NOTIFY_EVENT (e.g., ALARM)
%EVENT_STATUS% AS_EVENT_STATUS Event Manager event status of the
NOTIFY_EVENT (e.g., OPEN)

Alert Rules
The following variables are available only as environment variables that can be used
by a notification script.
Table 37 Notification Server Environment Variables

Environment Variable Description Example
AS_NOTIFICATION_TYPE notification type e-mail, page
AS_NOTIFICATION_TARGETS notification targets dave@anyco.com
AS_NOTIFICATION_MSG reworded message High CPU on glamis at 99.54%
AS_NOTIFICATION_FILE filename on hostname that /usr/patrol/CPU_CPU_CPUC
contains recovery action output puUtil_20020404111134.out
Alert Rules
Each PATROL object (computer, application class, instance, and parameter) can have
its own alert settings.
arsAction
You can use the arsAction rule to specify the actions to perform when an alert
condition occurs for a specific PATROL object.
Table 38 arsAction Rule

Rule arsAction
Configuration Variables ■ /AS/EVENTSPRING/object/arsAction
■ /AS/EVENTSPRING/object/arsActionINFORMATION
■ /AS/EVENTSPRING/object/arsActionWARNING
■ /AS/EVENTSPRING/object/arsActionALARM
Values 3 bit mask
0 - Do nothing
2 - Allow recovery actions
4 - Trigger NOTIFY_EVENT (Perform notification)
6 - Allow recovery actions and notification
Menu Command Access Event Management => Alert Settings => Alert Actions
NOTE
To allow recovery actions for INFORMATION events, you must also set the
allowInfoRecoveryActions variable to 1.
Chapter 5 161
Alert Rules
alertSystem
You can use the alertSystem rule to specify the location of the notification server that
performs the notification for the specified PATROL object. The notification server can
be local, remote, both, or none.
Table 39 alertSystem Rule

Rule alertSystem
Configuration Variable ■ /AS/EVENTSPRING/ALERT/object/alertSystem
■ /AS/EVENTSPRING/ALERT/object/alertSystemINFORMATION
■ /AS/EVENTSPRING/ALERT/object/alertSystemWARNING
■ /AS/EVENTSPRING/ALERT/object/alertSystemALARM
Values Remote
Local
Local, Remote
None
For a detailed description of these options, see Table 40 on page 163.

Support supported by PATROL KM for Event Management version 2.4.05 or later
Menu Command Event Management => Alert Settings => Notification System
Access

Alert Rules
Table 40 Notification System Options

Location Description
LOCAL Send alerts to a notification server on the same computer as the PATROL Agent that is
doing the monitoring. This configuration is sufficient for sending e-mail notification,
but most systems do not have paging capabilities. Paging usually requires the
REMOTE option.
Using the LOCAL option, notification failures have no impact on other systems. Local
notification is potentially more reliable since it requires fewer intermediate
components (for example, the network connection, the remote notification server).
Some disadvantages to using the LOCAL option are
■ Notification scripts and procedures are required on each computer.

■ Most systems are unable to perform paging locally.
■ Notification targets (for example, who is paged or e-mailed) must be maintained
for each computer.
REMOTE Specifies that alerts are sent to a notification server that is on a different computer. The
REMOTE option allows you to centralize notification and simplifies the management
of settings and procedures. However, if the notification server fails, alerts from many
monitored machines are not sent. One way to reduce this risk is to configure a backup
notification server. If the primary notification server is unavailable, PATROL
automatically fails over to the backup notification server.
LOCAL, You can choose both LOCAL and REMOTE. You may need to select this option if you
REMOTE want to send an e-mail message or page from the local box, but still forward the event
to an enterprise console.
NONE PATROL KM for Event Management does not perform notification.
allowOverrides
You can use the allowOverrides rule to disable the use of rule overrides
(__OVERRIDE__).
Table 41 allowOverrides Rule

Rule allowOverrides
Configuration Variable /AS/EVENTSPRING/allowOverrides
Values 0 = do not allow rule overrides
1 = allow rule overrides (default)
Example 1
Support supported by PATROL KM for Event Management version 2.4.05 or
later
Menu Command Access Not available
Chapter 5 163
Alert Rules
loginDeniedIgnoredUsers
Use the LoginDeniedIgnoredUsers configuration variable to specify the users to
ignore when a user name is denied login to the agent because of ACL restrictions or
invalid login information. When you use this variable, the specified user account does
not generate invalid login errors even if it is unable to login to the agent.
NOTE
If you use this configuration variable, you must add the built-in users EventSpring
and EventSpring_Availability_Check to the list of usernames. By default, if you don’t
use the LoginDeniedIgnoredUsers configuration variable, then any login errors
caused by these built-in users are ignored. However, if you do use the
LoginDeniedIgnoredUsers configuration variable, login errors caused by these users
are not ignored unless you also add them to the comma-delimited list of usernames.
Table 42 LoginDeniedIgnoredUsers Rule

Rule loginDeniedIgnoredUsers
Configuration /AS/EVENTSPRING/loginDeniedIgnoredUsers
Variable
Values comma delimited string
Examples patrol_checker,EventSpring,EventSpring_Availability_Check
Menu Command Not available
Access
useEnvOnlyForCmds
Use the useEnvOnlyForCmds rule to indicate whether PATROL KM for Event
Management should run all operating system commands (for example, notification
and recovery) with command-line arguments.
Table 43 useEnvOnlyForCmds Rule

Rule useEnvOnlyForCmds
Configuration /AS/EVENTSPRING/useEnvOnlyForCmds
Variable
Values 0 = run commands with command-line arguments (default)
1 = do not use command-line arguments
Example 1
Menu Command Event Management => Alert Settings => Local Alert Settings => Notification
Access Command

Alert Rules
allowInfoRecoveryActions
Use the allowInfoRecoveryActions rule to indicate whether the PATROL KM for
Event Management can perform recovery actions for INFORMATION events. For
example, an INFORMATION event is generated when a parameter goes from an
ALARM state to an OK state.
Table 44 useEnvOnlyForCmds Rule

Rule allowInfoRecoveryActions
Configuration /AS/EVENTSPRING/allowInfoRecoveryActions
Variable
Values 0 = recovery actions not enabled for INFORMATION events (default)
1 = recovery actions enabled for INFORMATION events
Example 0
Support supported by PATROL KM for Event Management version 2.7or later
Menu Command None
Access
spoolDirectory
Use the spoolDirectory configuration variable to specify the directory where
PATROL KM for Event Management reports are stored (for example, parameter
reports and recovery action output).
Table 45 SpoolDirectory Rule

Rule spoolDirectory
Configuration Variable /AS/EVENTSPRING/spoolDirectory
Values directory path
The default location is the directory specified in the PATROL_HOME

environment variable.
Example /usr/local/patrol_reports
later
Chapter 5 165
Local Alert Settings
setParameterValue
You can use the setParameterValue rule to set the value of an active parameter.
Table 46 SetParameterValue Rule

Rule setParameterValue
Configuration /AS/EVENTSPRING/setParameterValue
Variable
Format PARAMETER=VALUE,DELAY=N,...,PARAMETER=VALUE,DELAY=N
■ parameter = a PATROL object

(/APPLICATION_CLASS/INSTANCE/PARAMETER). When you use an
instance name of __ANYINST__, the KM selects a valid instance.
■ VALUE = ALARM, WARM, OK, CLEAR. If you specify CLEAR, the KM

attempts to set the parameter to a value that is not within an active alarm range.
■ DELAY = the time in seconds that the KM waits between each parameter set
(optional).
Example /CPU/CPU/CPUCpuUtil=ALARM,.../CPU/CPU/CPUCpuUtil=CLEAR,DELAY
=5

You can use the Local Alert Settings menu commands to specify configurations or
rules that apply to the PATROL Agent where the alert occurs. Local settings can
include external procedures (for example, script, batch file, or other OS command) to
execute for local notification and recovery actions. Local notification settings (for
example, locally defined targets and the notification command) are used only if the
value of the Notification System is set to Local. If the Notification System is set to
Remote, local alert settings, including local notification targets, are not forwarded to
the notification servers.

alertResend
You can use the alertResend rule to specify the number of times the agent should
resend outstanding alerts. You can configure alarm and warning alerts to have
different resend values. Alerts are resent at the interval specified by the
ResendAlertQueue parameter polling time and contain current alert information,
such as, parameter value and status. A resend value of -1 causes PATROL KM for
Event Management to resend outstanding alerts for object until the alert condition
clears.
Table 47 alertResend Rule

Rule alertResend
Configuration Variable /AS/EVENTSPRING/ALERT/object/alertResend
Values Alarm_Resends,Warning_Resends
Example 2,1
Menu Command Access Event Management => Alert Settings => Local Alert Settings => Alert
Resend
alertLocalCommand
You can use the alertLocalCommand rule to specify a script or program to perform
notification, such as paging or e-mail. PATROL KM for Event Management contains
sample notification scripts located in the PATROL PSL directory. The same
notification command is typically set at the root (/) object level so that it applies to all
PATROL objects (for example, application classes, instances, and parameters) with an
ALERT status.
Table 48 alertLocalCommand Rule

Rule alertLocalCommand
Configuration Variable /AS/EVENTSPRING/ALERT/object/alertLocalCommand
Values notification script or program
Example /usr/patrol/my_notify.sh
Support supported by PATROL KM for Event Management version 2.4.05or later
Menu Command Event Management => Alert Settings => Local Alert Settings =>
Access Notification Command
Chapter 5 167
arsCommand
You can use the arsCommand rule to specify a script or program that performs
recovery procedures pertaining to the PATROL object with an ALERT status.
PATROL KM for Event Management contains sample notification scripts located in
the PATROL PSL directory.
You can specify that the recovery action command executes only for a specific alert
status, such as INFORMATION, WARN, or ALARM by appending the status to the
variable name. However, to run recovery actions for INFORMATION events, you
must also set the variable allowInfoRecoveryActions to 1.
Table 49 arsCommand Rule

Rule arsCommand
Configuration Variable /AS/EVENTSPRING/object/arsCommand
/AS/EVENTSPRING/object/arsCommandINFORMATION
/AS/EVENTSPRING/object/arsCommandWARNING
/AS/EVENTSPRING/object/arsCommandALARM
Values recovery script or program
Example /usr/patrol/filesystem_recovery.sh
Menu Command Event Management => Alert Settings => Local Alert Settings => Recovery
Access Action Commands
NOTE
You must enable recovery actions using the Alert Actions menu command for the KM
to execute these actions. See “arsAction” on page 161.
arsCmdType
You can use the arsCmdType rule to specify the command type to use when
executing the recovery action command. This command is typically used when the
recovery action requires special KM information, such as the PATROL password
used to log into a database. The AS_EVENTSPRING application class contains a
sample PATROL command type.

Remote Alert Settings
Table 50 arsCmdType Rule

Rule arsCmdType
Configuration Variable ■ /AS/EVENTSPRING/object/arsCmdType
■ /AS/EVENTSPRING/object/arsCmdTypeINFORMATION
■ /AS/EVENTSPRING/object/arsCmdTypeWARNING
■ /AS/EVENTSPRING/object/arsCmdTypeALARM
Values command type
Example PSL
Menu Command Event Management => Alert Settings => Local Alert Settings => Recovery
Access Action Command Type
alertResetOnInit
You can use the alertResetOnInit rule to specify whether the agent should, upon an
agent restart, close outstanding events (for example, alarms or warnings) that existed
prior to the agent being shutdown. You may want to close these events because they
are no longer applicable. You cannot apply this rule to specific PATROL objects. By
default, this option is not enabled.
Table 51 alertResetOnInit Rule

Rule alertResetOnInit
Configuration Variable /AS/EVENTSPRING/ALERT/alertResetOnInit
Values 0 - Do not send reset alert
1 - Send reset alert
Menu Command Access Event Management => Alert Settings => Local Alert Settings => Send
Reset on Init

You can use the Remote Alert Settings menu commands to specify the notification
servers and the communication settings you want to use for remote notifications.
NOTE
The notification server must be running when you set up PATROL KM for Event
Management alert rules on remote agents.
Chapter 5 169
NOTIFICATION_SERVER
You can use the following notification server configuration variables to identify the
primary and backup notification servers for the remote agents.
■ NOTIFICATION_SERVER1.defaultAccount—the user name and password for the

primary notification sever
■ NOTIFICATION_SERVER2.defaultAccount—the user name and password for the
backup notification sever
■ NOTIFICATION_SERVER1—hostname and port number of the primary
notification server
■ NOTIFICATION_SERVER2—hostname and port number of the backup
notification server
Table 52 Remote Alert Settings: Configure Notification Servers Configuration Variable
/AS/EVENTSPRING/NOTIFICATION_SERVER1.defaultAccount (primary)
Configuration Variable /AS/EVENTSPRING/NOTIFICATION_SERVER2.defaultAccount (backup)
Values user/encrypted password
Example patrolns/FB0A195D062696
Menu Command Access Event Management => Quick Config => Remote Agent
Table 53 Remote Alert Settings: Configure Notification Servers Configuration Variable

/AS/EVENTSPRING/NOTIFICATION_SERVER1 (primary)
Configuration Variable /AS/EVENTSPRING/NOTIFICATION_SERVER2 (backup)
Values host,agent port number
Example ns1,3181
Menu Command Access Event Management => Quick Config => Remote Agent
RemoteAgentCommSettings
You can use the RemoteAgentCommSettings configuration variable to configure the
remote communication settings for the following situations:
■ the agent sending events to a notification server

■ an availability monitor checking the availability of monitored agents
Table 54 Remote Alert Settings: Remote Communication Settings Configuration Variable
Configuration Variable /AS/EVENTSPRING/RemoteAgentCommSettings
Values TCP
UDP,timeout,retries

Notification Target Rules
Table 54 Remote Alert Settings: Remote Communication Settings Configuration Variable

Example UDP,100,3
Menu Command Event Management =>Alert Settings => Remote Alert Settings => Remote
Comm Settings

You can use emailTargets rules to specify whom to notify (the target) when an alert
condition occurs for a PATROL object. You can specify a different target for
WARNING, ALARM, and INFORMATION conditions.
Notification targets are typically defined only on the notification server. If you define
targets on the remote agent, you must use a remote notification system and remote
notification targets. Remote notification targets are forwarded to the notification
server for processing.
TIP
To prevent notification, use a special target name of NONE or leave the target blank.
For example, if you set a default target for an application class and set the target to
NONE for a particular instance or parameter in that application class, notifications for
that instance or parameter are not sent.
NOTE
The target type, such as page or e-mail, can be changed to any type of notification
action. For example, trouble ticket targets are not required for trouble tickets. The
target can perform any task programmed in the notification command.
emailTargets
You can use emailTargets rules to specify e-mail accounts as notification targets.
Chapter 5 171
Table 55 Notification Targets: Email Target Configuration Variable

Rule: emailTargets
Configuration /AS/EVENTSPRING/ALERT/EMAIL/object/emailTargetsLocalINFORMATION
Variable /AS/EVENTSPRING/ALERT/EMAIL/object/emailTargetsLocalWARNING
/AS/EVENTSPRING/ALERT/EMAIL/object/emailTargetsLocalALARM
/AS/EVENTSPRING/ALERT/EMAIL/object/emailTargetsLocalESCALATED
/AS/EVENTSPRING/ALERT/EMAIL/object/emailTargetsLocal
/AS/EVENTSPRING/ALERT/EMAIL/object/emailTargetsRemoteINFORMATIO
N
/AS/EVENTSPRING/ALERT/EMAIL/object/emailTargetsRemoteWARNING
/AS/EVENTSPRING/ALERT/EMAIL/object/emailTargetsRemoteALARM
/AS/EVENTSPRING/ALERT/EMAIL/object/emailTargetsRemote
Values email_target1,email_target2,…mail_targetn
Example patrol,admin@company.com
Menu Event Management => Alert Settings => Notification Targets => Email
Command
Access
pagerTargets
You can use pagerTargets rules to specify one or more pagers as notification targets.
Table 56 Notification Targets: Pager Target Configuration Variable

Rule pagerTargets
Configuration /AS/EVENTSPRING/ALERT/PAGER/object/pagerTargetsLocalINFORMATIO
Variable N
/AS/EVENTSPRING/ALERT/PAGER/object/pagerTargetsLocalWARNING
/AS/EVENTSPRING/ALERT/PAGER/object/pagerTargetsLocalALARM
/AS/EVENTSPRING/ALERT/PAGER/object/pagerTargetsLocalESCALATED
/AS/EVENTSPRING/ALERT/PAGER/object/pagerTargetsLocal
/AS/EVENTSPRING/ALERT/PAGER/object/pagerTargetsRemoteINFORMATI
ON
/AS/EVENTSPRING/ALERT/PAGER/object/pagerTargetsRemoteWARNING
/AS/EVENTSPRING/ALERT/PAGER/object/pagerTargetsRemoteALARM
/AS/EVENTSPRING/ALERT/PAGER/object/pagerTargetsRemote
Values pager_target1,pager_target2,…pager_targetn
Example adminpg
Menu Event Management => Alert Settings => Notification Targets => Pager
Command
Access

customTargets
You can use the customTargets rule to specify custom notification targets.
Table 57 Notification Targets: Custom Target Configuration Variable

Rule customTargets
Configuration /AS/EVENTSPRING/ALERT/CUSTOM/object/customTargetsLocalINFORMATI
Variable ON
/AS/EVENTSPRING/ALERT/CUSTOM/object/customTargetsLocalWARNING
/AS/EVENTSPRING/ALERT/CUSTOM/object/customTargetsLocalALARM
/AS/EVENTSPRING/ALERT/CUSTOM/object/customTargetsLocalESCALATED
/AS/EVENTSPRING/ALERT/CUSTOM/object/customTargetsLocal
/AS/EVENTSPRING/ALERT/CUSTOM/object/customTargetsRemoteINFORMA
TION
/AS/EVENTSPRING/ALERT/CUSTOM/object/customTargetsRemoteWARNIN
G
/AS/EVENTSPRING/ALERT/CUSTOM/object/customTargetsRemoteALARM
/AS/EVENTSPRING/ALERT/CUSTOM/object/customTargetsRemote
Values custom_target1,custom_target2,…custom_targetn
Example glamis
Menu Event Management => Alert Settings => Notification Targets => Custom
Command
ttTargets
You can use ttTargets rules to specify trouble ticket notification targets.
Table 58 Notification Targets: TT Targets Configuration Variable

Rule ttTargets
Configuration /AS/EVENTSPRING/ALERT/TT/object/ttTargetsLocalINFORMATION
Variable /AS/EVENTSPRING/ALERT/TT/object/ttTargetsLocalWARNING
/AS/EVENTSPRING/ALERT/TT/object/ttTargetsLocalALARM
/AS/EVENTSPRING/ALERT/TT/object/ttTargetsLocalESCALATED
/AS/EVENTSPRING/ALERT/TT/object/ttTargetsLocal
/AS/EVENTSPRING/ALERT/TT/object/ttTargetsRemoteINFORMATION
/AS/EVENTSPRING/ALERT/TT/object/ttTargetsRemoteWARNING
/AS/EVENTSPRING/ALERT/TT/object/ttTargetsRemoteALARM
/AS/EVENTSPRING/ALERT/TT/object/ttTargetsRemote
Values trouble_tix_target1,trouble_tix_target2,…trouble_tix_targetn
Example ttpatrol
Menu Command Event Management => Alert Settings => Notification Targets => Trouble Ticket
Chapter 5 173
Blackout Settings
NOTE
If the type of alert condition (INFORMATION, WARNING, ALARM, or
ESCALATED) is not specified for a notification target (for example,
/AS/EVENTSPRING/ALERT/EMAIL/object/emailTargetsRemote), notification
occurs for all alert conditions.
Blackout Settings
You can use the Blackout Periods menu commands to prevent notification during a
specified time period, even if an alert condition occurs. You can specify multiple
blackout times per day. Blackout periods apply to notification only and can be
applied to most PATROL objects. For more information about blackout periods, see
“Configuring Blackout Periods” on page 115.
blackoutPeriod
You can use the blackoutPeriod configuration variable to specify the start and stop
times of a blackout period for a specified PATROL object.
Table 59 Blackout Periods Configuration Variable

Rule blackoutPeriod
Configuration Variable /AS/EVENTSPRING/BLACKOUT/object/blackoutPeriod
Values day1 start1 stop1,day2 start2 stop2
Note: Start and stop times are in seconds past midnight.

Example Sat 3600 7200,Wed 3600 7200
Menu Command Access Event Management => Alert Settings => Blackout Periods
__OVERRIDE__
You can use the __OVERRIDE__ configuration variable to override PATROL KM for
Event Management rules based on the time of day. Using this command, you can
establish multiple overrides per day.

Notification Server Settings
Table 60 Overrides Configuration Variable

Configuration Variable /AS/EVENTSPRING/__OVERRIDE__/object/rule
Values day start stop=value_for_rule
Example Sat 0 86399,Sun 0 86399=oncallpager
Menu Command Access Event Management => Alert Settings => Overrides
Notification Server Settings

You can use the Notification Server Settings menu command to perform actions
specific to a notification server.
nsRemoteTargetSetting
You can use the nsRemoteTargetSetting configuration variable to specify the
handling of remote targets received by the notification server. Table 61 on page 175
lists the options you can specify for the remote target setting.
Table 61 Notification Server Settings: Remote Target Setting Configuration Variable

Rule nsRemoteTargetSetting
Configuration Variable /AS/EVENTSPRING/NS/nsRemoteTargetSetting
Values ■ Ignore—remote targets are ignored. Notification is sent only to the
local targets defined at the notification server.
■ Merge (default)—remote targets are merged with local targets

defined at the notification server. For example, an email notification
is sent to both the email addresses defined at the remote agent and
the email addresses defined at the notification server.
■ Override—notification is sent only to the targets defined at the

remote agent.
■ Forward—remote targets are forwarded. Use this option when you

are using cascading notification servers in which one notification
server is forwarding events to another notification server.
Example Merge
Menu Command Access Event Management => Alert Settings => Notification Server Settings =>
Remote Target Settings
Chapter 5 175
Custom Settings
Custom Settings
You can use the following custom settings to reword notification messages and to
assign custom identifiers to an object.
msgText
You can use the msgText rule to specify the message format for the subject line of the
notification message. You can specify different formats for different types of alerts
and for specific PATROL objects (applications, instances, or parameters).
Table 62 msgText Configuration Variable

Rule msgText
Configuration /AS/EVENTSPRING/ALERT/MSG/object/msgText
Variable /AS/EVENTSPRING/ALERT/MSG/object/msgTextINFORMATION
/AS/EVENTSPRING/ALERT/MSG/object/msgTextWARNING
/AS/EVENTSPRING/ALERT/MSG/object/msgTextALARM
Values message_replacement_text
message_replacement_variables
message_replacement_text_and_variables
Example %HOSTNAME% has CPU Processor time of %PARAMETER_VALUE% for time
zone %TIMEZONE% for %OS_TYPE%
For more information about replacement variables, see “NOTIFY_EVENT Fields”

on page 5-157.
Menu Event Management => Alert Settings => Alert Messages => Default Message
Command Format
Access
NOTE
If you do not specify INFORMATION, WARNING or ALARM, the same message
format is used for all events.

Custom Settings
msgBody
You can use the msgBody rule to specify the message format for the body of the
notification message. You can specify different formats for different types of alerts
and for specific PATROL objects (applications, instances, or parameters).
Table 63 msgBody Configuration Variable

Rule msgText
Configuration /AS/EVENTSPRING/ALERT/MSG/object/msgBody
Variable /AS/EVENTSPRING/ALERT/MSG/object/msgBodyINFORMATION
/AS/EVENTSPRING/ALERT/MSG/object/msgBodyWARNING
/AS/EVENTSPRING/ALERT/MSG/object/msgBodyALARM
Values message_replacement_text
message_replacement_variables
message_replacement_text_and_variables
Example %HOSTNAME% has CPU Processor time of %PARAMETER_VALUE% for time
zone %TIMEZONE% for %OS_TYPE%
For more information about replacement variables, see Table 35,

“NOTIFY_EVENT Fields,” on page 5-157.
Menu Event Management => Alert Settings => Alert Messages => Default Message
Command Format
Access
NOTE
If you do not specify INFORMATION, WARNING or ALARM, the same message
format is used for all events.
An example of a reworded message template is:
%HOSTNAME% has CPU Processor time of %PARAMETER_VALUE% for time zone %TIMEZONE% for
%OS_TYPE%
At run time, the message could be displayed as:
Mercury has CPU Processor time of 99 for time zone Eastern Standard Time for NT 5.0
Service Pack 1
Chapter 5 177
Custom Settings
NOTE
A special instance name of __ANYINST__ can be used for all instances of a
parameter. If object is not specified, then the configuration variable defines the default
message format.
CustomId1 and CustomId2

You can use the CustomId1 and CustomId2 configuration variables to specify custom
identifiers. These variables are commonly used to identify an application, such as
Oracle, or a geographical area.
Table 64 Custom Configuration Variables

Configuration /AS/EVENTSPRING/object/CustomId1
Variable /AS/EVENTSPRING/object/CustomId2
Values custom_identifier
Example financial_app
Menu Command Event Management => Alert Settings => Custom Identifiers => CustomID1
Access Event Management => Alert Settings => Custom Identifiers => CustomID2
allowOperator
You can use the allowOperator configuration variable to control which PATROL KM
for Event Management menu commands an operator can execute from a PATROL
Operator console.

Custom Settings
Table 65 allowOperator Variable

Configuration
Variable /AS/EVENTSPRING/MENU_COMMANDS/allowOperator
Values ■ all - all menu commands
■ availability - Availability menu commands
■ configNS - Quick Config -> Notification Server menu command
■ configRemoteAgent - Quick Config -> Remote Agent menu command
■ thresholds - Threshold menu commands
■ interval - Poll time menu commands
■ arsAction - Alert Action menu commands
■ arsCommand - Recovery Action menu commands
■ arsCmdType - Recovery Action Command Type menu commands
■ overrides - Override related menu commands
■ customId - Custom Identifier menu commands
■ alertLocalCommand - Notification Command menu command
■ alertSystem - Notification System menu command
■ alertResend - Alert Resend menu command
■ alertResetOnInit - SendResetOnInit menu command
■ msgText - Alert Messages menu commands
■ emailTargetsLocal - Local Email Target menu commands
■ emailTargetsRemote - Remote Email Target menu commands
■ pagerTargetsLocal - Local Pager Target menu commands
■ pagerTargetsRemote - Remote Pager Target menu commands
■ ttTargetsLocal - Local Trouble Ticket Target menu commands
■ ttTargetsRemote - Remote Trouble Ticket Target menu commands
■ customTargetsLocal - Local Custom Target menu commands
■ customTargetsRemote - Remote Custom Target menu commands
■ blackoutPeriod - Blackout Periods menu commands
■ instanceFiltering - Instance Filtering menu commands
All configuration changes take affect immediately once they have been applied. The
following are exceptions:
■ arsAction, only in certain circumstances

■ RemoteAgentCommSettings
These configuration settings are updated by restarting the PATROL Agent after
applying the configuration change.
Chapter 5 179
Custom Settings
active
You can use the active configuration variable to set the status of an application class.
NOTE
You cannot use this setting to activate an application class that is inactive by default
in the KM. If you use the PATROL KM for Event Management to activate such an
application class, the application class again becomes inactive after an agent restart.
Table 66 active Variable

Configuration
Variable /AS/EVENTSPRING/APPLICATION_CLASSES/object/active
Values 0 = set active status to 0 (disable application class)
1 = set active status to 1 (perform pre-discovery for the application class)
2 = set active status to 2 (perform full discovery for the application class)
Support supported by PATROL KM for Event Management version 2.4.05.02 or later
appClassSettingsStatusFlag
You can use the appClassSettingsStatusFlag to indicate whether PATROL KM for
Event Management application class settings are used.
NOTE
You cannot use this setting to activate an application class that is inactive by default
in the KM. If you use the PATROL KM for Event Management to activate such an
application class, the application class again becomes inactive after an agent restart.
Table 67 appClassSettingsStatusFlag Variable

Configuration /AS/EVENTSPRING/APPLICATION_CLASSES/STATUSFLAGS/appClassSettingStatusF
Variable lag
Values 0 = use KM defaults
1 = use PATROL KM for Event Management application class settings
2 = refresh active rules

Availability
disableNotifyAnnotations
You can use the disableNotifyAnnotations variable to disable notification annotations
for the NotifiedEvents parameter. By default, this variable is not provided;
annotations are performed. To disable annotations, add this configuration variable to
the agent using the PATROL Configuration Manager and set the value to 1.
Table 68 disableNotifyAnnotations
Configuration Variable /AS/EVENTSPRING/disableNotifyAnnotations
Values 0 = don’t disable annotations (default)
1 = disable annotations
Example 1
Menu Command Access None
later
maxEventsToReport
You can use the maxEventsToReport variable to specify the maximum number of
NOTIFY_ EVENTS events to report in the console system output window when you
run the PATROL KM for Event Management menu command Reports => All NOTIFY
EVENTS.
Table 69 disableNotifyAnnotations
Configuration Variable /AS/EVENTSPRING/maxEventsToReport
Values Any integer value. The default value is 100.
Example 100
later
Availability
You can use the availability settings to specify the agents and hosts that PATROL
monitors for availability.
Chapter 5 181
Availability
Targets
You can use the Targets configuration variable to specify the host to be monitored.
You can also use this menu command to change the default SNMP settings and the
SNMP Object ID.
Table 70 Add Target Configuration

Configuration Variable /AS/EVENTSPRING/AVAILABILITY/Targets(Targets2)
Values host PATROL_Agent_port SNMP_port
Example glamis 3181 161,mirage - 161
Menu Command Access Event Management => Availability => Add Target
snmpSettings
You can use the snmpSettings configuration variable to specify the SNMP ping
information for the PATROL Agent on the managed system that you want to monitor
for availability.
Configuration Variable /AS/EVENTSPRING/AVAILABILITY/snmpSettings

Values SNMP_Community SNMP_Timeout SNMP_Retries
Example public,500,3
snmpOid
You can use the snmpOid configuration variable to specify the SNMP Object ID on
the managed system that you want to monitor for availability. PATROL uses the
SNMP object ID only when checking the availability of the remote agent on the
managed system. It uses the object ID when making an SNMP call to the agent and
checking for a response. You can use the default object ID or provide any other valid
SNMP object ID.
Configuration Variable /AS/EVENTSPRING/AVAILABILITY/snmpOid
Values SNMP_ObjectID
Example .1.3.6.1.2.1.1.3.0

Availability
Updated
Use the Updated configuration variable to indicate that changes have been made to
the availability targets and availability checkers.
NOTE
The KM automatically sets the Updated variable to 1 whenever you make a change
using the Availability menu command.
Table 71 Add Target: Updated Flag Configuration

Configuration Variable /AS/EVENTSPRING/AVAILABILITY/Updated
Values 0 - Ignore changes to Targets and Primary configuration variables
1 - Enable changes to Targets and Primary configuration variables
Primary
You can use the Primary configuration variable to specify the primary availability
monitor.
Table 72 Primary Configuration Variable

Configuration Variable /AS/EVENTSPRING/AVAILABILITY/Primary
Values host_primary_monitor PATROL_Agent_port SNMP_port
Example pismo 3181 161
Menu Command Access Event Management => Availability => Failover Settings => Identify
Primary
NOTE
The PATROL Agent that you use to run the Identify Primary menu command
becomes the backup monitor.
Blackout
You can use the Blackout configuration variable to specify time periods to stop
monitoring of a host or an agent.
Chapter 5 183
Availability
NOTE
If you specify one or more availability blackouts for a PATROL Agent or host, the KM
stops monitoring that agent or host during the blackout period.
Table 73 Blackout Configuration Variable

Configuration Variable /AS/EVENTSPRING/AVAILABILITY/Blackouts/host_port
Values day1 start1 stop1, day2 start2 stop2
Example Sat 3600 7200,Wed 3600 7200
Menu Command Access Event Management => Availability => Blackout Periods
pingCmd
You can use the pingCmd configuration variable to specify the operating system
command to use when checking host availability.
Table 74 PingCmd Configuration Variable

Configuration Variable /AS/EVENTSPRING/AVAILABILITY/pingCmd
Values absolute_path_to_OS_ping_command
Example /usr/patrol/myping.sh
Menu Command Access Event Management => Availability => Ping Command
pingOkString
The pingOkString configuration variable is the string that appears in the output of the
pingCmd.
Table 75 pingOKString Configuration Variable

Configuration Variable /AS/EVENTSPRING/AVAILABILITY/pingOkString
Values ping output
Example bytes

Availability
pingPacketSize
The pingPacketSize configuration variable defines the packet size of the ping
command in bytes.
Table 76 pingPacketSize Configuration Variable

Configuration Variable /AS/EVENTSPRING/AVAILABILITY/pingPacketSize
Values number of bytes; if not specified, the default value is 32 bytes
Example 32
This variable is not supported on OpenVMS or iSeries.
pingAttempts
The pingAttempts configuration variable defines the number of pings attempted.
Table 77 pingAttempts Configuration Variable

Configuration Variable /AS/EVENTSPRING/AVAILABILITY/pingAttempt
Values number of attempts; if not specified, the default value is 2 attempts
Example 2
This variable is not supported on OpenVMS or iSeries.
pingArgs
The pingArgs configuration variable allows you to use custom ping arguments. The
arguments defined by pingArgs are appended to the ping command defined by the
configuration variable pingCmd.
If you assign a value to the configuration variable pingArgs, the configuration

variables pingAttempts and pingPacketSize are ignored.
For more information about using this variable, see Table 78 on page 186 or “To
Specify Ping Command Arguments” on page 93.
Chapter 5 185
Parameter Settings
Table 78 pingArgs Configuration Variable

Configuration Variable /AS/EVENTSPRING/AVAILABILITY/pingArgs
Values ping command arguments
Example -n 2 -|32
checkerAccount.defaultAccount
You can use the checkerAccount.defaultAccount configuration variable to specify the
account to use when performing pings against other PATROL Agents.
Table 79 Checker Account Configuration Variable

Configuration Variable /AS/EVENTSPRING/AVAILABILITY/checkerAccount.defaultAccount
Values username/PEM_encrypted_password
Example patrolns/FB0A195D062696
Menu Command Access Event Management => Availability => Checker Account
NOTE
BMC Software recommends that you do use the PATROL Agent default account. The
account could be locked out if an agent check fails because of an invalid login.
Parameter Settings
You can use the Parameter Settings menu commands to customize PATROL
parameter thresholds and polling times. These changes are stored externally from the
KM and do not change the KM version.
THRESHOLDS
Using the Thresholds configuration variable, you can change the thresholds for all
instances of a parameter or thresholds for a particular parameter instance. Changes
apply only to the agent where the command was executed. This operation is similar
to creating a localized parameter (overriding the global definition) by using a
developer console.

Parameter Settings
Table 80 Parameter Settings: Thresholds Configuration

/AS/EVENTSPRING/PARAM_SETTINGS/THRESHOLDS/object
where object is the full parameter object name such as

Configuration Variable /FILESYSTEM/root/FSCapacity
Value parameter_settings
Example 1,1 0 100 0 0 2,1 1 50 0 0 1,1 51 100 0 0 2
Menu Command Access Event Management => Parameter Settings => Thresholds
The following table provides a detailed description of the THRESHOLDS

configuration rule.
Table 81 Understanding the THRESHOLDS Rule (Part 1 of 2)

Item Description
/AS/EVENTSPRING variable folder
/PARAM_SETTINGS variable folder
/THRESHOLDS variable folder
/NT_CPU application class
/__ANYINST__ a variable that indicates any instance of the application class.
You could also specify a specific instance instead.
CPUprcrProcessorTi parameter name
mePercent
1 indicates that the parameter is active
Border Settings
0 indicates that the border range is inactive
0 the border begin range
0 the border end range
0 specifies when to trigger alarm; 0 means immediately on the
first occurrence
0 if the trigger value is non zero, this value specifies the
number of occurrences before triggering an alarm
0 specifies that the state is OK
Alarm1 Settings
1 indicates that the Alarm 1 alarm is active
80 the Alarm 1 begin range
85 the Alarm 1 end range
first occurrence
Chapter 5 187
Parameter Settings
Table 81 Understanding the THRESHOLDS Rule (Part 2 of 2)

Item Description
1 specifies that the state is WARN
Alarm 2 Settings
1 indicates that the Alarm 2 alarm is active
85 the Alarm 2 begin range
100 the Alarm 2 end range
first occurrence
2 specifies that the state is ALARM
interval
You can use the interval configuration variable to specify poll times for standard and
collector parameters.
Table 82 Parameter Settings: poll times Configuration

/AS/EVENTSPRING/PARAM_SETTINGS/POLLTIMES/object/interval

Configuration Variable /FILESYSTEM/root/FSCapacity
Values polltime_in_seconds
Example 90
Menu Command Event Management => Parameter Settings => Polltimes
Access
paramSettingsStatusFlag
You can use the paramSettingsStatusFlag configuration variable to enable or disable
the use of PATROL KM for Event Management thresholds or poll times. By default,
they are enabled. For more information on using PATROL KM for Event
Management to manage thresholds and poll times, see “Managing Parameter
Thresholds and Poll Times” on page 104.

Parameter Settings
Table 83 Parameter Settings: Status Flags Configuration

/AS/EVENTSPRING/PARAM_SETTINGS/STATUSFLAGS/object/

/FILESYSTEM/root/FSCapacity
Note: To apply the setting globally, omit the object reference, as shown below:
Configuration
Variable /AS/EVENTSPRING/PARAM_SETTINGS/STATUSFLAGS/paramSettingsStatusFlag
Values 0 - PATROL KM for Event Management settings are ignored
1 - PATROL KM for Event Management parameter settings have been processed
2 - Refresh thresholds
4 - Refresh poll times
6 - Refresh thresholds and poll times
NOTE
You can use a special instance name, __ANYINST__, for all instances of a parameter.
processWildcards
You can use the processWildcards rule to enable the use of wildcards for instance
names when specifying parameter thresholds and poll times.
Table 84 Parameter Settings: poll times Configuration

Configuration Variable /AS/EVENTSPRING/processWildcards
Values 1 = enable wildcards
0 = disable wildcards
Example 1
Menu Command None
Access
Support supported by PATROL KM for Event Management version 2.700 or later
Chapter 5 189
Instance Filtering Settings
Instance Filtering Settings

You can use the Instance filtering configuration variables to manage discovered
application instances.
FilterList Configuration Variable

You can use the FilterList configuration variable to specify the application instances
that you want to filter. For more information, see “Selecting Application Instances to
Monitor” on page 112.
Table 85 Filter List Configuration Variable

Configuration Variable /AgentSetup/ApplicationClass.filterList
Values list_of_application_instances
Example C:,D:,E:,F:
Menu Command Access Event Management => Instance Filtering => Edit Filter List
FilterType Configuration Variable

You can use the FilterType configuration variable to specify the type of instance filter.
There are two filter types: Exclude and Include. Instances specified in an exclude
filter list are not monitored. Instances specified in an include filter list are monitored.
“Selecting Application Instances to Monitor” on page 112.
Table 86 Filter Type Configuration Variable

Configuration Variable /AgentSetup/ApplicationClass.filterType
Values Include
Exclude
Menu Command Access Event Management => Instance Filtering => Edit Filter List

Chapter
6
6 Parameters
This chapter list PATROL KM for Event Management parameters and shows their
default settings. The following topics are discussed:
Parameter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Parameter Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Chapter 6 191
Parameter Summary
Parameter Summary
PATROL KM for Event Management parameters are in the following applications
classes:
■ AS_EVENTSPRING
■ AS_AVAILABILITY
Table 87 lists PATROL KM for Event Management parameters.
Table 87 PATROL KM for Event Management Parameters (Part 1 of 3)

Parameter Description
AS_EVENTSPRING Application Class
AlertTest tests the notification systems and rules without forcing a production
parameter into an alert state
AgentLoginDenied Monitors failed login attempts to the agent. The alarm is immediate - not
polling based.
To prevent a possible flood of notifications, this parameter alarms on the first

occurrence and must be manually reset or reset by a recovery action. Each
failed login attempt increments the parameter value by one and generates an
annotation that contains the IP address and user name of the failed login
account. You can use this information to troubleshoot communication
problems with the notification server. For more information, see
“AgentLoginDenied Parameter is in Alarm” on page 203.
NotifiedEvents the number of OK, ALARM, and WARN NOTIFY events processed by the
PATROL KM for Event Management during the collection cycle. Data about
each event is stored in a parameter annotation. For example, if the following 3
events are detected during the collection cycle, an OK, an ALARM, and a
WARN event, then the value of the NotifiedEvents parameter is set to 3 and 3
annotations are created on the graph at that data point.
By default, the collection cycle is every 30 seconds. The collector parameter is

EventCollector.
You can use information to troubleshoot notification problems. For more

information, see Chapter 7, “Troubleshooting PATROL KM for Event
Management”.

Parameter Summary

BlackoutEvents the number of blackout NOTIFY events processed by the PATROL KM for
Event Management during the collection cycle. Blackout NOTIFY events are
generated when a PATROL object generates an event and a PATROL KM for
Event Management rule specifies that the object is in a blackout period and
should not be forwarded. For more information about configuring blackout
periods, see “Configuring Blackout Periods” on page 115.
Data about each event is stored in the event annotation.

EventCollector.

Management”.
EscalatedEvents the number of escalated NOTIFY events processed by the PATROL KM for
Event Management during the collection cycle. Data about each event is
stored in the parameter annotation.

EventCollector.

Management”.
EventCollector collects the NOTIFY events on the monitored agent and sets the value of the
following parameters:
■ NotifiedEvents
■ EscalatedEvents
■ BlackoutEvents
RefreshParamSettin updates parameter settings as required
gs
ResendAlertQueue resends specified alerts
RetriggerEventQue retriggers events that failed to be sent to a notification server
ue
AS_AVAILABILITY Application Class
AlertTest tests the notification systems and rules without forcing a production
parameter into an alert state
Chapter 6 193
Parameter Defaults

AvailabilityMonitor Collector that performs availability checks and sets the value of the following
Coll parameters:
■ HostPingFailures
■ AgentPingFailures
■ SnmpPingFailures
The AgentPingFailures parameter value is set during every second polling

cycle. For example, if you set the poll time for the AvailabilityMonitorColl at
2 minutes, data is collected every 2 minutes for the HostPingFailures and
SnmpPingFailures parameters, and every 4 minutes for the
AgentPingFailures parameter.
AgentPingFailures indicates the availability of the PATROL Agent
The AgentPingFailures parameter value is set by the AvailabilityMonitorColl

during every second polling cycle. For example, if you set the poll time for
the AvailabilityMonitorColl at 2 minutes, data is collected every 4 minutes for
the AgentPingFailures parameter.
HostPingFailures indicates the host is unavailable using an ICMP ping
SnmpPingFailures indicates the SNMP Agent is unavailable
Parameter Defaults
Table 88 lists the default properties for each PATROL KM for Event Management
parameter.
Table 88 PATROL KM for Event Management Parameter Defaults (Part 1 of 2)

Annotated
Active
Alarm1
Parameter Type Alarm2 Border Schedule Icon Units
AlertTest Con 1-50 N/A N/A Gauge N/A N Y
51-100
AgentLoginDenied Con N/A 0-0 N/A Graph N/A Y Y
N/A
NotifiedEvents Con N/A N/A N/A Graph N/A Y Y
N/A

Parameter Defaults
Table 88 PATROL KM for Event Management Parameter Defaults (Part 2 of 2)
Annotated
Active
Alarm1
Parameter Type Alarm2 Border Schedule Icon Units
BlackoutEvents Con N/A N/A N/A Graph N/A Y Y
N/A
EscalatedEvents Con N/A N/A N/A Graph N/A Y Y
N/A
EventCollector Coll N/A N/A 30 seconds N/A N/A N Y
RefreshParamSettings Std N/A 0-1000 1.5 minutes Graph N/A N Y
N/A
ResendAlertQueue Std N/A N/A 10 minutes Graph N/A N Y
N/A
RetriggerEventQueue Std N/A N/A 2 minutes Graph N/A N Y
N/A
AvailabilityMonitorCo Coll N/A N/A 2 minutes 3 N/A N/A N Y
ll N/A seconds
AgentPingFailures Con N/A N/A N/A Graph N/A N Y
1
HostPingFailures Con N/A N/A N/A Graph N/A Y Y
1
SnmpPingFailures Con 1 N/A N/A Graph N/A N Y
2
Chapter 6 195
Parameter Defaults

Chapter
7
Troubleshooting PATROL KM for
7
Event Management
This chapter contains information for troubleshooting PATROL KM for Event
Management.
This chapter contains the following topics:
Configuration Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

Cannot Send E-mail Notifications to Multiple Targets . . . . . . . . . . . . . . . . . . . . . 198
Parameters are Unavailable or are Not Being Updated. . . . . . . . . . . . . . . . . . . . . 200
Too Many E-mail Alerts Are Being Generated . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Parameters Show a Negative Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Parameter Annotations Show Incorrect Targets or Other Errors . . . . . . . . . . . . . 203
AgentLoginDenied Parameter is in Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
The Availability Monitor is Not Pinging Frequently Enough . . . . . . . . . . . . . . . 205
NOTIFY_EVENTS not Generated when Parameter is in Alarm . . . . . . . . . . . . . 205
Parameters Setting Lost After Agent Restart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Notification Message not Sent from OpenVMS Server . . . . . . . . . . . . . . . . . . . . . 207
AS_AVAILABILITY Application Not Displayed . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Gathering Diagnostic Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Where to Find Diagnostic Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Installation Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Determining PATROL KM for Event Management Version Number . . . . . . . . 209
Chapter 7 197
Configuration Problems
This section contains troubleshooting information for the following common
configuration problems:
Problem Type Page

Cannot Send E-mail Notifications to Multiple Targets 198
Parameters are Unavailable or are Not Being Updated 200
Too Many E-mail Alerts Are Being Generated 201
Parameters Show a Negative Number 202
Parameter Annotations Show Incorrect Targets or Other Errors 203
AgentLoginDenied Parameter is in Alarm 203
The Availability Monitor is Not Pinging Frequently Enough 205
NOTIFY_EVENTS not Generated when Parameter is in Alarm 205
Parameters Setting Lost After Agent Restart 206
Notification Message not Sent from OpenVMS Server 207
AS_AVAILABILITY Application Not Displayed 207
Cannot Send E-mail Notifications to Multiple Targets

When the notification server is on Windows computer and you are using Blat as the
command-line e-mail client, e-mail notifications are not being sent to all of the e-mail
addresses that are entered as notification targets.
Explanation Solution
The PATROL KM for Event From the PATROL Configuration Manager, set the
Management is not configured to pass /AS/EVENTSPRING/useEnvOnlyForCmds rule to 0.
command-line arguments.
For more information, see “To Set the
/AS/EVENTSPRING/useEnvOnlyForCmds Value” on
page 199.
Why set the /AS/EVENTSPRING/useEnvOnlyForCmds Rule to O?
The batch file uses the environment variable AS_NOTIFICATION_TARGETS to get

the list of e-mail targets. PATROL does not allow commas to be passed to the
environment variable.

If you set the rule /AS/EVENTSPRING/useEnvOnlyForCmds to 0, the PATROL KM

for Event Management passes the targets as command-line arguments first.
Command-line arguments support commas.
Default Values
If you configure the notification server using the Quick Config menu option, the
default value for /AS/EVENTSPRING/useEnvOnlyForCmds is 1 on Unix and
AS/400 (iSeries) environments, which does not support commas.
In Windows and VMS environments, the default value is 0, which does support
commas.
To Set the /AS/EVENTSPRING/useEnvOnlyForCmds Value
Settings => Notification Command => Set For Classes.
3 From the Choose Target Class(es) dialog box, select / (for all application classes)
and select Accept.
The SET EVENT MANAGEMENT VARIABLE: alertLocalCommand dialog box is

displayed, as shown in Figure 29.
Chapter 7 199
Figure 29 SET EVENT MANAGEMENT VARIABLE: alertLocalCommand dialog box
4 For the option Call command using Event Management KM environment variables
only, select No.
6 Restart the PATROL Agent for the changes to be recognized.
Parameters are Unavailable or are Not Being Updated

In the PATROL console, the parameters NotifiedEvents, EscalatedEvents, or
BlackoutEvents, located in the host Event Management folder, are unavailable or are
not being updated.

PATROL KM for Event Management is not Verify that the arsAction rule is configured to
configured correctly. perform notification.
The value should be 4 or 6. For more

information, see “Configuring Recovery
Actions” on page 120.
PATROL KM for Event Management KM not Load the EVENT_MANAGEMENT.kml in the
loaded. PATROL console. For more information, see
“Loading Knowledge Modules” on page 52.
Too Many E-mail Alerts Are Being Generated

PATROL is generating too many e-mail messages, or too many notifications in
general or you are receiving notifications for events that are not important to you.
Parameters and thresholds Begin baselining and adjusting parameter thresholds.
need tuning.
Review the e-mail alerts to determine which parameters are
generating alerts. Then adjust the parameter thresholds, deactivate
threshold ranges, or deactivate parameters, as necessary. You can
make these changes on one remote agent and then use the PATROL
Configuration Manager to deploy these changes to other agents.
Blackout periods are needed. If you are receiving alerts because systems are down for
maintenance, you should configure blackout periods that specify
when alerts are not generated. For more information, see
“Configuring Blackout Periods” on page 115.
The rule Set the rule /AS/EVENTSPRING/ALERT/arsAction to 0.
/AS/EVENTSPRING/ALER
T/arsAction is set to 4. If the arsAction rule is set to 4 for all PATROL objects, notifications
are sent for all events. Instead, you may want to disable notification
for all PATROL objects, by setting /AS/EVENTSPRING/arsAction
to 0 at the remote agent. Then, enable notification only for the
desired applications, instances, or parameters.
When you enable notification for a specific PATROL object, the

following configuration variable is created:
/AS/EVENTSPRING/ALERT/object/arsAction
Chapter 7 201
Parameters Show a Negative Number

When you open the parameters NotifiedEvents, BlackoutEvents, or EscalatedEvents,
located in the host Event Management application, they shows a negative number.
The notification command is Fix the notification command.
failing at the notification server.
Run the notification script from the command line using the
PATROL default user account. If the script fails, determine
why. Possible reasons could include:
■ the script has a typo

■ the script may be in the wrong directory
■ the script may lack an exit statement
If the script runs correctly, verify that you have entered the
correct script name in your PATROL KM for Event
Management rule. If you update the script, you must restart the
PATROL Agent for the change to be recognized. For more
information, see “Testing Notification Scripts” on page 70.
The PATROL default account does Check the permissions on the script file.
not have the proper permissions
to execute the script file.
The PATROL Agent on the Verify that the PATROL agent on the notification server is
notification server is not running. running.
The remote notification event did Resolve connection problems.
not reach the notification server.
Verify whether you can ping the notification server from the
remote agent. Use the same hostname specified during
notification configuration. For more information about
configuring remote agents, see “Configuring Remote Agents”
on page 73.
The remote agent is configured Verify the rules have correct values.
incorrectly.
■ /AS/EVENTSPRING/alertSystem should be set to
REMOTE.
■ /AS/EVENTSPRING/NOTIFICATION_SERVER1.defaultA
ccount rule exists at the remote agent. If this rule is not
present, you need to specify the notification server as
described in “Configuring Remote Agents” on page 73.

Parameter Annotations Show Incorrect Targets or Other

Errors
When you examine the annotation for the NotifiedEvents, BlackoutEvents, or
EscalatedEvents parameter, the text indicates that there is no action to take or it
indicates that the targets are incorrect.
The notification rules are not Examine the annotation information in the NotifiedEvents
configured correctly. parameter at the remote agent and at the notification server.
Examine the NOTIFY_EVENT and the REMOTE_NOTIFY_EVENT
in the PATROL Event Manager. Determine whether the notification
settings at the remote agent are appropriate. If a NOTIFY_EVENT is
not being sent, see “NOTIFY_EVENTS not Generated when
Parameter is in Alarm” on page 205.
AgentLoginDenied Parameter is in Alarm

The AgentLoginDenied parameter, which monitors failed login attempts to the agent,
is in alarm.
The notification server account is Supply a valid account and reset the parameter.
not valid.
For more information, see “To Supply a Valid Account” on
page 204.
A user has caused the PATROL Determine the user account that generated the failed login.
default account to be locked out.
On Windows, domain accounts are often locked out after 3
failed login attempts. If the PATROL default account is
locked out, PATROL no longer works properly. This could
happen if a user starts a console using an account that does
not have the rights to connect to the agents.
For more information, see “To Determine the User Account

that Generated the Failed Login” on page 204.
Chapter 7 203
To Supply a Valid Account
1 From the remote agent machine, supply the correct notification server account. For
more information, see “Configuring Remote Agents” on page 73.
2 Reset the AgentLoginDenied parameter by accessing the remote agent Event

Management application and choosing the KM menu command Reset
AgentLoginDenied Alert.
For information about accessing KM menu commands on different consoles, see

To Determine the User Account that Generated the Failed Login
Review the AgentLoginDenied annotated data point to determine the account used
during the failed login. The annotated data point format is as follows:
U P:X.Y@Z
U = login name
P == protocol (T=TCP, U=UDP)
X == agent side file descriptor used for the connection
Y == agent side local port used for the connection
Z==ipaddressoftheclientconnecting(e.g.,console,PatrolCli,remoteagent,
etc.
Example)
patrol T:936.1389@192.168.1.233
To analyze the annotated data more closely, you can run this Unix command:
dump_hist-paramAgentLoginDenied-annotate|grep@|awk-F@{'print$2'}|sort
| uniq
It returns the hosts that attempted to connect to the notification server.

The Availability Monitor is Not Pinging Frequently Enough

The availability monitors are pinging less frequently than specified by the
AvailabilityMonitorColl collector parameter. By default, the AvailabilityMonitorColl
parameter schedules pinging every 2 minutes.
The availability Monitor a maximum of 100 agents.
monitor is monitoring
too many agents. An availability monitor should monitor a maximum of 100 agents. If it
monitors more than 100 agents, it may not be able to ping with the
frequency specified by the parameter AvailabilityMonitorColl.
NOTIFY_EVENTS not Generated when Parameter is in Alarm

A parameter alarms but a NOTIFY_EVENT is not sent to the notification server.
The parameter is being set There is currently no workaround for this issue.
to ALARM by way of an
PSL command, not because Some KMs change the state of a parameter using a PSL command.
it exceeded its threshold. When this occurs, the parameter does not generate the standard state
change events 9, 11, or 39, that it generates when it exceeds thresholds
or is cleared. Thus, the PATROL KM for Event Management does not
detect the ALARM state and does not generate a NOTIFY_EVENT.
The wrong standard events Take the following steps:
catalog (StdEvents.ctg) is
being used. 1. For the PATROL Agent machine, obtain the updated catalog file,
StdEvents.ctg.EVS, and copy it to
%PATROL_HOME%\lib\knowledge.
2. Rename existing StdEvents.ctg to StdEvents.ctg.bak or any other

suitable name.
3. Rename StdEvents.ctg.EVS to StdEvents.ctg.
4. Restart the PATROL Agent.
If you are using the PATROL Console for Windows or PATROL

Console for Unix, make sure each is using the same StdEvents.ctg file
that is used by the PATROL Agent.
Chapter 7 205
Parameters Setting Lost After Agent Restart

When using the PATROL Agent versions prior to 3.6.00, parameter poll times that are
set using the PATROL KM for Event Management are not retained upon agent
restart.
The allowsendparamonly variable exists in
Remove the allowsendparamonly variable.For
%PATROL_HOME%\common\patrol.d\pat instructions, see “Removing the allowsendparamonly
rol.conf file and is set to true. Variable” on page 206.
If this variable exists and is set to True, then state

change events for applications and instances are not
generated. This reduces network traffic, but it also
prevents the PATROL KM for Event Management
from detecting when parameters become active after
an agent restart. Thus, the PATROL KM or Event
Management threshold and poll time settings are not
applied.
etc/patrol.d/patrol.conf does not exist. If patrol.conf file doesn't exist then all the agent
variables get set to TRUE. To resolve this problem,
obtain a copy of the file patrol.conf and remove the
allowsendparamonly variable, if it exists, as described
in “Removing the allowsendparamonly Variable” on
page 206.
To obtain the patrol.conf file, copy it from another

computer or contact BMC Software Support.
Removing the allowsendparamonly Variable
1 Move patrol.conf from %PATROL_HOME%\common\patrol.d to a secure location.
2 Using the PACFG (PATROL Agent Configuration) utility, specify that secured
location.
3 Using Notepad (with word wrap disabled) or Wordpad, open patrol.conf.
4 Underneath the [AGENT] stanza, remove the following line:
allowsendparamonly=true
5 Save and close the file.
6 Reinitialize the agent.

Notification Message not Sent from OpenVMS Server

On an OpenVMS notification server, a parameter alerts and creates a
NOTIFY_EVENT but the notification message is not sent.
The message subject line Shorten the subject line to 80 characters or less and the body text to 255
or body text contain too characters or less.
many characters.
In OpenVMS, the subject line of a mail message is limited to 80
characters and the e-mail message body is limited to 255 characters. If
you exceed these limits, notification messages may not be sent. For
more information, see “Using Notification Scripts” on page 64.
The notificiation rules are For more information about configuring notification rules, see
not configured properly. “Configuring Notification Servers” on page 71.
AS_AVAILABILITY Application Not Displayed

The AS_AVAILABILITY application icon is not displayed in the PATROL Console.
Availability targets have Add availability targets. For more information, see “Configuring
not been added. Availability Monitoring” on page 87.
The AS_AVAILABILITY application class instantiates only when

availability targets have been defined.
When Using event_trigger2() Statements, Notifications Sent

to Wrong Target
When creating custom notifications using the event_trigger2() statement,
notifications may be sent to the wrong target. This could occur if the origin of the
event is external to the PATROL Agent machine from which you want to issue the
notification.
The event_trigger2() statement obtains the application If this problem occurs, you will need to
class, instance, and parameter name from the change your notification rules so that
NOTIFY_EVENT details, not from the event origin. notifications are sent to the correct target.
For more information see “Event Details” on page 156.
Chapter 7 207
Gathering Diagnostic Information

This section contains general information on gathering diagnostic information for
PATROL KM for Event Management.
Where to Find Diagnostic Information

The following table lists locations where you can find diagnostic information for
problems with PATROL KM for Event Management.
Type Location Description

Installation %USERPROFILE%\Application See “Installation Logs” on page 208.
logs Data\BMCINSTALL\
System See the documentation for you The system output window contains
Output PATROL console. messages relating to the operation of KMs,
Window including error messages.
PATROL From the PATROL console, The PATROL Event Manager shows all of
Event right-click the host and select Event the PATROL related events for the host. You
Manager Manager. can check here to determine if
NOTIFY_EVENTS are being generated.
parameter From the PATROL console, access the These parameter annotations contains
annotation host Event Management application information about every notification related
data and open one of the following event that passes through the PATROL KM
parameters: for Event Management.
■ NotifiedEvents
■ BlackoutEvents
■ EscalatedEvents
Double-click the annotated data

points on the graph.
Installation Logs
One log file is created each time the installer is run. The name of the log file is a
combination of the computer name and a time stamp. The log file is located in the
%USERPROFILE%\Application Data\BMCINSTALL\ directory.
For example, a log file for user bhunt on a Windows Server computer BHUNT_1
could be:

C:\WINNT\Profiles\jrando\Application Data\BMCinstall\BHUNT_1-1005340189.log.
Determining PATROL KM for Event Management Version

Number
Follow these steps to determine the PATROL KM for Event Management version that
is installed on the host machine.
To Determine the PATROL KM for Event Management Version
1 From the PATROL console, access the host Event Management application.
2 Right-click the Event Management application and select the menu command
InfoBox and described in “Accessing KM Commands and InfoBoxes” on page 212.
The PATROL KM for Event Management version is displayed next to KM Version.
Chapter 7 209

Appendix
A
Accessing Menu Commands,
A
InfoBoxes, and Online Help

BMC Software offers several PATROL consoles from which you can view a PATROL
Knowledge Module (KM). Because of the different environments in which these
consoles run, each one uses a different method to display and access information in
the KM. This appendix provides instructions for accessing the KM menu commands,
InfoBoxes, and online Help on each of the PATROL consoles. See the PATROL for
Windows Servers online Help for more detailed information about navigation in the
PATROL Consoles.
Accessing KM Commands and InfoBoxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

Accessing Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

Accessing KM Commands and InfoBoxes
Accessing KM Commands and InfoBoxes

Table 0-1 provides information about how to access KM commands and InfoBoxes
from the various PATROL consoles.
Table 0-1 Accessing KM Commands and InfoBoxes
To access To access
Console menu commands InfoBoxes
PATROL Console for Microsoft In either the Desktop tree tab or In either the Desktop tree tab or
Windows Servers work area, right-click a the work area, right-click an
computer or application icon application class or parameter
and choose KM Commands icon and choose InfoBox from
from the pop-up menu. the pop-up menu.
PATROL Console for Unix In the work area, right-click a With the middle mouse button,
computer or application icon to click an application class or
display a pop-up menu that parameter icon.
contains KM-specific
commands.
PATROL Central Operator - In the navigation pane, In the navigation pane,
Windows Edition right-click a managed system or right-click a PATROL object
application icon and choose and choose InfoBox from the
Knowledge Module pop-up menu.
Commands from the pop-up
menu.
PATROL Central Operator - In the tree view area, right-click In the tree view area, right-click
Web Edition an application icon and choose a PATROL object and choose
Knowledge Module Commands Infobox from the pop-up menu.
from the pop-up menu.
212 PATROL® for Microsoft Windows Servers Getting Started

Accessing Online Help

Table 0-2 provides information about how to access Help from each console.
NOTE
If you are trying to access Help from a Unix console, see the PATROL Installation
Reference Manual for specific instructions about installing and setting up a browser in
the Unix environment.
Table 0-2 Accessing Online Help (Part 1 of 2)
To access To access To access parameter

Console product help application class help help
PATROL Console From the console menu Double-click an ■ Right-click a
for Microsoft bar, choose Help => application class in the parameter icon and
Windows Servers Help Topics => KM tab of the console. choose Help On
PATROL Knowledge From the Application from the pop-up
Modules. Properties dialog box, menu.
click the Help tab. Then
click Show Help. ■ Double-click a
parameter icon; click
the ? icon or Help
button in the
parameter display
window.
■ Double-click a
parameter in the KM
tab of the console;
from the properties
dialog box, click the
Help tab; then click
Show Help.
PATROL Console From the console menu Choose Attributes => Right-click a parameter
for Unix bar, choose Help On => Application Classes and icon and click Help On.
Knowledge Modules. double-click the
application name. Click
Show Help in the
Application Definition
dialog box.

Table 0-2 Accessing Online Help (Part 2 of 2)
To access To access To access parameter

Console product help application class help help
PATROL Central From the console menu In the Operator tab of In the Operator tab of
Operator - bar, choose Help => the navigation pane, the navigation pane,
Windows Edition Help Topics. In the select an application select a parameter icon
Contents tab, click the icon and press F1. and press F1.
name of your product.
PATROL Central In the upper right corner In the tree view, In the tree view,
Operator - Web of PATROL Central, right-click an right-click a parameter
Edition click Help and choose application class and and choose Help.
PATROL KM Help. choose Help.
214 PATROL® for Microsoft Windows Servers Getting Started

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
Index
Symbols
%AGENT_VERSION% 160
%ALARM_MAX% 159
A
%ALARM_MIN% 159 accounts
%APPCLASS% 158 adminstrative rights required for 28
%APPINSTANCE% 158 availability monitoring 92
%AVE10% 158 console connection 28
%CUSTOM_ID1% 160 domain 28
%CUSTOM_ID2% 160 generating failed login alarms 204
%DATE% 158 operator 28
%EVENT_CATALOG% 160 root 29
%EVENT_CLASS% 160 setting up for installation 27
%EVENT_ID% 159 Unix 28
%EVENT_SEVERITY% 160 Windows 27
%EVENT_STATUS% 160 action scripts, AlarmPoint 98
%EVENT_TYPE% 160 active (configuration variable) 180
%HOSTNAME% 157 ActiveX control 66
%ICON_NAME% 158 addresses
%IPADDRESS% 157 default 72
%LAST10% 158 email, multiple 198
%LAST10TP% 159 paging 99
%LAST10TS% 159 AgentLoginDenied 203
%NOTIFY_EVENT_ID% 160 defined 192
%OS_TYPE% 159 resetting 204
%PARAMETER_NAME% 158 troubleshooting 203
%PARAMETER_STATUS% 158 using annotation data 204
%PARAMETER_VALUE% 158 AgentPingFailures 194
%PARENT_INSTANCE% 158 agents
%PATROL_HOME% 160 applying settings to 111
%TCP_PORT% 157 assigning notification servers to 73
%TIME% 158 configuring 73–75
%TIMEZONE% 158 maximum to monitor 61
%UDP_PORT% 157 monitoring for availability 87–93
%USERDEFINED% 159 persistent connection to 75
__ANYINST__ 149, 166, 189 protocol settings 79
__appl_class__ 124 tuning 91
__instance__ 124 where to install 32
__nfile__ 124 alarm ranges
__output__ 125 default 194
__OVERRIDE__ 174 setting 106
__param__ 124 AlarmPoint
__param_status__ 124 benefits 95
__param_value__ 124 integrating with 94–103
__src_event_id__ 124 java client 21, 96
__udefvar__ 125, 143 notification script for 95
215
alarms arsAction, continued

generating notification for 128 using 19, 85, 99
resetting 204 arsCmdType
triggering 106 defined 168
tuning 201 using 19, 142
alert condition 174 arsCommand
alertLocalCommand defined 168
defined 167 using 19, 20, 142
using 99 AS/400
alertResend See also iSeries
defined 167 installing on 42
using 19, 20, 78 scripts 67
alertResetOnInit subject line limitations 80
defined 169 AS_AVAILABILITY.km 55
using 19 defined 23
alerts InfoBox items 24
blacking out 115–120 loading 53
clearing outstanding 77 preloading 91
configuring 76 troubleshooting 207
false 77 AS_EVENTSPRING.km
resending 78 defined 23
troubleshooting 201 InfoBox items 24
variables for 158 loading 53
alertSystem AS_EVENTSPRING_ALL_COMPUTERS.km 53
defined 162 AS_EVSLocalAlertNotify.bat
troubleshooting 202 editing 68
using 19, 20, 72, 76 requirements for using 66
AlertTest 193 AS_EVSLocalAlertNotify.pl
aliases, account 29 location 65
ALL_COMPUTERS.KM 43 requirements for using 66
allowInfoRecoveryActions 165 AS_EVSLocalAlertNotify.sh 65
allowOperator 178 AS_EVSLocalAlertNotifyAP.bat 99
allowOverrides 163 AS_EVSLocalAlertNotifyAP.sh 99
allowsendparamonly variable 206 availability
annotations blackouts 184
disabling 181 monitoring 87–93
parameter 194 AvailabilityMonitorColl
troubleshooting 203, 208 defined 194
using in recovery actions 140–144 troubleshooting 205
AP_PATROL_EmailActionScriptV521-01.ppx 98 using 61
AP_PATROL_FaxActionScriptV521-01.ppx 98
APAgent.xml 96
appClassSettingsStatusFlag 180
application classes
B
AS_AVAILABILITY 23 backing up notification scripts 69
AS_EVENTSPRING 23 backup availability monitor 89
hierarchy 23 backup notification servers 58
icons 23 batch file 66
variable for 158 best practices 61
architecture 16 Blackout (configuration variable) 183
arguments BlackoutEvents
command-line 164, 198 annotations 208
NOTIFY_EVENT 156 defined 193
ping command 93 troubleshooting 203
arsAction blackoutPeriod
defined 161 defined 174
troubleshooting 201 using 19

blackouts, configuring 115–120 configuration variables, continued

Blat customTargets 173
defined 65 disableNotifyAnnotations 181
troubleshooting 198 emailTargets 171
version tested with 66 filterList 190
BMC Software, contacting 2 filterType 190
body, notification message 80 interval 188
border, parameter 105 LoginDeniedIgnoredUsers 164
Bourne shell 45 msgBody 177
msgText 176
NOTIFICATION_SERVER1.defaultAccount 170
C nsRemoteTargetSetting 175
pagerTargets 172
C shell 45 paramSettingsStatusFlag 188
cache, PATROL 43 pingArgs 185
changing pingAttempts 185
account, availability monitoring 92 pingCmd 184
notification messages 79 pingOkString 184
notification targets 171 pingPacketSize 185
parameter thresholds 104 Primary 183
ping commands 93 processWildcards 189
poll times 107 RemoteAgentCommSettings 170
what is being monitored 112 setParameterValue 166
checkerAccount.defaultAccount snmpOid 182
defined 186 snmpSettings 182
using 92 spoolDirectory 165
clearing Targets 182
AgentLoginDenied parameter 204 Thresholds 186
false alerts 77 ttTarget 173
client, java 21 Updated 183
collection period, setting 107 useEnvOnlyForCmds 164
colormap option 45 userdefined 157
command-line 198 configuring
commands alarm ranges 104
menu 151 AlarmPoint 96
operating system 142 alarms 104
ping, changing 93 availability monitoring 87–93
commas in variables 157 backup availability monitor 89
configuration variables blackouts 115–120
__ANYINST__ 189 globally 134
__OVERRIDE__ 174 notification servers 71–73
active 180 ping command 93
alertLocalCommand 167 poll times 107
alertResend 167 primary availability monitor 87
alertResetOnInit 169 recovery actions 120–125
alertSystem 162 remote agents 73–75
allowInfoRecoveryActions 165 thresholds 104
allowOperator 178 connection, persistent 75
allowOverrides 163 consoles
appClassSettingsStatusFlag 180 connection accounts 28
arsAction 161 supported 26
arsCmdType 168 copying rules 134
arsCommand 168 custom installation option 35
Blackout 183 customer support 3
blackoutPeriod 174 CustomId1 and CustomId2
checkerAccount.defaultAccount 186 defined 178
CustomId1 and CustomId2 178 using 19
217
customizing environment variables, continued

notification messages 79 setting for Help browser 45
ping command 93 using in notification command 200
scripts 67–69 EPD (Electronic Product Download) site 31
customTargets error messages 208
defined 173 EscalatedEvents 193
using 21, 99 annotations 208
troubleshooting 203
event catalog variable 160
D event class variable 160
event severity variable 160
date variables 158 event status variable 160
default email account 72 event type variable 160
default port number 27 event_trigger2() statement 207
default values, parameter 194 EventCollector 193
defining events
notification servers 58 ID, variables for 159
remote agents 58 NOTIFY_EVENT 156
targets 60 PATROL standard 19
where to place rules 61 REMOTE_NOTIFY_EVENT 156
dependencies 55 size limitations 157
deploying settings 59 standard 205
designing translating 20
availability monitoring 61 example
notification servers 60 e-mail rule 154
diagnosing problems 197–209 PATROL objects 153
disableNotifyAnnotations 181 ping command 93, 94
disabling rule inheritance 154
annotations 181 usage scenarios 128–150
monitoring of specific instances 112 using targets 136
notification 85 wildcard usage 108
parameters 109 eXceed 45
rules 86 excluding instances from monitoring 112
use of event management KM thresholds 112 exit statement 202
displaying in console 55
E F
failed login 204
editing failover
notification messages 79 configuring 89
scripts 67–69 features 17
electronic product download (EPD) site 31 filtering objects to monitor 112
emailTargets filterList
defined 171 defined 190
using 19 using 114
enabling filterType
ftp 29 defined 190
notification 141 using 113
parameters 109 first time installation 37
PATROL KM for Event Management thresholds 112 fixes, installing 30
recovery actions 121 ftp, enabling 29
enterprise console 59
environment variables
LANG 45
PATH 45
H
PATROL_BROWSER 46 Help, online 211

hierarchy, rule 154 KMs, continued

host macro 94 installing QuickStart packages 35
hostname variable 157 loading and unloading 52
HostPingFailures 194 preloading 52
upgrading from an earlier version 43
Korn shell 45
I
ICMP ping 194
icon name variable 158
L
icon, parameter 194 LANG environment variable 45
importing action scripts 98 license requirements 27
inheritance, rule 154 Linux
installation scripts 64
custom option 35 supported versions 26
log files 208 loading KMs
preparing for 30 with the PATROL Console for Unix 55
setting up installation accounts 27 with the PATROL Console for Windows 54
system requirements 26 local installation 31
typical option 35 local notification 162
Unix account requirements 28 location, rule 61
Windows account requirements 27 lock, account 203
installing login, failed 204
AlarmPoint java client 96 LoginDeniedIgnoredUsers 164
for the first time 37 logs, installation 208
on AS/400 (iSeries) 42
patches 30
upgrading from an earlier version 43
where to install PATROL Agent 32
M
instance name MAIL utility 67
__ANYINST__ 189 mailx 64
using wildcards to represent 107 Make Connection Persistent option 75
variable 158 managed system role 32
integration MAPI scripts 67
AlarmPoint 94–103 maxEventsToReport 181
Blat 65 maximum agents to monitor 61
PATROL Enterprise Manager (PEM) 20 menu commands, accessing 211–212
interval merging blackout settings 118
collection, changing 107 messages
configuration variable 188 body 177
IP address variable 157 customizing 140
iSeries error log 208
See also AS/400 rewording 79
installing on 42 subject line 176
scripts 67 migrating from earlier version 43
subject line limitations 80 monitoring
agent availability 87–93
notification servers 60
J specific instances 112
msgBody
java client, AlarmPoint 96 defined 177
using 19
msgText
K defined 176
using 19
KMs multiple targets, email 198
determining versions of 209
installing individual 35
219
N NOTIFY_EVENT, continued
troubleshooting 203
negative value, parameter 202 nsRemoteTargetSetting 175
Netscape Navigator 44
new PATROL users
easy install option 35
installing for the first time 37
O
NFS 29 objects, PATROL 153
notification OpenVMS
local versus remote 162 ping command 94
scripts, using 64–71 scripts 67
server 17, 58 subject line limitations 80
system, configuring 72 support for 26
types supported 69 troubleshooting 207
notification messages operating systems, support for 26
body text 80 operator accounts 28
length 80 OS (operating system)
rewording 79 command type 142
subject line 80 type, variable 159
where to send from 72 OS(operating system)
notification scripts supported 26
backing up 69 output window, system 208
customizing 69 overrides
editing 67 allowing 163
specifying 72 variable 174
testing 70
notification servers
benefits of 58 P
configuring 71–72
PACFG (PATROL Agent Configuration) utility 206
defining 58
pagerTargets 172
monitoring for availability 60
parameters
primary and backup 58
activating 105
protocol settings 79
AgentLoginDenied 192
providing security for 59
AgentPingFailures 194
notification targets
AlertTest 192, 193
defining 72
AvailabilityMonitorColl 194
types 70
BlackoutEvents 193
NOTIFICATION_SERVER1
default values 194
defined 170
EscalatedEvents 193
using 73
EventCollector 193
NOTIFICATION_SERVER1.defaultAccount
HostPingFailures 194
defined 170
list of 192
troubleshooting 202
NotifiedEvents 192
using 73
RefreshParamSettings 193
NOTIFICATION_SERVER2
ResendAlertQueue 193
defined 170
RetriggerEventQueue 193
using 73
set value 166
NOTIFICATION_SERVER2.defaultAccount 170
SnmpPingFailures 194
NotifiedEvents
variables for 158
annotations 181, 208
defined 192
defined 188
troubleshooting 203
using 111
usage example 143
parent instance variable 158
NOTIFY_EVENT
partitions, installing on 29
description 156
patches, installing 30
missing 205
PATH environment variable 45
triggering 156

PATROL Agents product

See also agents application classes 23
version of, variable for 160 architecture 16
where to install 32 capabilities 15
PATROL Configuration Manager components 15
icon 22 features 16
using 134 uninstalling in Windows environments 48
PATROL Enterprise Manager (PEM) 59 product support 3
PATROL Event Translator (PET) 20 protocol settings 79
PATROL objects 153 PSL (PATROL Script Language) 124
PATROL Script Language (PSL) 124
PATROL security 34
PATROL.conf 206
PATROL_BROWSER environment variable 46
R
PATROL_CACHE 43 ranges, alarm 106
pconfig variables 17 recommendations, rule location 61
PEM (PATROL Enterprise Manager) 59 recovery actions
Perl scripts 65 about 121
permissions 202 allowing 161
persistent agent connection 75 configuring 120–125
PET (PATROL Event Translator) 20 enabling 121
pingArgs examples 144
defined 185 rule location 63
using 93, 94 testing 149
pingAttempts 185 redundancy 58, 60
pingCmd RefreshParamSettings 193
defined 184 remote agents, assigning notification servers to 73
OpenVMS 94 remote installation 31
using 93 REMOTE_NOTIFY_EVENT
pinging triggering 156
arguments 93 troubleshooting 203
commands 93 RemoteAgentCommSettings
InfoBox items 24 defined 170
on OpenVMS 94 using 79
problems with 205 removing
variables 184–186 annotations 181
pingOkString 184 customized KM files 43
pingPacketSize 185 menu commands 43
planning notification 85
availability monitoring 61 renaming notification scripts 69
installation 30 requirements
notification 58 license 27
platforms, supported 26 system 26
poll times Unix account 28
applying to agent 111 Unix script 65
disabling 112 Windows account 27
setting 107 Windows script 66
practices, best 61 ResendAlertQueue 193
preloading KMs 52 resending alerts 78
preparing for installation 30 Reset AgentLoginDenied Alert menu command 204
Primary (configuration variable) 183 restart, agent 206
problem resolution 197–209 RetriggerEventQueue 193
processWildcards rewording
defined 189 default notification message 81
using 111 example 136
messages 79
variables 81
221
rules rules, contined

__OVERRIDE__ 174 useEnvOnlyForCmds 164
See also configuration variables using wildcards in 107
active 180 where to locate 61
alertLocalCommand 167
alertResend 167
alertResetOnInit 169
alertSystem 162
S
allowOperator 178 scalability 205
allowOverrides 163 scenarios 128–150
appClassSettingsStatusFlag 180 schedule, parameter 195
arsAction 161 scheduling interval, setting 107
arsCmdType 168 scripts
arsCommand 168 action 98
Blackout 183 AlarmPoint 98, 99
blackoutPeriod 174 AS/400 (iSeries) 67
checkerAccount.defaultAccount 186 backing up 69
copying 134 batch file 66
CustomId1 and CustomId2 178 customizing 69
customTargets 173 editing 67–69
disableNotifyAnnotations 181 Linux 64
e-mail 154 OpenVMS 67
emailTargets 171 Perl 65
example 153 renaming 69
filterList 190 testing 70
filterType 190 Unix 64
hierarchy 153 using 64–71
hierarchy of 154 using exit statements in 202
inheritance 154 Windows 65
inheritance of 154 security
interval 188 account 28
LoginDeniedIgnoredUsers 164 changing levels 34
loginDeniedIgnoredUsers 164 notification server 59
msgBody 177 SED Utility 143
msgText 176 Send Distribution utility 67
notification server 170 send_mapi.vbs 66
nsRemoteTargetSetting 175 sendmail.vbs 66
overriding 86 servers
pagerTargets 172 deploying settings to 59
paramSettingsStatusFlag 188 monitoring for availability 60
pingArgs 185 notification 71
pingAttempts 185 setParameterValue
pingCmd 184 defined 166
pingOkString 184 using 103
pingPacketSize 185 setting environment variables for Help browser 45
Primary 183 shells
processWildcards 189 Bourne 45
RemoteAgentCommSettings 170 C 45
setParameterValue 166 Korn 45
snmpOid 182 SMTP scripts 67
snmpSettings 182 snmpOid 182
spoolDirectory 165 SnmpPingFailures 194
Targets 182 snmpSettings 182
testing 84 spoolDirectory 165
Thresholds 186 standard events catalogue 43
ttTarget 173 standard events, PATROL 19, 159, 205
Updated 183 StdEvent.ctg 43

StdEvents.ctg.EVS 205
stopping U
notification 85 UDP Port variable 157
the monitoring of objects 112 UDP protocol 79
subject line umask setting 29
back slashes in 81 uninstalling 48
length limitations 80 units, parameter 194
notification message 80 Unix
rewording 79 account requirements 28
rewording variables 81 browser requirements 44
support, customer 3 scripts 64
supported platforms 26 subject line limitations 80
system output window 208 using for availability monitoring 61
system requirements 26 unloading KMs
with the PATROL Console for Unix 57
with the PATROL Console for Windows 57
T Updated (configuration variable) 183
upgrading 43
tabs in variables 157 backing up scripts prior to 30
targets from an earlier version of the KM 43
availability monitoring 88 useEnvOnlyForCmds
custom 21 changing value of 199
example 136 defined 164
rules 171–174 troubleshooting 198
using multiple 198 user account 45
where to locate 61 User defined variables 159
Targets (configuration variable) 182 userdefined configuration variable 157
TCP port variable 157
TCP protocol 79
technical support 3
telnet, enabling 29 V
testing variables
AlarmPoint java client 97 alarm settings 159
notification scripts 70 alert 158
notification using AlarmPoint 103 application class 158
recovery actions 149 date 158
rules 84 disableNotifyAnnotations 181
thresholds event catalog 160
applying to agent 111 event class 160
configuration variable 186 event ID 159
disabling 112 event severity 160
PATROL KM for Event Management 104 event status 160
rule for 187 event type 160
setting 104 hostname 157
tuning 201 icon name 158
time variables 158, 159 instance name 158
Tivoli 59 IP address 157
Trigger NOTIFY_EVENT option 101 maxEventsToReport 181
triggering alarms 106 message-replacement 157–161
troubleshooting 197–209 OS type 159
ttTarget parameter 158
defined 173 parent instance 158
using 70 PATROL Agent version 160
typical installation option 35 PATROL_BROWSER 46
pconfig 17
pingArgs 186
pingAttempt 185
223
variables, continued
pingPacketSize 185
TCP port 157
time 158, 159
UDP port 157
user-defined 159
using tabs or commas in 157
VB (Visual Basic) 65
verifying discovery 64
version, determining 209
Visual Basic (VB) 65
VMware, support for 29
W
What If? feature 84
wilcards 107
Windows
accounts 27
scripts 65

Notes
*52965*
*52965*
*52965*
*52965*
*52965*

PATROL Knowledge Module For Event Management User Guide - 2.7

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PATROL Knowledge Module For Event Management User Guide - 2.7

Uploaded by

Copyright:

Available Formats

PATROL® KM ® for Event

Restricted rights legend

Support by telephone or e-mail

Before contacting BMC Software

PATROL® KM ® for Event Management 3

Chapter 2 Installing and Migrating PATROL KM for Event Management 25

Chapter 3 Using the PATROL KM for Event Management 49

6 PATROL Knowledge Module for Event Management User Guide

Chapter 4 Usage Scenarios 127

Chapter 5 Rules and Configuration Variables 151

8 PATROL Knowledge Module for Event Management User Guide

Chapter 6 Parameters 191

Chapter 7 Troubleshooting PATROL KM for Event Management 197

Appendix A Accessing Menu Commands, InfoBoxes, and Online Help 211

10 PATROL Knowledge Module for Event Management User Guide

14 PATROL Knowledge Module for Event Management User Guide

■ configure notification (e-mail, paging, trouble-ticket, or custom) for PATROL alerts

■ configure PATROL to send notifications to an enterprise console

■ configure recovery actions for PATROL alerts

■ reword notification messages and customize message content

■ configure PATROL to monitor the availability of hosts

■ manage PATROL parameter thresholds and polling schedules

■ configure blackout periods for notification and for availability monitoring

■ integrate with AlarmPoint enterprise notification software using provided scripts

■ who gets notified

16 PATROL Knowledge Module for Event Management User Guide

Figure 1 Typical PATROL KM for Event Management Architecture

Agent 1 Agent 2 Agent 3

Rules Stored as Pconfig Variables

■ e-mail notification using a notification server

18 PATROL Knowledge Module for Event Management User Guide

Sending Notification: Process Flow

Table 1 E-mail Notification Process

Sending Alerts to an Enterprise Console: Process Flow

Table 2 Sending Alerts to Enterprise Console Process

5. PATROL Event Translator (PET) NA

You can also send events to

20 PATROL Knowledge Module for Event Management User Guide

Sending Pages using AlarmPoint: Process Flow

Table 3 Sending Pages using AlarmPoint Process

Using the PATROL Configuration Manager

PATROL Configuration Manager Tasks

Tasks that Must be Completed Using PATROL KM for Event

■ “Configuring Notification Servers” on page 71

22 PATROL Knowledge Module for Event Management User Guide

Application Classes and Instances

Table 4 Application Classes and KM File

AS_AVAILABILITY.km instances, menu commands, parameters, and

Application Class Hierarchy

Application InfoBox Items

To View the InfoBox on the PATROL Console for Unix

2 Using the middle mouse button, click the instance icon.

To View the InfoBox on the PATROL Console for Windows

2 Right-click the instance icon to display a pop-up menu.

Table 5 AS_EVENTSPRING InfoBox Items

Table 6 AS_AVAILABILITY InfoBox Items

24 PATROL Knowledge Module for Event Management User Guide

for Event Management

26 PATROL Knowledge Module for Event Management User Guide

■ PATROL default accounts on domain controllers should be only domain accounts.

Creating a Separate Account

Console Connection Accounts