PATROL Knowledge Module For Event Management User Guide

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

2101 CITYWEST BLVD
HOUSTON TX 77042-2827
USA
Telephone
713 918 8800 or

800 841 2031
Fax
(01) 713 918 8000
Fax
713 918 8000
Outside United States and Canada

Telephone
(01) 713 918 8800
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
PATROL Knowledge Module for Event Management User Guide
Contents
Chapter 1
Product Components and Capabilities
15
Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Typical Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Notification Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rules Stored as Pconfig Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Notification Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sending Notification: Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sending Alerts to an Enterprise Console: Process Flow . . . . . . . . . . . . . . . . . . . . .
Sending Pages using AlarmPoint: Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the PATROL Configuration Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PATROL Configuration Manager Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tasks that Must be Completed Using PATROL KM for Event Management . . .
Application Classes and Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Application Class Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Application InfoBox Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
16
17
17
17
18
19
20
21
22
22
22
22
23
23
24
Chapter 2
25
Installing and Migrating PATROL KM for Event Management
Installation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Virtual Machine Support Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Preparing for Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backing up the Notification Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Checking for Product Patches or Fixes Before Installing. . . . . . . . . . . . . . . . . . . . .
Determining How to Install Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installation Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Determining Where to Install the PATROL Agent. . . . . . . . . . . . . . . . . . . . . . . . . .
Determining Where to Install KMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PATROL Security Levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Checking Security Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Assessing and Implementing a Different Security Level . . . . . . . . . . . . . . . . . . . .
Typical and Custom Installation Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing into a PATROL 3.3.x or 3.4.x Unix Environment . . . . . . . . . . . . . . . . . .
First-Time Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing For the First Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing on AS/400 (iSeries) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Upgrading from an Earlier Version. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
26
27
29
30
30
30
31
31
32
32
34
34
34
35
36
37
37
42
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
6
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
Sending E-mail Notification When Disk Space is Low . . . . . . . . . . . . . . . . . . . . . . . .

Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Selecting a Mail Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Loading the PATROL KM for Event Management . . . . . . . . . . . . . . . . . . . . . . . .
Defining the Notification Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring the Remote Agent NT1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Specifying an E-mail Target for Low Disk Space . . . . . . . . . . . . . . . . . . . . . . . . . .
Rewording the Notification Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Testing Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sending E-mail Notification for CPU Usage that Includes Parameter Annotations
Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Overview of Annotated Data Points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling Recovery Actions and Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating Recovery Action Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating Notification Command Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring a Recovery Action that Runs Under a Specified Account . . . . . . . . . . .
Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Testing Recovery Action Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling Recovery Actions for ArchFreeSpace on Agent Computer . . . . . . . . .
Defining the Recovery Action Type for Agent Computer . . . . . . . . . . . . . . . . . .
127
128
128
129
130
130
130
132
135
136
138
140
140
141
141
141
142
143
143
144
144
145
145
146
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
8
CustomId1 and CustomId2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Parameter Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Chapter 7
Troubleshooting PATROL KM for Event Management
Configuration Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cannot Send E-mail Notifications to Multiple Targets . . . . . . . . . . . . . . . . . . . . .
Parameters are Unavailable or are Not Being Updated. . . . . . . . . . . . . . . . . . . . .
Too Many E-mail Alerts Are Being Generated . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Parameters Show a Negative Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Parameter Annotations Show Incorrect Targets or Other Errors . . . . . . . . . . . . .
AgentLoginDenied Parameter is in Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Availability Monitor is Not Pinging Frequently Enough . . . . . . . . . . . . . . .
NOTIFY_EVENTS not Generated when Parameter is in Alarm . . . . . . . . . . . . .
Parameters Setting Lost After Agent Restart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Notification Message not Sent from OpenVMS Server . . . . . . . . . . . . . . . . . . . . .
AS_AVAILABILITY Application Not Displayed . . . . . . . . . . . . . . . . . . . . . . . . . .
When Using event_trigger2() Statements, Notifications Sent to Wrong Target
Gathering Diagnostic Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Where to Find Diagnostic Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
197
198
198
200
201
202
203
203
205
205
206
207
207
207
208
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
10
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
12
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
14
Chapter
Product Components and

Capabilities
1
This chapter provides an overview of the PATROL Knowledge Module for Event
Management (also referred to as PATROL KM for Event Management).
Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Typical Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Notification Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rules Stored as Pconfig Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Notification Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sending Notification: Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sending Alerts to an Enterprise Console: Process Flow . . . . . . . . . . . . . . . . . . . . .
Sending Pages using AlarmPoint: Process Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the PATROL Configuration Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PATROL Configuration Manager Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tasks that Must be Completed Using PATROL KM for Event Management . . .
Application Classes and Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Application Class Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Application InfoBox Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 1
16
16
17
17
17
18
19
20
21
22
22
22
22
23
23
24
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).
16
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 dont
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.
18
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
arsAction
3. The remote agent triggers a PATROL
NOTIFY_EVENT (if arsAction = 4 or 6)
4. CustomID values are set (if configured) customId1
customId2
5. Notification message reworded (if
configured)
msgText
msgBody
6. PATROL determines if a blackout

period applies. If so, NOTIFY_EVENT
is not sent to the notification server.
blackoutPeriod
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
REMOTE_NOTIFY_EVENT event
details, which contains the same
information as the original
NOTIFY_EVENT.
NA
13. Repeat steps 4 through 10 on the

notification server (except step 7).
Multiple. See steps 4

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)
arsAction
arsCommand
msgText
msgBody
The message rewording (msgText) blackoutPeriod
must be done on the remote agent alertResetOnInit
alertResend
so that when the PATROL Event
alertSystem
Translator (PET) pulls the event,
the event contains the host specific
information.
2. Notification processing occurs on

the remote agent as previously
discussed in Table 1 on page 19.
3. The NOTIFY_EVENT is sent to the NA

notification server.
4. The notification server process the
REMOTE_NOTIFY_EVENT as
previously discussed in Table 1 on
page 19.
arsAction
arsCommand
blackoutPeriod
alertSystem
5. PATROL Event Translator (PET)

pulls REMOTE_NOTIFY_EVENT
from the notification server
NA
NA
6. The PET processes the
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
PATROL Enterprise Manager.
20
NA
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
the remote agent as previously
discussed in Table 1 on page 19.
arsAction
arsCommand
msgText
blackoutPeriod
alertResetOnInit
alertResend
alertSystem
customTargets
3. The NOTIFY_EVENT is sent to the

4. The notification server process the
REMOTE_NOTIFY_EVENT as
previously discussed in Table 1 on
page 19.
arsAction
arsCommand
blackoutPeriod
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.
22
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
directory used to store output files generated by parameter reports and

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
PATROLAgent?
whether the PATROL Agent is being monitored for availability
Ping SNMP Agent? whether the SNMP agent is being monitoring for availability
24
Blacked Out?
indicates whether the selected instance is currently being

blacked out
KM Version
the version of the PATROL KM for Event Management
Chapter
Installing and Migrating PATROL KM

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

Management along with many other PATROL
components and you need information about
migrating customizations or using the Distribution
Server (DS).
You need more technical details about how to use
the installation program.
PATROL for Microsoft Windows Servers

Getting Started
PATROL for Unix Getting Started
PATROL for OpenVMS Installation Guide
PATROL for AS/400 Getting Started
PATROL Installation Reference Manual
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.
Table 7
the account that you use to install the product has sufficient privileges
(Part 1 of 2)
Resource
Requirements
operating
systems
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.
PATROL
products
For a current list of the supported PATROL products, see

the release notes for the PATROL solution. For example, the
PATROL for Microsoft Windows Servers Release Notes.
26
Comments
Table 7
(Part 2 of 2)
Resource
Requirements
Comments
security levels For information on security, see PATROL Security Levels On iSeries, only
security levels 0 and
on page 34.
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 enterprises
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

for Event Management, you must specify the port number
to connect to all the agent computers.
Use Netscape Navigator version 3.014.78 to use online

(Unix only)
Help with PATROL for Unix.
browser to
support online
Help for
PATROL for
Unix Console
browser
The default port

number is 3181 for
agents.
Browser Version
Required for
Viewing PATROL
Console for Unix
Help on page 44
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 dont 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:
28
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.
30
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 images 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 AgentSelect 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
UnixSelect 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 ServerSelect 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.
32
Computers hosting the PATROL AgentSelect 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 products 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.
34
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 dont 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 ManagementPreload 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 ManagementPreload 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.
36
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:
Table 8
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.
System Role Packages Available for Product Components

System Role to Select
Console System
Product Component/Selectable Entity
PCO-Winb
PATROL 3c
Managed
System
Common
Servicesa
PATROL Knowledge Module for Event

Management
no
yes
yes
yes
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.
38
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:
40
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.
42
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:
44
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
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
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
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
46
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

Management features
Chapter 1, Product Components and

Capabilities.
setting up and configuring PATROL KM for Chapter 3, Using the PATROL KM

Event Management
for Event Management.
48
information on usage scenarios
Chapter 4, Usage Scenarios.
information about PATROL KM for Event

Management configuration variables
Chapter 5, Rules and Configuration

Variables.
parameter descriptions
Chapter 6, Parameters.
troubleshooting information
Chapter 7, Troubleshooting PATROL

KM for Event Management,
step-by-step procedures and detailed

descriptions of the applications, menu
commands, parameters, and InfoBoxes
PATROL KM for Event Management

component online Help
Chapter
Using the PATROL KM for Event

Management
3
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 . . . . . . . . . . . . . . . . . . . . .
Loading and Preloading KMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Determining Which KMs to Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
KM Files Preloaded on Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Loading and Unloading KMs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Loading Knowledge Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verifying that PATROL KM for Event Management KM is Loaded. . . . . . . . . . .
Unloading Knowledge Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining Notification Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining Notification Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining Availability Monitors and Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deciding Where to Place Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Recommended Configuration Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Notification Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Testing Notification Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring Notification Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring Remote Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring Alert Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rewording Notification Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting Notification Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Testing Notification Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Disabling Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring Availability Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring an Availability Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring a Backup Availability Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring the Availability Monitor Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Specifying an Availability Monitoring Account . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changing the Ping Command Used for Availability Monitoring . . . . . . . . . . . . .
Chapter 3
51
51
51
52
52
52
55
55
58
58
60
60
61
63
63
64
70
71
73
76
79
82
84
85
87
87
89
91
92
93
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
50
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 products 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 KMs data collection
history, you do not see any gaps that would otherwise occur (because of the consoles
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.

52
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.

54
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.
56
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.
58
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.
60
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, seeConfiguring 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)
Rule Type
Recommended
Location
Targets (notification
recipients)
notification
server
Alert Messages
(wording and content
of notification
messages)
Blackouts
remote agent
remote agent
Advantage
Easier to manage
Less processing at
managed nodes reduces
PATROL resource
consumption
Reduces the number of

rules at the notification
server
Since messages are

reworded before arriving
at the notification server,
you dont need a second
level of notification
servers to properly send
messages to an enterprise
console.
Reduces network traffic
Reduces processing at
the notification server
Disadvantage
More processing is
performed at the
notification server
More difficult to manage

the rules on multiple
remote agents
More difficult to manage

the rules on multiple
remote agents
Alert Action (what to

do when an alert
occurs)
remote agent
only
The alert action must be defined on the remote agent

where PATROL alerts are generated.
Parameter Settings
(thresholds and poll
times)
remote agent
only
The parameter settings must be defined on the remote

agent where PATROL alerts are generated.
Alert Resend (whether

to resend outstanding
alerts)
remote agent
only
The alert resend settings must be defined on the remote

agent where the PATROL alerts are generated.
Notification Command notification

(the script used to send server only
notifications)
The notification script must be defined on a notification

server that sends 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

(whether to close old
events when agent
restarts)
62
remote agent
only
The Send Reset on Init setting must be defined on the

remote agent where PATROL alerts are generated.
Configuring Notification
Table 11
Recommended Rule Location (Part 2 of 2)

Recommended
Location
Advantage
Custom Identifiers
remote agent
only
Custom identifiers must be defined on the remote agent

where message rewording is taking place.
Recovery Actions
remote agent
only
Recovery actions settings must be defined on the remote

agent where PATROL events are generated and where
you expect the recovery action to occur.
Rule Type
Disadvantage
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
Identify, edit, and test the notification

script.
Using Notification Scripts
64
Testing Notification Scripts
70
Configure a notification server.
Configuring Notification Servers
71
Reword default notification message

for the notification server.
Rewording Notification Messages
79
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.
Configure remote agents to use a

Configuring Remote Agents
73
Chapter 3
63
Table 12
Recommended Configuration Process (Part 2 of 2)
Topic(s)
For an example of how to use the PATROL 134

Configuration Manager, see To Assign
Notification Servers for NT2 and NT3 on
page 134. For more detailed instructions on
using the PATROL Configuration Manager,
see the PATROL Configuration Manager User
Guide.
Use PATROL Configuration Manager

to copy agent notification server rules
to other like agents.
For example, copying the settings to
other agents that use the same
Configure notification rules and

parameter settings for the agents.
Page
Setting Notification Targets
82
Managing Parameter Thresholds and Poll

Times
104
Configuring Alert Settings
76
Use PATROL Configuration Manager For an example of how to use the PATROL 134
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
Guide.
to Oracle. You would then copy that
rule to all other agents that are
monitoring Oracle.
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.
64
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
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
66
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
(iSeries)
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.
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
68
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:
emailsends an e-mail notification

pagesends a page notification
ttsends a trouble ticket notification
customsends a custom notification
If you use the page, tt, and custom notification types, you must
customize the notification script.
70
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 dont 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.
72
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
74
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
Property
Description
Notification Server
Hostname
the hostname or IP address of the primary notification

server for the selected managed system
To avoid DNS resolution problems, use the IP address.
Notification Server Agent

Port
the port number of the notification server that the

selected managed system will use
Notification Server User

Name
the user name that the selected managed system will

use to connect to the notification server
Notification Server
Password
the password that the selected managed system will

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
Persistent
indicates that the remote agent maintains a 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.
76
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.
78
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
(iSeries)
When using the native SNDDST mail utility, the subject line is limited
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.
80
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 dont 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.
82
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.
84
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 dont 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 dont 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.
86

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)
Property
Description
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
88
the SNMP community string of the managed system you are

monitoring
Table 23
Availability Target Properties (Part 2 of 2)
Property
Description
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:
90
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
dont 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.
92
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.
94
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:
Topic(s)
Page
Install AlarmPoint on a Windows

server.
Installing and Configuring AlarmPoint
96
Configure AlarmPoint and define users Installing and Configuring AlarmPoint

(notification targets).
96
Install AlarmPoint java client.
Installing the AlarmPoint Java Client
96
Configure AlarmPoint java client
Configuring the AlarmPoint Java Client
96
Test the AlarmPoint Java client.
Testing the Java Client
97
Download AlarmPoint scripts (only if

using AlarmPoint 5.2.01).
Using Action Scripts for AlarmPoint

5.2.01
98
Configure notification.
99
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.
96
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 dont 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.
98
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.
100
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
102
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.
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.
104
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)
Property
Description
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)
Property
Description
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:
Enable
must be greater than Alarm1 values

cannot overlap the Alarm1 range
cannot fall outside the range limits or border range
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.
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
persistent
makes the selected parameter thresholds persist after the console is disconnected
If a Problem Occurs
If a problems occurs, see Parameters Setting Lost After Agent Restart on page 206.
106
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
CPU_13
HoustonCPU_03
CP_1
CPU14
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
108
msdtc
svchost
msv
Rule # 1:
msdtc
svchost
msv
Rule# 1:
Result
Since rule # 2 did not

/AS/EVENTSPRING/PARAM_SETTINGS/THRESH match any of the
OLDS/NT_PROCESS/__ANYINST__/PROCSTATUS processes running on
the host, rule # 1 is
applied to all of the
Rule# 2:
/AS/EVENTSPRING/PARAM_SETTINGS/THRESH instances on the host.
OLDS/NT_PROCESS/pat{re:*}/PROCSTATUS
Since rule # 1 is an
/AS/EVENTSPRING/PARAM_SETTINGS/THRESH exact match for a
process that is running
OLDS/NT_PROCESS/msdtc/PROCSTATUS
on the host, it takes
precedence over rule
Rule # 2:
/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


110
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:
112
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 dont 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
dont 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.
114
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 dont 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.
116
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
Property
Description
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

Pre-Existing Settings
merges the current blackout out period

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.
118
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.
120
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 dont 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:
122
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__
124
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
126
Chapter
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 . . . . . . . . . . . . . . . . . . . . . . . .
Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Selecting a Mail Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Loading the PATROL KM for Event Management . . . . . . . . . . . . . . . . . . . . . . . .
Defining the Notification Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring the Remote Agent NT1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Specifying an E-mail Target for Low Disk Space . . . . . . . . . . . . . . . . . . . . . . . . . .
Rewording the Notification Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Overview of Annotated Data Points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling Recovery Actions and Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating Recovery Action Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating Notification Command Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring a Recovery Action that Runs Under a Specified Account . . . . . . . . . . .
Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Testing Recovery Action Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling Recovery Actions for ArchFreeSpace on Agent Computer . . . . . . . . .
Defining the Recovery Action Type for Agent Computer . . . . . . . . . . . . . . . . . .
Storing the Encrypted Password as a Pconfig Variable. . . . . . . . . . . . . . . . . . . . .
Configuring the PSL Recovery Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary of Rules Created . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Testing the Recovery Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 4
128
128
129
130
130
130
132
135
136
138
140
140
141
141
141
142
143
143
144
144
145
145
146
146
147
148
149
149
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
Notification Server
NS1
NT1
Backup
Notification Server
NS2
NT2
NT3
Assumptions
For this scenario, assume the following:
128
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
Step Task
PATROL Product
Alternative PATROL
Product
Selecting a Mail Client
NA
NA
Loading the PATROL KM for

Event Management
PATROL console
None
Defining the Notification Servers PATROL console - (PATROL KM None

for Event Management)
Configuring the Remote Agent

NT1
PATROL console - (PATROL KM None

Copying notification server

settings to NT2 and NT3
PATROL Configuration
Manager
Specifying an E-mail Target for

Low Disk Space
PATROL console - (PATROL KM PATROL

Configuration Manager
Copying e-mail targets from NS1 PATROL Configuration

to NS2
Manager
Rewording the Notification

Messagee
PATROL console - (PATROL KM PATROL

Copying reworded notification

message rule from NS1 to NS2
PATROL Configuration
Manager
None
10
PATROL console or PATROL

None
None
None
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.
130
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 dont 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
132
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
134
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.
136
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.
138
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
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:
140
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.
142

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
144
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
Step Task
PATROL Product
Alternative PATROL
Product
Testing Recovery Action Script
OS (outside of PATROL)
NA
Enabling Recovery Actions for

ArchFreeSpace on Agent
Computer
PATROL console - (PATROL KM PATROL Configuration

Manager
Defining the Recovery Action

Type for Agent Computer

Manager
Storing the Encrypted Password PATROL Developer Console

as a Pconfig Variable
Configuring the PSL Recovery

Action

Manager
Testing the Recovery Action
PATROL console
None
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.
146
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
148
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.
150
Chapter
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example: PATROL Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example: Rule Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example: PATROL KM for Event Management E-mail Rule . . . . . . . . . . . . . . . .
NOTIFY_EVENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How the NOTIFY_EVENT and REMOTE_NOTIFY_EVENT are Triggered . . .
Event Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Order of Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Empty Fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the Variable userdefined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Event Size Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NOTIFY_EVENT Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Alert Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
arsAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
alertSystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
allowOverrides. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
loginDeniedIgnoredUsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
useEnvOnlyForCmds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
allowInfoRecoveryActions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
spoolDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
setParameterValue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Local Alert Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
alertResend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
alertLocalCommand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
arsCommand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
arsCmdType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
alertResetOnInit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 5
153
153
154
154
156
156
156
156
156
157
157
157
161
161
162
163
164
164
165
165
166
166
167
167
168
168
169
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
152
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
host
host computer of the

objects that are being
monitored
ntprod1
sunprod1
application
class
type of objects that can

be monitored
NT_LOGICAL_DISKS
FILESYSTEM
application
instance
actual instance of an
application class
C:
root
parameter
specific parameter of an LDldFreeMegabytes

application instance
FSCapacity
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:
instance
parameter
/NT_LOGICAL_DISKS/C:
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.
154
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 its 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.
156
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 -CRtabs 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:
Table 35
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)
NOTIFY_EVENT Fields (Part 1 of 4)
Field
Message
Replacement Variable Environment Variable
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)
Description
Chapter 5
157
NOTIFY_EVENT
Table 35
Field
Message
Application Class
%APPCLASS%
Description
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
CE%
CE
Instance name that is the

parent container of instance
(e.g., /CPU/CPU)
Parameter Name
%PARAMETER_NA
ME%
Parameter name (e.g.,

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_PARAMETER
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
Values
%LAST10%
AS_LAST10
Last 10 parameter 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)
158
NOTIFY_EVENT
Table 35
Field
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
Description
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
Table 35
Field
Message
Custom Id1
%CUSTOM_ID1%
AS_CUSTOM_ID1
Description
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
version
%AGENT_VERSION AS_AGENT_VERSION
%
The version of the PATROL

Agent running on the host.
PATROL Home
%PATROL_HOME% AS_PATROL_HOME
The PATROL installation

directory.
Event catalog
%EVENT_CATALO
G%
AS_EVENT_CATALOG The PATROL event catalog

file.
Event class
%EVENT_CLASS%
AS_EVENT_CLASS
Event status
%EVENT_STATUS% AS_EVENT_STATUS
Event severity
%EVENT_SEVERITY AS_EVENT_SEVERITY The event severity. For

%
example, 4.
Event type
%EVENT_TYPE%
AS_EVENT_TYPE
The event class of the event.

For example, 9 or 11.
The status of the event. For
example, Open.
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)
160
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
Values
/AS/EVENTSPRING/object/arsAction
/AS/EVENTSPRING/object/arsActionINFORMATION
/AS/EVENTSPRING/object/arsActionWARNING
/AS/EVENTSPRING/object/arsActionALARM
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
Values
/AS/EVENTSPRING/ALERT/object/alertSystem
/AS/EVENTSPRING/ALERT/object/alertSystemINFORMATION
/AS/EVENTSPRING/ALERT/object/alertSystemWARNING
/AS/EVENTSPRING/ALERT/object/alertSystemALARM
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
Access
Event Management => Alert Settings => Notification System
162
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,
REMOTE
You can choose both LOCAL and REMOTE. You may need to select this option if you
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
/AS/EVENTSPRING/allowOverrides
Values
0 = do not allow rule overrides

1 = allow rule overrides (default)
Example
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 dont
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
Variable
/AS/EVENTSPRING/loginDeniedIgnoredUsers
Values
comma delimited string
Examples
patrol_checker,EventSpring,EventSpring_Availability_Check
Support
Menu Command
Access
Not available
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
Variable
/AS/EVENTSPRING/useEnvOnlyForCmds
Values
0 = run commands with command-line arguments (default)

1 = do not use command-line arguments
Example
Support
Menu Command
Access
Event Management => Alert Settings => Local Alert Settings => Notification
Command
164
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
Variable
/AS/EVENTSPRING/allowInfoRecoveryActions
Values
0 = recovery actions not enabled for INFORMATION events (default)

1 = recovery actions enabled for INFORMATION events
Example
Support
supported by PATROL KM for Event Management version 2.7or later
Menu Command
Access
None
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
/AS/EVENTSPRING/spoolDirectory
Values
directory path
The default location is the directory specified in the PATROL_HOME
environment variable.
Example
/usr/local/patrol_reports
Support

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
Support

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.
166
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
/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
Access
Event Management => Alert Settings => Local Alert Settings =>
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
Support
Menu Command
Access
Event Management => Alert Settings => Local Alert Settings => Recovery
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.
168
Remote Alert Settings
Table 50
arsCmdType Rule
Rule
arsCmdType
/AS/EVENTSPRING/object/arsCmdType
/AS/EVENTSPRING/object/arsCmdTypeINFORMATION
/AS/EVENTSPRING/object/arsCmdTypeWARNING
/AS/EVENTSPRING/object/arsCmdTypeALARM
Values
command type
Example
PSL
Support
Menu Command
Access
Event Management => Alert Settings => Local Alert Settings => Recovery
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
/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.
Table 52
NOTIFICATION_SERVER1.defaultAccountthe user name and password for the

primary notification sever
NOTIFICATION_SERVER2.defaultAccountthe user name and password for the
backup notification sever
NOTIFICATION_SERVER1hostname and port number of the primary
notification server
NOTIFICATION_SERVER2hostname and port number of the backup
notification server
Remote Alert Settings: Configure Notification Servers Configuration Variable
/AS/EVENTSPRING/NOTIFICATION_SERVER1.defaultAccount (primary)
/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)
/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:
Table 54
the agent sending events to a notification server

an availability monitor checking the availability of monitored agents
Remote Alert Settings: Remote Communication Settings Configuration Variable
Configuration Variable /AS/EVENTSPRING/RemoteAgentCommSettings

Values
170
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
Command
Access
Event Management => Alert Settings => Notification Targets => Email
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
Variable
/AS/EVENTSPRING/ALERT/PAGER/object/pagerTargetsLocalINFORMATIO
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
Command
Access
Event Management => Alert Settings => Notification Targets => Pager
172
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
Command
Event Management => Alert Settings => Notification Targets => Custom
ttTargets
You can use ttTargets rules to specify trouble ticket notification targets.
Table 58
Notification Targets: TT Targets Configuration Variable
Rule
ttTargets
Configuration
Variable
/AS/EVENTSPRING/ALERT/TT/object/ttTargetsLocalINFORMATION
/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
/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.
174
Notification Server Settings
Table 60
Overrides 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
/AS/EVENTSPRING/NS/nsRemoteTargetSetting
Values
Example
Ignoreremote 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.
Overridenotification is sent only to the targets defined at the

remote agent.
Forwardremote 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.
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
Command
Access
Event Management => Alert Settings => Alert Messages => Default Message
Format
NOTE
If you do not specify INFORMATION, WARNING or ALARM, the same message
format is used for all events.
176
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
Variable
/AS/EVENTSPRING/ALERT/MSG/object/msgBody
/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
Command
Access
Event Management => Alert Settings => Alert Messages => Default Message
Format
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
Variable
/AS/EVENTSPRING/object/CustomId1
/AS/EVENTSPRING/object/CustomId2
Values
custom_identifier
Example
financial_app
Support
Menu Command
Access
Event Management => Alert Settings => Custom Identifiers => CustomID1
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.
178
Custom Settings
Table 65
allowOperator Variable
Configuration
Variable
/AS/EVENTSPRING/MENU_COMMANDS/allowOperator
Values
Support
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

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
Variable
/AS/EVENTSPRING/APPLICATION_CLASSES/STATUSFLAGS/appClassSettingStatusF
lag
Values
0 = use KM defaults
1 = use PATROL KM for Event Management application class settings
2 = refresh active rules
Support
180
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
/AS/EVENTSPRING/disableNotifyAnnotations
Values
0 = dont disable annotations (default)

1 = disable annotations
Example
Menu Command Access None

Support

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
/AS/EVENTSPRING/maxEventsToReport
Values
Any integer value. The default value is 100.
Example
100

Support

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
/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.
/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.
/AS/EVENTSPRING/AVAILABILITY/snmpOid
Values
SNMP_ObjectID
Example
.1.3.6.1.2.1.1.3.0
182
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
/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
/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
/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
/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
/AS/EVENTSPRING/AVAILABILITY/pingOkString
Values
ping output
Example
bytes
184
Availability
pingPacketSize
The pingPacketSize configuration variable defines the packet size of the ping
command in bytes.
Table 76
pingPacketSize Configuration Variable
/AS/EVENTSPRING/AVAILABILITY/pingPacketSize
Values
number of bytes; if not specified, the default value is 32 bytes
Example
32

Support

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
/AS/EVENTSPRING/AVAILABILITY/pingAttempt
Values
number of attempts; if not specified, the default value is 2 attempts
Example

Support

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
/AS/EVENTSPRING/AVAILABILITY/pingArgs
Values
ping command arguments
Example
-n 2 -|32

Support
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
/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.
186
Parameter Settings
Table 80
Parameter Settings: Thresholds Configuration

/AS/EVENTSPRING/PARAM_SETTINGS/THRESHOLDS/object
where object is the full parameter object name such as
/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
mePercent
parameter name
indicates that the parameter is active

Border Settings
indicates that the border range is inactive
the border begin range
the border end range
specifies when to trigger alarm; 0 means immediately on the

first occurrence
if the trigger value is non zero, this value specifies the

number of occurrences before triggering an alarm
specifies that the state is OK

Alarm1 Settings
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
specifies that the state is WARN

Alarm 2 Settings
indicates that the Alarm 2 alarm is active
85
the Alarm 2 begin range
100
the Alarm 2 end range

first occurrence

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
Access
Event Management => Parameter Settings => Polltimes
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.
188
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
Values
/AS/EVENTSPRING/PARAM_SETTINGS/STATUSFLAGS/paramSettingsStatusFlag
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
Menu Command
Access
None
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
/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
/AgentSetup/ApplicationClass.filterType
Values
Include
Exclude
Menu Command Access
Event Management => Instance Filtering => Edit Filter List
190
Chapter
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.
192
Parameter Summary
Table 87
Parameter
Description
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
ue
retriggers events that failed to be sent to a notification server
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
Table 87
Parameter
Description
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.
PATROL KM for Event Management Parameter Defaults (Part 1 of 2)
Type
AlertTest
Con
1-50
Active
Parameter
Alarm1
Alarm2
Annotated
Table 88
Border
Schedule
Icon
Units
N/A
N/A
Gauge
N/A
51-100
AgentLoginDenied
Con
N/A
N/A
0-0
N/A
Graph
N/A
NotifiedEvents
Con
N/A
N/A
N/A
N/A
Graph
N/A
194
Parameter Defaults
PATROL KM for Event Management Parameter Defaults (Part 2 of 2)
Type
BlackoutEvents
Con
EscalatedEvents
Active
Parameter
Alarm1
Alarm2
Annotated
Table 88
Border
Schedule
Icon
Units
N/A
N/A
N/A
N/A
Graph
N/A
Con
N/A
N/A
N/A
N/A
Graph
N/A
EventCollector
Coll
N/A
N/A
30 seconds
N/A
N/A
RefreshParamSettings
Std
N/A
N/A
0-1000
1.5 minutes
Graph
N/A
ResendAlertQueue
Std
N/A
N/A
N/A
10 minutes
Graph
N/A
RetriggerEventQueue
Std
N/A
N/A
N/A
2 minutes
Graph
N/A
AvailabilityMonitorCo Coll
ll
N/A
N/A
N/A
2 minutes 3
seconds
N/A
N/A
AgentPingFailures
Con
N/A
1
N/A
N/A
Graph
N/A
HostPingFailures
Con
N/A
1
N/A
N/A
Graph
N/A
SnmpPingFailures
Con
1
2
N/A
N/A
Graph
N/A
Chapter 6
195
Parameter Defaults
196
Chapter
Troubleshooting PATROL KM for

Event Management
7
This chapter contains information for troubleshooting PATROL KM for Event

Management.
This chapter contains the following topics:
Configuration Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cannot Send E-mail Notifications to Multiple Targets . . . . . . . . . . . . . . . . . . . . .
Parameters are Unavailable or are Not Being Updated. . . . . . . . . . . . . . . . . . . . .
Too Many E-mail Alerts Are Being Generated . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Parameters Show a Negative Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Parameter Annotations Show Incorrect Targets or Other Errors . . . . . . . . . . . . .
AgentLoginDenied Parameter is in Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Availability Monitor is Not Pinging Frequently Enough . . . . . . . . . . . . . . .
NOTIFY_EVENTS not Generated when Parameter is in Alarm . . . . . . . . . . . . .
Parameters Setting Lost After Agent Restart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Notification Message not Sent from OpenVMS Server . . . . . . . . . . . . . . . . . . . . .
AS_AVAILABILITY Application Not Displayed . . . . . . . . . . . . . . . . . . . . . . . . . .
When Using event_trigger2() Statements, Notifications Sent to Wrong Target
Gathering Diagnostic Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Where to Find Diagnostic Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installation Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Determining PATROL KM for Event Management Version Number . . . . . . . .
Chapter 7
198
198
200
201
202
203
203
205
205
206
207
207
207
208
208
208
209
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
When Using event_trigger2() Statements, Notifications Sent to Wrong Target 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

Management is not configured to pass
command-line arguments.
From the PATROL Configuration Manager, set the

/AS/EVENTSPRING/useEnvOnlyForCmds rule to 0.
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.
198
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.
200
Explanation
Solution
PATROL KM for Event Management is not

configured correctly.
Verify that the arsAction rule is configured to

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

loaded.
Load the EVENT_MANAGEMENT.kml in the

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.
Explanation
Solution
Parameters and thresholds

need tuning.
Begin baselining and adjusting parameter thresholds.

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.
Explanation
Solution
The notification command is

failing at the notification server.
Fix the notification command.

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
notification server is not running.
Verify that the PATROL agent on the notification server is

running.
The remote notification event did

not reach the notification server.
Resolve connection problems.

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

incorrectly.
202
Verify the rules have correct values.
/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.
Explanation
Solution
The notification rules are not

configured correctly.
Examine the annotation information in the NotifiedEvents

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.
Explanation
Solution
The notification server account is

not valid.
Supply a valid account and reset the parameter.

For more information, see To Supply a Valid Account on
page 204.
A user has caused the PATROL

default account to be locked out.
Determine the user account that generated the failed login.

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.
204
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.
Explanation
Solution
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.
Explanation
Solution
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.
Explanation
Solution
The allowsendparamonly variable exists in
Remove the allowsendparamonly variable.For

%PATROL_HOME%\common\patrol.d\pat instructions, see Removing the allowsendparamonly
Variable on page 206.
rol.conf file and is set to true.
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.
206
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.
Explanation
Solution
The message subject line

or body text contain too
many characters.
Shorten the subject line to 80 characters or less and the body text to 255
characters or less.
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.
Explanation
Solution
Availability targets have

not been added.
Add availability targets. For more information, see Configuring

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.
Explanation
Solution
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
logs
%USERPROFILE%\Application
Data\BMCINSTALL\
See Installation Logs on page 208.
System
Output
Window
See the documentation for you

PATROL console.
The system output window contains

messages relating to the operation of KMs,
including error messages.
PATROL
Event
Manager
From the PATROL console,

right-click the host and select Event
Manager.
The PATROL Event Manager shows all of

the PATROL related events for the host. You
can check here to determine if
NOTIFY_EVENTS are being generated.
parameter
annotation
data
From the PATROL console, access the

host Event Management application
and open one of the following
parameters:
These parameter annotations contains

information about every notification related
event that passes through the PATROL KM
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:
208
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
210
Appendix
Accessing Menu Commands,

InfoBoxes, and Online Help
A
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
Appendix A
Accessing Menu Commands, InfoBoxes, and Online Help
211
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
Console
To access
menu commands
PATROL Console for Microsoft In either the Desktop tree tab or

Windows Servers
work area, right-click a
computer or application icon
and choose KM Commands
from the pop-up menu.
To access
InfoBoxes
In either the Desktop tree tab or
the work area, right-click an
application class or parameter
icon and choose InfoBox from
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 Windows Edition
In the navigation pane,

right-click a managed system or
application icon and choose
Knowledge Module
Commands from the pop-up
menu.
PATROL Central Operator Web Edition
In the tree view area, right-click In the tree view area, right-click
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
In the navigation pane,

right-click a PATROL object
and choose InfoBox from the
pop-up menu.
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)
Console
PATROL Console
for Microsoft
Windows Servers
PATROL Console
for Unix
To access
product help
To access
application class help
From the console menu

bar, choose Help =>
Help Topics =>
PATROL Knowledge
Modules.
Double-click an
application class in the
KM tab of the console.
From the Application
Properties dialog box,
click the Help tab. Then
click Show Help.
To access parameter
help
Right-click a
parameter icon and
choose Help On
from the pop-up
menu.
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.
From the console menu Choose Attributes =>

Right-click a parameter
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.
Appendix A
Accessing Menu Commands, InfoBoxes, and Online Help
213
Table 0-2
Accessing Online Help (Part 2 of 2)
To access
product help
To access
application class help
To access parameter
help
PATROL Central
Operator Windows Edition
From the console menu

bar, choose Help =>
Help Topics. In the
Contents tab, click the
name of your product.
In the Operator tab of

the navigation pane,
select an application
icon and press F1.
In the Operator tab of

the navigation pane,
select a parameter icon
and press F1.
PATROL Central
Operator - Web
Edition
In the upper right corner

of PATROL Central,
click Help and choose
PATROL KM Help.
In the tree view,

right-click an
application class and
choose Help.
In the tree view,

right-click a parameter
and choose Help.
Console
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
%ALARM_MIN% 159
%APPCLASS% 158
%APPINSTANCE% 158
%AVE10% 158
%CUSTOM_ID1% 160
%CUSTOM_ID2% 160
%DATE% 158
%EVENT_CATALOG% 160
%EVENT_CLASS% 160
%EVENT_ID% 159
%EVENT_SEVERITY% 160
%EVENT_STATUS% 160
%EVENT_TYPE% 160
%HOSTNAME% 157
%ICON_NAME% 158
%IPADDRESS% 157
%LAST10% 158
%LAST10TP% 159
%LAST10TS% 159
%NOTIFY_EVENT_ID% 160
%OS_TYPE% 159
%PARAMETER_NAME% 158
%PARAMETER_STATUS% 158
%PARAMETER_VALUE% 158
%PARENT_INSTANCE% 158
%PATROL_HOME% 160
%TCP_PORT% 157
%TIME% 158
%TIMEZONE% 158
%UDP_PORT% 157
%USERDEFINED% 159
__ANYINST__ 149, 166, 189
__appl_class__ 124
__instance__ 124
__nfile__ 124
__output__ 125
__OVERRIDE__ 174
__param__ 124
__param_status__ 124
__param_value__ 124
__src_event_id__ 124
__udefvar__ 125, 143
A
accounts
adminstrative rights required for 28
availability monitoring 92
console connection 28
domain 28
generating failed login alarms 204
operator 28
root 29
setting up for installation 27
Unix 28
Windows 27
action scripts, AlarmPoint 98
active (configuration variable) 180
ActiveX control 66
addresses
default 72
email, multiple 198
paging 99
AgentLoginDenied 203
defined 192
resetting 204
troubleshooting 203
using annotation data 204
AgentPingFailures 194
agents
applying settings to 111
assigning notification servers to 73
configuring 7375
maximum to monitor 61
monitoring for availability 8793
persistent connection to 75
protocol settings 79
tuning 91
where to install 32
alarm ranges
default 194
setting 106
AlarmPoint
benefits 95
integrating with 94103
java client 21, 96
notification script for 95
215
alarms
generating notification for 128
resetting 204
triggering 106
tuning 201
alert condition 174
alertLocalCommand
defined 167
using 99
alertResend
defined 167
using 19, 20, 78
alertResetOnInit
defined 169
using 19
alerts
blacking out 115120
clearing outstanding 77
configuring 76
false 77
resending 78
troubleshooting 201
variables for 158
alertSystem
defined 162
troubleshooting 202
using 19, 20, 72, 76
AlertTest 193
aliases, account 29
ALL_COMPUTERS.KM 43
allowInfoRecoveryActions 165
allowOperator 178
allowOverrides 163
allowsendparamonly variable 206
annotations
disabling 181
parameter 194
troubleshooting 203, 208
using in recovery actions 140144
AP_PATROL_EmailActionScriptV521-01.ppx 98
AP_PATROL_FaxActionScriptV521-01.ppx 98
APAgent.xml 96
appClassSettingsStatusFlag 180
application classes
AS_AVAILABILITY 23
AS_EVENTSPRING 23
hierarchy 23
icons 23
variable for 158
architecture 16
arguments
command-line 164, 198
NOTIFY_EVENT 156
ping command 93
arsAction
defined 161
troubleshooting 201
216
arsAction, continued
using 19, 85, 99
arsCmdType
defined 168
using 19, 142
arsCommand
defined 168
using 19, 20, 142
AS/400
See also iSeries
installing on 42
scripts 67
subject line limitations 80
AS_AVAILABILITY.km 55
defined 23
InfoBox items 24
loading 53
preloading 91
troubleshooting 207
AS_EVENTSPRING.km
defined 23
InfoBox items 24
loading 53
AS_EVENTSPRING_ALL_COMPUTERS.km 53
AS_EVSLocalAlertNotify.bat
editing 68
requirements for using 66
location 65
requirements for using 66
AS_EVSLocalAlertNotify.sh 65
AS_EVSLocalAlertNotifyAP.bat 99
AS_EVSLocalAlertNotifyAP.sh 99
availability
blackouts 184
monitoring 8793
AvailabilityMonitorColl
defined 194
troubleshooting 205
using 61
B
backing up notification scripts 69
backup availability monitor 89
backup notification servers 58
batch file 66
best practices 61
Blackout (configuration variable) 183
BlackoutEvents
annotations 208
defined 193
troubleshooting 203
blackoutPeriod
defined 174
using 19
blackouts, configuring 115120
Blat
defined 65
troubleshooting 198
version tested with 66
BMC Software, contacting 2
body, notification message 80
border, parameter 105
Bourne shell 45
C
C shell 45
cache, PATROL 43
changing
account, availability monitoring 92
notification messages 79
notification targets 171
parameter thresholds 104
ping commands 93
poll times 107
what is being monitored 112
checkerAccount.defaultAccount
defined 186
using 92
clearing
AgentLoginDenied parameter 204
false alerts 77
client, java 21
collection period, setting 107
colormap option 45
command-line 198
commands
menu 151
operating system 142
ping, changing 93
commas in variables 157
configuration variables
__ANYINST__ 189
__OVERRIDE__ 174
active 180
alertLocalCommand 167
alertResend 167
alertResetOnInit 169
alertSystem 162
allowInfoRecoveryActions 165
allowOperator 178
allowOverrides 163
arsAction 161
arsCmdType 168
arsCommand 168
Blackout 183
blackoutPeriod 174
checkerAccount.defaultAccount 186
CustomId1 and CustomId2 178
configuration variables, continued

customTargets 173
disableNotifyAnnotations 181
emailTargets 171
filterList 190
filterType 190
interval 188
LoginDeniedIgnoredUsers 164
msgBody 177
msgText 176
NOTIFICATION_SERVER1.defaultAccount 170
nsRemoteTargetSetting 175
pagerTargets 172
paramSettingsStatusFlag 188
pingArgs 185
pingAttempts 185
pingCmd 184
pingOkString 184
pingPacketSize 185
Primary 183
processWildcards 189
RemoteAgentCommSettings 170
setParameterValue 166
snmpOid 182
snmpSettings 182
spoolDirectory 165
Targets 182
Thresholds 186
ttTarget 173
Updated 183
useEnvOnlyForCmds 164
userdefined 157
configuring
alarm ranges 104
AlarmPoint 96
alarms 104
backup availability monitor 89
blackouts 115120
globally 134
notification servers 7173
ping command 93
poll times 107
primary availability monitor 87
recovery actions 120125
remote agents 7375
thresholds 104
connection, persistent 75
consoles
connection accounts 28
supported 26
copying rules 134
custom installation option 35
customer support 3
CustomId1 and CustomId2
defined 178
using 19
217
customizing
ping command 93
scripts 6769
customTargets
defined 173
using 21, 99
D
date variables 158
default email account 72
default port number 27
default values, parameter 194
defining
remote agents 58
targets 60
where to place rules 61
dependencies 55
deploying settings 59
designing
diagnosing problems 197209
disabling
annotations 181
monitoring of specific instances 112
notification 85
parameters 109
rules 86
use of event management KM thresholds 112
displaying in console 55
E
editing
scripts 6769
electronic product download (EPD) site 31
emailTargets
defined 171
using 19
enabling
ftp 29
notification 141
parameters 109
PATROL KM for Event Management thresholds 112
enterprise console 59
environment variables
LANG 45
PATH 45
PATROL_BROWSER 46
218
environment variables, continued

setting for Help browser 45
using in notification command 200
EPD (Electronic Product Download) site 31
error messages 208
EscalatedEvents 193
annotations 208
troubleshooting 203
event catalog variable 160
event class variable 160
event severity variable 160
event status variable 160
event type variable 160
event_trigger2() statement 207
EventCollector 193
events
ID, variables for 159
NOTIFY_EVENT 156
PATROL standard 19
REMOTE_NOTIFY_EVENT 156
size limitations 157
standard 205
translating 20
example
e-mail rule 154
PATROL objects 153
ping command 93, 94
rule inheritance 154
usage scenarios 128150
using targets 136
wildcard usage 108
eXceed 45
excluding instances from monitoring 112
exit statement 202
failed login 204

failover
configuring 89
features 17
filtering objects to monitor 112
filterList
defined 190
using 114
filterType
defined 190
using 113
first time installation 37
fixes, installing 30
ftp, enabling 29
H
Help, online 211
hierarchy, rule 154
host macro 94
hostname variable 157
HostPingFailures 194
I
ICMP ping 194
icon name variable 158
icon, parameter 194
importing action scripts 98
inheritance, rule 154
installation
custom option 35
log files 208
preparing for 30
setting up installation accounts 27
system requirements 26
typical option 35
Unix account requirements 28
Windows account requirements 27
installing
AlarmPoint java client 96
for the first time 37
on AS/400 (iSeries) 42
patches 30
upgrading from an earlier version 43
where to install PATROL Agent 32
instance name
__ANYINST__ 189
using wildcards to represent 107
variable 158
integration
AlarmPoint 94103
Blat 65
PATROL Enterprise Manager (PEM) 20
interval
collection, changing 107
configuration variable 188
IP address variable 157
iSeries
See also AS/400
installing on 42
scripts 67
J
java client, AlarmPoint 96
K
KMs
determining versions of 209
installing individual 35
KMs, continued
installing QuickStart packages 35
loading and unloading 52
preloading 52
upgrading from an earlier version 43
Korn shell 45
L
LANG environment variable 45
license requirements 27
Linux
scripts 64
supported versions 26
loading KMs
with the PATROL Console for Unix 55
with the PATROL Console for Windows 54
local installation 31
local notification 162
location, rule 61
lock, account 203
login, failed 204
logs, installation 208
M
MAIL utility 67
mailx 64
Make Connection Persistent option 75
managed system role 32
MAPI scripts 67
maxEventsToReport 181
maximum agents to monitor 61
menu commands, accessing 211212
merging blackout settings 118
messages
body 177
customizing 140
error log 208
rewording 79
subject line 176
migrating from earlier version 43
monitoring
agent availability 8793
specific instances 112
msgBody
defined 177
using 19
msgText
defined 176
using 19
multiple targets, email 198
219
N
negative value, parameter 202
Netscape Navigator 44
new PATROL users
easy install option 35
installing for the first time 37
NFS 29
notification
local versus remote 162
scripts, using 6471
server 17, 58
system, configuring 72
types supported 69
notification messages
body text 80
length 80
rewording 79
subject line 80
where to send from 72
notification scripts
backing up 69
customizing 69
editing 67
specifying 72
testing 70
notification servers
benefits of 58
configuring 7172
defining 58
primary and backup 58
providing security for 59
notification targets
defining 72
types 70
NOTIFICATION_SERVER1
defined 170
using 73
NOTIFICATION_SERVER1.defaultAccount
defined 170
troubleshooting 202
using 73
NOTIFICATION_SERVER2
defined 170
using 73
NOTIFICATION_SERVER2.defaultAccount 170
NotifiedEvents
annotations 181, 208
defined 192
troubleshooting 203
usage example 143
NOTIFY_EVENT
description 156
missing 205
triggering 156
220
NOTIFY_EVENT, continued
troubleshooting 203
O
objects, PATROL 153
OpenVMS
ping command 94
scripts 67
support for 26
troubleshooting 207
operating systems, support for 26
operator accounts 28
OS (operating system)
command type 142
type, variable 159
OS(operating system)
supported 26
output window, system 208
overrides
allowing 163
variable 174
P
PACFG (PATROL Agent Configuration) utility 206
pagerTargets 172
parameters
activating 105
AgentLoginDenied 192
AgentPingFailures 194
AlertTest 192, 193
AvailabilityMonitorColl 194
BlackoutEvents 193
default values 194
EscalatedEvents 193
EventCollector 193
HostPingFailures 194
list of 192
NotifiedEvents 192
RefreshParamSettings 193
ResendAlertQueue 193
RetriggerEventQueue 193
set value 166
SnmpPingFailures 194
variables for 158
defined 188
using 111
parent instance variable 158
partitions, installing on 29
patches, installing 30
PATH environment variable 45
PATROL Agents
See also agents
version of, variable for 160
where to install 32
PATROL Configuration Manager
icon 22
using 134
PATROL Enterprise Manager (PEM) 59
PATROL Event Translator (PET) 20
PATROL objects 153
PATROL Script Language (PSL) 124
PATROL security 34
PATROL.conf 206
PATROL_BROWSER environment variable 46
PATROL_CACHE 43
pconfig variables 17
PEM (PATROL Enterprise Manager) 59
Perl scripts 65
permissions 202
persistent agent connection 75
PET (PATROL Event Translator) 20
pingArgs
defined 185
using 93, 94
pingAttempts 185
pingCmd
defined 184
OpenVMS 94
using 93
pinging
arguments 93
commands 93
InfoBox items 24
on OpenVMS 94
problems with 205
variables 184186
pingOkString 184
pingPacketSize 185
planning
installation 30
notification 58
platforms, supported 26
poll times
applying to agent 111
disabling 112
setting 107
practices, best 61
preloading KMs 52
preparing for installation 30
Primary (configuration variable) 183
problem resolution 197209
processWildcards
defined 189
using 111
product
application classes 23
architecture 16
capabilities 15
components 15
features 16
uninstalling in Windows environments 48
product support 3
PSL (PATROL Script Language) 124
R
ranges, alarm 106
recommendations, rule location 61
recovery actions
about 121
allowing 161
configuring 120125
enabling 121
examples 144
rule location 63
testing 149
redundancy 58, 60
RefreshParamSettings 193
remote agents, assigning notification servers to 73
remote installation 31
REMOTE_NOTIFY_EVENT
triggering 156
troubleshooting 203
defined 170
using 79
removing
annotations 181
customized KM files 43
menu commands 43
notification 85
renaming notification scripts 69
requirements
license 27
system 26
Unix account 28
Unix script 65
Windows account 27
Windows script 66
ResendAlertQueue 193
resending alerts 78
Reset AgentLoginDenied Alert menu command 204
restart, agent 206
RetriggerEventQueue 193
rewording
default notification message 81
example 136
messages 79
variables 81
221
rules
__OVERRIDE__ 174
See also configuration variables
active 180
alertLocalCommand 167
alertResend 167
alertResetOnInit 169
alertSystem 162
allowOperator 178
allowOverrides 163
arsAction 161
arsCmdType 168
arsCommand 168
Blackout 183
blackoutPeriod 174
checkerAccount.defaultAccount 186
copying 134
CustomId1 and CustomId2 178
customTargets 173
e-mail 154
emailTargets 171
example 153
filterList 190
filterType 190
hierarchy 153
hierarchy of 154
inheritance 154
inheritance of 154
interval 188
loginDeniedIgnoredUsers 164
msgBody 177
msgText 176
notification server 170
overriding 86
pagerTargets 172
paramSettingsStatusFlag 188
pingArgs 185
pingAttempts 185
pingCmd 184
pingOkString 184
pingPacketSize 185
Primary 183
processWildcards 189
RemoteAgentCommSettings 170
setParameterValue 166
snmpOid 182
snmpSettings 182
spoolDirectory 165
Targets 182
testing 84
Thresholds 186
ttTarget 173
Updated 183
222
rules, contined
useEnvOnlyForCmds 164
using wildcards in 107
where to locate 61
S
scalability 205
scenarios 128150
schedule, parameter 195
scheduling interval, setting 107
scripts
action 98
AlarmPoint 98, 99
AS/400 (iSeries) 67
backing up 69
batch file 66
customizing 69
editing 6769
Linux 64
OpenVMS 67
Perl 65
renaming 69
testing 70
Unix 64
using 6471
using exit statements in 202
Windows 65
security
account 28
changing levels 34
notification server 59
SED Utility 143
Send Distribution utility 67
send_mapi.vbs 66
sendmail.vbs 66
servers
deploying settings to 59
notification 71
setParameterValue
defined 166
using 103
setting environment variables for Help browser 45
shells
Bourne 45
C 45
Korn 45
SMTP scripts 67
snmpOid 182
SnmpPingFailures 194
snmpSettings 182
spoolDirectory 165
standard events catalogue 43
standard events, PATROL 19, 159, 205
StdEvent.ctg 43
StdEvents.ctg.EVS 205
stopping
notification 85
the monitoring of objects 112
subject line
back slashes in 81
length limitations 80
notification message 80
rewording 79
rewording variables 81
support, customer 3
supported platforms 26
system output window 208
system requirements 26
T
tabs in variables 157
targets
custom 21
example 136
rules 171174
using multiple 198
where to locate 61
Targets (configuration variable) 182
TCP port variable 157
TCP protocol 79
technical support 3
telnet, enabling 29
testing
AlarmPoint java client 97
notification scripts 70
notification using AlarmPoint 103
rules 84
thresholds
applying to agent 111
configuration variable 186
disabling 112
PATROL KM for Event Management 104
rule for 187
setting 104
tuning 201
time variables 158, 159
Tivoli 59
Trigger NOTIFY_EVENT option 101
triggering alarms 106
troubleshooting 197209
ttTarget
defined 173
using 70
typical installation option 35
U
UDP Port variable 157
UDP protocol 79
umask setting 29
uninstalling 48
units, parameter 194
Unix
account requirements 28
browser requirements 44
scripts 64
using for availability monitoring 61
unloading KMs
with the PATROL Console for Unix 57
with the PATROL Console for Windows 57
Updated (configuration variable) 183
upgrading 43
backing up scripts prior to 30
from an earlier version of the KM 43
useEnvOnlyForCmds
changing value of 199
defined 164
troubleshooting 198
user account 45
User defined variables 159
userdefined configuration variable 157
V
variables
alarm settings 159
alert 158
application class 158
date 158
event catalog 160
event class 160
event ID 159
event severity 160
event status 160
event type 160
hostname 157
icon name 158
instance name 158
IP address 157
maxEventsToReport 181
message-replacement 157161
OS type 159
parameter 158
parent instance 158
PATROL Agent version 160
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
224
Notes
*52965*
*52965*
*52965*
*52965*
*52965*

PATROL Knowledge Module For Event Management User Guide - 2.7 PDF

Uploaded by

Document Information

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 PDF

Uploaded by

Copyright:

Available Formats

PATROL KM for Event

Contacting BMC Software

United States and Canada

BMC SOFTWARE INC

713 918 8800 or

(01) 713 918 8000

713 918 8000

Outside United States and Canada

(01) 713 918 8800

Restricted rights legend

Support by telephone or e-mail

Before contacting BMC Software

operating system and environment information

sequence of events leading to the problem

commands and options that you used

product error messages

PATROL KM for Event Management

Product Components and Capabilities

Installing and Migrating PATROL KM for Event Management

Remove Customized KM Files From the PATROL_CACHE . . . . . . . . . . . . . . . . . 43

Using the PATROL KM for Event Management

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

PATROL Knowledge Module for Event Management User Guide

Sending E-mail Notification When Disk Space is Low . . . . . . . . . . . . . . . . . . . . . . . .

Storing the Encrypted Password as a Pconfig Variable . . . . . . . . . . . . . . . . . . . . . 147

Rules and Configuration Variables

PATROL Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

PATROL Knowledge Module for Event Management User Guide

CustomId1 and CustomId2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Parameter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Troubleshooting PATROL KM for Event Management

Installation Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

Accessing KM Commands and InfoBoxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

PATROL Knowledge Module for Event Management User Guide

PATROL Knowledge Module for Event Management User Guide

Notification System Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

PATROL Knowledge Module for Event Management User Guide

Product Components and

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

PATROL Knowledge Module for Event Management User Guide

Typical PATROL KM for Event Management Architecture

Rules Stored as Pconfig Variables

e-mail notification using a notification server

PATROL Knowledge Module for Event Management User Guide

Sending Notification: Process Flow

E-mail Notification Process

1. Alert occurs on remote agent NA

6. PATROL determines if a blackout

7. The alert is queued.

8. Determine whether notification is local alertSystem

10. Remote agent NotifiedEvent parameter NA

13. Repeat steps 4 through 10 on the

Multiple. See steps 4

14. The notification server executes the