The ABS's of Parameters and Thresholds PDF

Page 1 of 40
Susan E. Miller BMCS:CE

The ABCs of Parameters
and Thresholds

Author
BMC Software Business School

August 25, 2004

Page 2 of 40
Copyright 2004 BMC Software, Inc. or licensors, 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. BMC
Software, the BMC Software l ogos, and all other BMC Software product or service names
are registered trademarks or trademarks of BMC Software, Inc., in the USA and in other
select countries. And indicate USA registration or USA trademark. All other logos
and product/ trade names are registered trademarks or trademarks belonging to their
respective companies.

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 ti me 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.

Support

Support for this document is provided through the BMC Software Developer Connection Web site
ONLY and is governed by the BMC SOFTWARE SDK LICENSE AGREEMENT attached to
the end of this document.

BMC Software Developer Connection Web Site
The BMC Software Developer Connection Web Site generally available 24 hours a day, 7 days a
week at http:/ / devcon.bmc.com.

From this Web site, you can
n Converse with forum members and developers about BMC Software products
n Search the forums for information about BMC Software products
n Post questions and answers in forums for BMC Software products
n Find and download code examples, documents, utilities, and tools for BMC
Software Products
n Upload and share your code examples, utilities, tools for BMC Software Products

Page 3 of 40

Contacting BMC Software
USA and Canada

In the USA and Canada, you can contact BMC Software by telephone or fax:

Telephone (800) 537-1813 (Product Support)

(713) 918-8800 (Houston metropolitan area)
Fax Call Product Support for the fax number of your BMC
Software product support representative.
Email support@bmc.com

International

Outside the USA and Canada, you can contact a BMC Software international
support center:
Asia/Pacific, Africa, Europe, Latin America, and the Middle East
BMC Software Pte Ltd.
#18-02 Millenia Tower
Singapore 039192 - Telephone: (65) 338 9400
USA - Telephone: (713) 918-8800

You can also call the BMC Software office in your country, if applicable.
For a complete list of all BMC Software international offices and
subsidiaries, see the BMC Software home page at http://www.bmc.com.

BMC Software Business School

To register for training in North America, contact
http://www.bmc.com/education or call our toll-free registration line at 800-
574-4262.

For private, international training, or Web Based Training, contact the
BMC Software office in your area.

Page 4 of 40

Table of Contents
Table of Contents........................................................................................................Error! Bookmark not defined.
Setting and Defining Parameter Thresholds.......................................................................................................5
What Happens to the History?..............................................................................................................................14
Corrupted History......................................................................................................................................................16
Dumping History........................................................................................................................................................19
Accessing History.......................................................................................................................................................20
Setting Thresholds......................................................................................................................................................20
Best Practice............................................................................................................................................................26
Setting with Operator Overrides....................................................................................................................29
Using File Overrides...........................................................................................................................................31
PSL Overrides........................................................................................................................................................32
Developer Thresholds and the Developer.................................................................................................33
I n General......................................................................................................................................................................34

Authors Disclaimer
This is not a document published or supported by BMC Software therefore it is
considered an, unsupported document. Every, intent, has been made to provide
up to date accurate information herein using field expertise and BMC technical
reference manuals. This document has not been checked for grammatical
accuracy and therefore may contain some grammatical errors.

Page 5 of 40

Setting and Defining Parameter Thresholds
Since this document is about defining parameter thresholds, let us start by
defining what a parameter does and is. Parameters allow you to gather and
display metrics of an application using a PATROL application KM. A typical KM
can include any number of parameter scripts that collect various metrics. The
program that executes the data collection script for a parameter is called a PSL
process. The PSL process is the runtime for the parameter that is created after the
application is instantiated. (A parameter becomes active as soon as an
applications instance is created. This is true for all of the parameters defined in
the application class.) Once the PSL process is created for a parameter, it is
moved to the RUNQ of the PATROL job scheduler and is scheduled for
immediate execution; thereafter the execution scheduled is based on the poll
cycle of the collecting parameter.

Thresholds are used to cause a parameter to issue an event. Events inform you
that a value collected by the parameter is within a predefined range of values
that are not normal. Three rules determine whether a threshold can be set against
parameter objects. First the type of parameter must be a consumer or standard
parameter, second the parameter value collected must be numeric and last the
display type cannot be text.

Figure 1 - Defining the type of parameter

Page 6 of 40

Developing a Parameter

In order that one might entirely understand how to set a threshold it might help
to have some general knowledge about parameters, what they are, how they are
created and what they do. Parameters are the component of a PATROL
application, called a KM that provides the automation. They typically are used to
monitor something on a computer or network. This could be any number of
things like running processes, files, users, or a piece of hardware. Parameters can
also be used to execute any type of automated task.

Based on the previous section we know that a parameter is created as part of a
KM. A KM file contains the source code for a PATROL application. Within the
agent namespace a KM is an application class. When a KM is loaded on an agent,
the agent uses the compiler within its virtual machine to compile the source code
into something called quad code. The quad code is optimized automatically into
optimized quad code which is the virtual machine instructions. It is from these
instructions that the runtime (PSL process) is executed.

A runtime is created for each collector and standard parameter that is part of the
KM. (A discovery process is created for the KM only when a developer defines a
custom discovery cycle.) In the namespace each KM has its own symbol tree,
which is part of a three level object hierarchy, Application Class, Application
Instance, and Parameter. A parameter is part of a particular application class and
is an attribute of an application instance.

When dealing with the object hierarchy in PATROL, the highest level of this
hierarchy for a KM is the application class which is only visible if the developer
creates a container for the class object. Under the application class there can be
one or multiple instances of the class. When parameters are created for a KM
they belong to the KM tree they are running under. Even though a parameter
belongs to specific class, a parameter can collect data for any PATROL
application. All PATROL applications are located under the root object which
appears as the computer instance on a PATROL console. The object hierarchy for
the PATROL agent is as follows;
1. Root =Computer Instance =/
2. PATROL KM =Application Class =__name__ =/ <APPLICATION (KM Name)>
3. Application Instance =/ <APPLICATION (KM Name)>/ APP_INSTANCE
4. Parameters =/ <APPLICATION (KM Name)>/ APP_INSTANCE/ PARAMETER

Page 7 of 40

Creating the Parameter
To create a parameter a developer uses a PATROL Classic Console running in
developer mode and adds a parameter object to a KM. They typically write a PSL
script that essentially goes out checks the object and returns a value that
indicates something about the monitored object.

Parameters have some mandatory properties. These include a unique parameter
name, which will identify the parameter in the namespace, the parameter type, the
parameter script and the activeflag. The nameof the parameter can be anything
but cannot contain spaces. Recommended naming conventions for a parameter
are to name the parameter with the first two or three letter of the KM followed
by initial capitalization. Once the name has been defined for a parameter, it
cannot be changed.

The type of parameter can be a standard, collector, or consumer. The script used
for a parameter depends on the type of parameter. Collectors can only be written
in PSL, as they use the PSL set() function to set a collected value to a consumer
parameter. Standards can use any language. If written in PSL a standard
parameter can act like a collector. Consumers have no script as they get their
value from a standard or collector parameter. The parameter active flag is a
toggle that allows you to turn on or off parameters.

The type of parameter you are defining will determine the execution properties.
Parameters that are responsible for collecting data will have to execute scripts to
gather the data. All parameters scripts must have a command type defined for the
script. You can only use command types that are defined on the application level
or computer class level. By default, the command types 'OS' and 'PSL' is always
available, however a PATROL developer can add any number of additional
command types. The command types tell the agent what language to execute or
compile the script in.

Page 8 of 40

Two other parameter definitions are the environment and style. The environment
allows you to define OS environment variables you might need in order for your
command to execute correctly. In addition to an OS environment variable the
environment variable's value can contain % macros for example %{/ hostname}.

The styleof the parameter can be one of six styles, Graph, Gauge, Stoplight, State
Boolean, No Output, and Text. The default type is No Output. Thresholds
cannot be set against all parameter types except those which collect text. In the
case where you want to display collected text and set a threshold you might
want to consider using a standard parameter that collects the text value and a
consumer for the threshold. For example:

#Count and display the Users in /etc/passwd

openFile=cat(/etc/passwd);
getUser=nthargf(openFile, 1);
count=lines(getUser);

set(value, openFile);
set(../UserCount/value, count);

Other properties for a parameter might include credentials that would be needed
to execute a command. You could hardcode OS credentials in a script, but most
developers know you are opening yourself up for a security risk as well as a
maintenance problem, because this would force you to modify the KM whenever
the username or password of an application changes.

The most efficient type of parameter in most cases will be a collector parameter.
A fairly common example of collector could be described as follows: Suppose
you wanted to monitor the number of errors found in a log file. A developer
would write a PSL script that would use multiple functions and typically would
begin by getting the size of the file, store that initial size in a configuration
variable in the agent configuration database, and then use functions like fseek()
and ftell() to determine where the last read left off. Channel functions like fopen()
and read() would be used to open and read the log file. The grep() function
might be used to search for an error, and the lines() function might be used to
count the number of errors. The number of errors found is set using the set()
function to the namespace where the current value is stored. This is the value
that is analyzed against any thresholds set for the parameter object.

Page 9 of 40

Consumers would be used to store and display the values collected by the
collector. If you used a standard parameter for this you would have to write a
parameter for each action you want to perform, thus resulting in a very efficient
KM.

The last definition of the parameter to describe is the poll cycle. The poll cycle is
set only against collector and standard parameters and indicates how often to
execute the PSL process and return a value. Each time the process executes a new
value is collected, saved in the namespace and written to the parameter history
database at the appropriate time. Only the most current value is kept in the
namespace. Previous values are kept in the history cache until written to the
history database.

Schedules for parameter execution can be set using a number of methods. The
initial schedule however is typically set by the developer. Parameter processes
can be scheduled directly on the parameter property sheet by the hour, minute,
second, day, week, month and at specific intervals. Poll schedules set with PCM,
the Event Manager KM or from an operator console can be scheduled by the
minute or seconds. (The interval you can set at is based on which tool you are
using.) As an additional note, when you define scheduling information for
parameters that execute on an irregular schedule you should keep in mind that if
the agent is down during the requested execution time, the command will not
execute. Sometimes this leads to confusion.

Figure 2 - Setting a Poll Cycle

Page 10 of 40

If you instruct the agent to start your process at 1:00 PM and the agent was down
at that moment, but started back up at 1:05 PM, it does not know it should start
the execution for your command and will wait until the next scheduled time.
Therefore if you have a command that executes in this manor you would need to
build in some type of check and balance system.
You can set at schedule to Start Immediately, Set by hour, minutes, seconds, or
Start on - every day of the week, some days or a particular day. The default
setting is every - 10 minutes.

We briefly mentioned that parameters thresholds cannot be set against a PSL
process that is collecting a textual value. Let us delve into that a little further. In
my example suppose a developer was using a command to get the uptime of a
server. The uptime would be returned as the number of hours a system has been
up which would include something like 2 Days, 12 hours and so forth. Suppose
you wanted to know the total uptime and set an alarm condition if the uptime
was less than 24 hours? Since the value returned is text you would not be able to
set a threshold against the collected value unless the developer converted the
collected values to numerical values. The script below demonstrates how that
could be done for example:

#-----------------------------------------------------
up=get("/uptUptime");
print("\n", up);
daysUp=nthlinef(up, "1");
hoursMin=nthlinef(up, "3");
hoursUp=ntharg(hoursMin, 1, ":");
minUp=ntharg(hoursMin, 2, ":");

convertDays=daysUp * 24;
addHrs=hoursUp + convertDays;
calMin=minUp / 24;
calculate=addHrs + calMin;
print("\nUpTime ", addHrs);
addMin=addHrs.minUp;
set(value, addMin);
print("\nNew Time is Hrs plus Min: ", addMin);
print("\nuptime ",calculate);
#-----------------------------------------------------

Now in the above example, if the developer wants to set a threshold he could.
But what if they had a case where they could not convert? In this case they
would need to manually set a value.

Page 11 of 40

Lets say for example you are looking to see if a file exists. First you would check
for the file using for example the file() function which returns the timestamp of
the file. Since you dont care about the timestamp and only want to know if the
value exists you would be looking for a true or false condition. In this case if the
value is returned, you have a true condition and you would manually set a value
indicating true for example:

#-----------------------------------------------------
chkFile=file(mydatafile.txt);
if(chkFile != )
{
set(value, 1); #Its there
}
else
{
set(value, 0); #Its not there
}
#-----------------------------------------------------

What Exactly is a Threshold?
Thresholds are alarm ranges used to define a scope of numeric ranges for
incident management. A PATROL Agent uses the thresholds to detect potential
problems. Each time a parameter process is executed the agent automatically
evaluates and compares collected value with defined ranges. If a range is crossed
an event is triggered along with any associated recovery actions or annotations.

A PATROL Developer typically will set initial parameter thresholds (alarm
ranges) for a variety of reasons. For example, it enables immediate use of the KM
after load, it allows the developer to add recovery actions directly to a KM and it
provides the ability to test and certify the recovery action. PATROL
Administrators use override tools to override the thresholds set by the developer.

When a collected value crosses a defined threshold and an event is triggered the
state of the object icon immediately changes. The object state of a parameter by
default is propagated to the highest level of the object hierarchy on a PATROL
Console. Event triggers which are defined as part of the PATROL Event
Management engine control the propagation. When a threshold is crossed if
recovery is defined, the appropriate recovery action will be automatically
executed.

Page 12 of 40

Thresholds are defined in two parts, a defined range of numbers that are set
against a standard or consumer parameter and a state, OK, ALARM or WARN.
(Thresholds cannot be set against collector parameters or parameters that collect
text.)

Before setting thresholds an individual would typically create a baseline to
determine what is normal for their environment. This usually involves turning
off any alarm settings which have already been set by a developer directly to a
KM or by an administrator using some type of override. There are several
methods that could be employed to turn off thresholds settings, but we will just
discuss the easiest method. If you install the Change Spring KM from Event
Manager you can use a menu command provided as part of the KM to generate
documentation of whats currently set and as well a set of pconfig variables that
you can apply to turn off the current settings.

To get a baseline once the alarm settings are off, just collect data for fairly good
period of time, for example three to four days. This will get enough data to get
the proper averages. This data is then analyzed to determine what the average
collected value is. (Make sure your history retention period is longer then your
collection period, if you are going to collect for four days, set the history to five
days.) The history can be pulled and averaged using the charting functions, a
PSL script or various other methods. It is from this data that you determine what
normalized data is.

Once you know what the normal range of values is, you set a threshold based on
the abnormal range of values. The range of values defines the scope of what an
abnormal value would be.

In addition to setting the range of values for the parameter object, the
administrator setting the thresholds also sets the state. The state and the range
are physically 2 different things. Essentially when a value is collected it is
analyzed to determine if the collected value falls within the range of defined
values and then if it does it changes the state of the parameter to the state defined
as part of the threshold for the object to the value of state that was defined.
Internally the state of the object becomes the object status. Each time a value is
collected that crosses a threshold an event is generated. PATROL Developers
typically set base ranges and define the alert types for a parameter.

Page 13 of 40

A couple of key notes to be aware of are as follows, alarms must be enabled
before values can be defined, values can only be set numerically. Once defined, a
developer can create an automated recovery action

Figure 3 - Example Baseline Documentation

A final note about parameters is that history is only kept on objects that collect
numeric values. Therefore for example the following values collected in this
example script would not be available as part of the parameter history. In cases
where the values collected contain critical data a developer might display the
collected data with a textual display for the parameter and then would write the
data out to a log file. For example:

curProcs=process("*");
procNum=lines(curProcs);
curTime=asctime(time());
#Create the message - Assign the values collected for a report
mess="\nCollection time is:\n" .curTime."\nCurrent value is: ".procNum.
"\n";
#................................................................
fileName=get("patrolHome")."/log/AVGNumProcLog";
openChan=fopen(fileName, "a");
write(openChan, mess);
close(openChan);
set("value",mess);

Page 14 of 40

What Happens to the History?
Once collected the history for parameters is stored in the parameter history
database. This database is comprised of three binary files, the param.hist, dir and
annotate.dat. The param.hist file stores the parameter data, annotate.dat stores
additional data collected using the annotate() function usually text, and dir is
essentially a type of pointer that keeps the two files in line with each other.
Collected data is flushed (or written) to the history database on predefined time
frames which are defined in several variables in the agent configuration
database.

In addition to the history files, the PATROL Agent has environment variables
that enable you to define where the agent creates the history database. You can
designate a location in or out of the PATROL directory structure or on another
host within the network provided the agent has static access to the location. In
addition to defining a directory, you can establish a location by port number.
This feature allows you to accommodate a host with multiple agents by directing
each agent running on a unique port number to write to a different history
database.

Index file - the history index file does not have a file size limit.

$PATROL_HOME/ log/ history/ hostname/ port_num/ dir
%PATROL_HOME%\ log\ history\ hostname\ port_num\ dir

History text annotation file

$PATROL_HOME/ log/ history/ hostname/ port_num/ annotate.dat
%PATROL_HOME%\ log\ history\ hostname\ port_num\ annotate.dat

History data file
$PATROL_HOME/ log/ history/ hostname/ port_num/ param.hist
%PATROL_HOME%\ log\ history\ hostname\ port_num\ param.hist

The environment variables include the default which is stored under -
PATROL_HOME. For Windows it is log\ history\ agent-name\ agent-port and
for UNIX it is log/ history/ agent-name/ agent-port.

Page 15 of 40

The PATROL_HISTORY variable can be defined to change the location of the
parameter history files.

Another variable is the PATROL_HISTORY_PORT variable. If this variable is
empty or doesnt exist, the agent writes the history files to
PATROL_HOME\ log\ history\ host\ port number. The last variable is
PATROL_VIRTUALNAME - PATROL_VIRTUALNAME_ PORT which is used
for Cluster Specific - an alias for the host name

One point we should make is that parameter history is not the same as parameter
events. History is kept in the history database (repository), while events are kept
in the event log repository file. History deals specifically with parameters and
the values collected by the parameter PSL processes, while events in PATROL
occur anytime an object changes state. This includes parameters going into or out
of alarm, connecting to an agent, disconnecting, informational events etc.

As far as when history is written out to disk, this is governed by configuration
variables. These variables control how often history is written to the history
database. There are two ways - (not mutually exclusive) - that history is written.
Using a time interval where the agent writes data points to the history database
when the time interval expires and the number of data points where the agent
writes data points to the history database when a parameter collects a specified
number of data points. In both cases the agent writes information to the history
database more frequently than if only one method is activated. The agent writes
once when the time interval expires and once when a parameter collects the
specified number of data points.

The /AgentSetup/prmHistCacheFlushTimer configuration variable determines
the period of time that the cache is flushed to the history database. Flushing is
based on a defined time frame how often? This time frame is used to
determine the period of time that the cache is flushed to the history database. A
default of 1200 seconds (or 20 minutes) is predefined. The minimum setting for
this is 5 minutes.

The number of intervals is stored in the /AgentSetup/prmHistCacheSize
configuration variable. This defines the number of data points allowed in the
cache, before writing the cache to the history file. For example, if you set the
value of prmHistCacheSize to 10, when the agent has collected 10 data points for
a parameter it writes the data to the history file. The default value for this is 16.

Page 16 of 40

Essentially the process of writing out history could be entirely turned off if this
value was set equal to or less than a value of 1. Care should be used in changing
these values thus avoiding the accidental turning off the process of recording
history.

The last variable used that controls the writing out of history is the
/AgentSetup/prmHistCacheMaxFlushTime configuration variable. This defines how
much time the agent spends writing cache data to a history file. For example, the
default which is set to 600 seconds, tells the agent stops writing cache data to the
history file after 600, seconds even if it has not written all the cache data to the
history file.

The amount of history retained is based on how one, sets, the history retention
period. This is also stored in an agent configuration variable
/ AgentSetup/ historyRetentionPeriod. This configuration variable determines
the number of days that collected parameter values, is, retained in the history
database. After this retention period has expired, the agent deletes the retained
information. The history files are circular and data is removed in a cyclic fashion.

Cached or stored history can be accessed through any PATROL Console Central
or Classic.
Dealing with Corrupted History
As discussed above how often history is written to the database depends on the
setting of agent configuration variables. Therefore if an agent was shutdown
abruptly history can become corrupt. This is because the agent was shutdown
before it had a chance to write out all of the history or was in the process of
writing out history at shutdown time.

When you see these problems it is usually associated with an error message like
parameter history inconsistencies found! The only way these problems occur
with the history database is through undesirable incidents like an abrupt shut
down of the PATROL Agent. So what is the actual result of an abrupt shutdown?
An abrupt shutdown leads to one or more pointers in the dir file pointing to
erroneous data in the other two files. In addition to our previous statement
corrupted history leads to several other things, a block of data that is no longer
available or unreadable but most importantly it could cause the agent to consume
excessive amounts of CPU and memory.

Page 17 of 40

The fix_hist command can be used to try and solve these problems by removing
the errant pointers and packing the related files: dir, annotate.dat, and
param.hist. Often you will only find out that your history database has these
problems when you see an error message similar to the following: "Found
inconsistency in hist param database." The fix_hist utility scans the entire history file
and resynchronizes the database and its indexes. Unfortunately however in
removing errant pointers some data is lost.

When using fix_hist while it is reading the annotation database, the fix_hist
utility creates a file. When the utility encounters an error that it cannot repair, it
saves the data that it has already read and discards the data that is unreachable
due to a corrupted pointer or other error. The fix history utility backs up the
history database files that it attempts to repair by appending "~#~" to each file,
for example param.hist.~3~. The utility then writes the recovered information to
the history database files, for example param.hist.

There are several options that can be used to fix history. For example, shutting
down the agent and running the fix_hist utility. Cleaning up history by removing
history no longer needed using a PATROL Console Option under parameter
menu called Clear History and in the most dire cases when history cannot be
fixed dumping the history to a comma separated file and then using dump_hist
from a command line, followed by shutting down the agent and relocating the
damaged annotate.dat, dir, and param.hist files. In this case on agent restart new
versions of the files are created

To Repair History for an Agent on a Specific Port

This command fixes history and packs the data and index files at port 5000.

fix_hist -p 5000

To Scan the History Database a Maximum of Two Times
This command fixes history and packs the data and index files for host host1 at
port 3181. It will scan the history file a maximum of two times.

fix_hist -host host1 -p 3181 -repair_cycle 2

Page 18 of 40

To Repair History Database without Packing Index Files
This command fixes history for host host1 at port 3181. The history index file is
not packed.

fix_hist -host host1 -p 3181 -no_pack_hist_index

To Pack Index Files without Repairing History Database
This command packs the files for host host1 at port 3181. The history files are not
scanned and fixed.

fix_hist -host host1 -p 3181 -no_repair_hist

To summarize remember that history is only corrupted when the PATROL
Agent is shutdown ungracefully. There are three main ways this can happen, the
computer crashes, the computer is shutdown gracefully, but the PATROL Agent
was left running (occurs on windows when agent is run as a process) or on Unix
the PATROL Agent process was killed using the 'kill -9' command.

There is an optional flag that can be set in the agent configuration database that
can be used to tell an agent how and when to fix history. This variable is called
"/ AgentSetup/ fixHistFlag" which has a default set of never.
.
Always repair - unconditionally
Only repair when the dirtybit is set
Never repair on agent startup

An important thing to note is that the PATROL Agent almost always has the
history file open for writes. Since we know that if the PATROL Agent is brought
down ungracefully, the history file most assuredly will get corrupted. So a good
practice would be to shutdown the PATROL Agent before shutting down the
computer on systems where the agent runs as a process. The proper way to kill a
PATROL Agent is to use the pconfig 'kill' command. On UNIX do not use kill -
9, this forces the Agent to shutdown without giving it a chance to close its files.
You can add some lines of code to your OS shutdown script to kill the Agent
prior to OS shutdown.

pconfig +KILL [+verbose] [-port port number] [-host hostname]

Page 19 of 40

About Dumping History
History can be dumped from a command line using dump_hist. If you use this
command with the format option you can generate a dat file for a database. You
can also include options to generate a comma separated file that can be opened in
Excel.

dump_hist format

The following command produces a .dat file for databases like Oracle, Sybase,
and Microsoft SQL Server.

dump_hist -format ",,%H,%A,%I,%P,%y-%m-%d %h:%M:%s,%v"

Options are placed between quotes using characters like commas, pipe symbol,
and dashes to separate values

%H host name, %A application name, %I instance name
%P parameter name, %y year (yyyy), %m month (mm)
%d day (dd), %h hour, %M minutes (MM), %s seconds (ss)
%v parameter value stored in param.hist file

The output of the above would produce something like the following for each
value.

- ,,smile,USERS,USERS,USRNoSession,CCYY-10-16 20:51:53,22

Page 20 of 40

Accessing History
In addition to the dump_hist command, history can be accessed using the PSL
history() function, or viewed through PATROL Console charting. Several
example scripts are provided below:

Using the Charting Functions to Get the History Averages

This is an example script that uses various functions to average history and is
executed from a menu command.

requires response_def_lib;
requires unix_misc_lib;
response_def();

buf = system("%DUMP KM_LIST");
buf = nthlinef(buf,"4-".(int(lines(buf)) - 1));
kms = "";
foreach lin (buf)
{
kms = kms . ntharg(lin, 2) . "=0\n";
}
kms = sort(kms);
resp_ret = response("APPLICATIONS",-1,"h=430,w=395",
LABEL."Select Application(s)",
SEP_HORIZ,
LIST_MULTIPLE.kms
);
act = trim(nthlinef(resp_ret,1), "\n");
if (act)
{
sel_list = trim(nthlinef(resp_ret,2), "\n");
apps = "";
foreach word sel_num (sel_list)
{
apps = apps."/".nthargf(nthlinef(kms, sel_num), 1, "=") .
"\n";
}
insts="";
parms="";
buf="";
foreach line appline (apps)
{
app_name=ntharg(appline,1);
insts = get_vars(app_name, "nodes");
insts = nthlinef(insts,"3-");
foreach line instline (insts)

Page 21 of 40

{
inst_name=app_name."/".ntharg(instline,1);
buf = get_vars(inst_name, "nodes");
buf = nthlinef(buf,"3-");
foreach line bufline (buf)
{

parms=parms.inst_name."/".ntharg(bufline,1)."=0\n";
}
}
}
parms = sort(parms);
resp_ret = response("Parameter Average Chart",-1,"h=430,w=395",
LABEL."Select Parameters to Chart",
SEP_HORIZ,
LIST_MULTIPLE.parms,
SEP_HORIZ,
RADIO_HORIZ."Monthly=1\nWeekly=0\nDaily=0\nHourly=0\n",
SEP_HORIZ
);
action = trim(nthlinef(resp_ret,1), "\n");
chart_type = trim(nthlinef(resp_ret,3), "\n");
if (chart_type == 1) {timestring="%m"; header="Monthly ";}
elsif (chart_type == 2) {timestring="%U"; header="Weekly ";}
elsif (chart_type == 3) {timestring="%j"; header="Daily ";}
else {timestring="%j%H"; header="Hourly ";}

if(action)
{
patrolhome=get("/patrolHome");
gdf_string="ChartTemplate:
".patrolhome."/lib/chart/line.ctf\nChartTitle: ".header."Parameter
Averages\n";
sel_list = trim(nthlinef(resp_ret,2), "\n");
foreach word sel_num (sel_list)
{
selparm=nthargf(nthlinef(parms, sel_num), 1, "=");
histlist=history(selparm,"tv");
firsttime=1;
total=0;
prevts=0;
prevgroup=0;
average=0;
datapoints=0;
#print (selparm, "\n");
gdf_string=gdf_string."StaticData2D:".selparm;
totlines=lines(histlist);
histlines=0;
foreach line histline (histlist)
{
histlines++;
histts=ntharg(histline,2);

Page 22 of 40

histval=ntharg(histline,1);
histtime=asctime(histts,timestring);
#print ("TS: ",histts," val: ",histval," group:
",histtime,"\n");
if (firsttime)
{
total=histval;
datapoints=1;
prevts=histts;
prevgroup=histtime;
firsttime=0;
}
elsif (totlines == histlines)
{
datapoints++;
total=total + histval;
prevts=histts;
average=total / datapoints;
lavg=", ".prevts." ".average;
#print ("Chart: ",prevts,"
",average,"\n");
gdf_string = gdf_string.lavg;
}
else
{
if (prevgroup == histtime)
{
total=total + histval;
datapoints++;
prevts=histts;
}
else
{
average=total / datapoints;
lavg=", ".prevts." ".average;
#print ("Chart: ",prevts,"
",average,"\n");
gdf_string = gdf_string.lavg;
total=histval;
datapoints=1;
prevts=histts;
prevgroup=histtime;
}
}
}
gdf_string=gdf_string."\n";
}
#print (gdf_string);
chart(CHART_LOAD,gdf_string);
}
}

Page 23 of 40

Using the history() Function for Simple Averaging

This is an example script that can be added as a menu command that asks the
user which parameter to average the history on.

whatParam=%%{What Parameter place the full path in
quotes};

cpuHist=history(whatParam,"tv");
data=ntharg(cpuHist, "1");

numProcs=lines(data);

foreach entry(data)
{
simVal=simVal + entry;
}
averVals= simVal / numProcs;
print("Average number of processes is: ", averVals);

What Methods are Available for Setting Thresholds and what are the
Rules?
Currently there are several methods available to set thresholds. These include
PCM, Event Manager KM, Operator Overrides, Developer Overrides, PSL
Overrides, and File Overrides. Where you set the threshold and how the agent
stores the setting depends on which method you chose. Lets start with the
method which is considered Best Practice in this method we set the threshold
using PCM.

However, before we actually start discussing the various methods for setting
thresholds lets cover a couple of rules. Thresholds are defined based on ranges.
Ranges are controlled by a range setting directly on the parameter property
sheet. In addition to setting a range, you can set one to three alarms or all. Alarm
types are BORDER, ALARM1 and ALARM2.

Page 24 of 40

The Border alarm is controlled by the range setting. You cannot set a range
beyond what is set for a border alarm. The values you set for ALARM1 must
always be numerically lower than the value set for ALARM2. In regards to the
setting of the thresholds themselves you should ensure that when setting the
values that there are no gaps in the settings.

Three Alarm Types
Border
o Border - minimum and maximum expected values
Alarm1
o Range of values indicative of problem must share common end-
begin point values with Alarm2 when set. (No gaps)
o Range values for Alarm1 must be less then Alarm2

Alarm2
o Range of values indicative of problem
o Range of values indicative of problem must share common end-
begin point values with Alarm1 when set. (No gaps)

If is of note to point out that if you have a range defined of 0 100, settings of 50
to 75 for ALARM1 (WARN State) and 75 to 100 for ALARM2 (ALARM State),
and you capture of value of 75, an ALARM1 state will be triggered and the
parameter state will be changed to WARN.

Figure 4 - Other states include, Suspended, or Offline

Page 25 of 40

To see a parameters state they visually are located at the lowest level of the object
viewer which would be a PATROL Console. The visual states indicate the
parameter condition. Parameters can be in one of five conditions, Alarm,
Warning, Offline, Suspended, Message, or OK.

Range Definitions include the following:

Range Limits
o Range Limits Minimum, Maximum (unlimited)
Default Min 0 - Max 100
Used to define the entire spectrum of possible values (Set by
developer only)
Auto Scale (Enabled by default)
o Visual setting that scales using actual minimum and maximum
parameter values (Set by developer only)
Border, Alarm1 and Alarm2
o Range of values determined by baseline
o Border used to control range limits when a PATROL administrator
overrides a developer setting.
o Ranges cannot be set beyond the range limit

Figure 5 - Example Range of Values

Page 26 of 40

PCM and Best Practice
Realistically when we discuss Best Practice there are two methods - PATROL
Configuration Manager (PCM) and the PATROL Event Manager KM. Since PCM
uses the Event Manager KM behind the scene they are essentially the same. Both
of these methods store the settings in exactly the same location in the agent
configuration database.
Key Notes Concerning PATROL Configuration Manager (PCM)

Although PCM writes its threshold to the same location in the agent
configuration database as the Event Manager KM -
(/ AS/ EVENSPRING/ PARAM_SETTINGS/ THRESHOLD) folder it can only be
used if parameter files exist for the KM. Typically parameter files are available
for most BMC Solution knowledge modules. See the following example of how
the threshold is written to the agent configuration database with PCM.

Example:
"/ AS/ EVENTSPRING/ PARAM_SETTINGS/ THRESHOLDS/ PSLBAS-
ADMINISTRATOR/ __ANYINST__/ ADMCurNumProc" = {REPLACE = "1,1 0
500 0 0 2,1 250 300 0 0 1,1 300 500 0 0 2"}

Figure 6 - PCM Overrides

Page 27 of 40

PATROL Event Manager KM
The second method is to use the PATROL Event Manager KM. essentially this is
the same as setting through PCM as they both write the threshold to exactly the
same location.

Set using menu commands from a PATROL Console, writes to the same location
as PCM: / AS/ EVENSPRING/ PARAM_SETTINGS/ THRESHOLD folder.

Example:
"/ AS/ EVENTSPRING/ PARAM_SETTINGS/ THRESHOLDS/ PSLBAS-
ADMINISTRATOR/ __ANYINST__/ ADMCurNumProc" = {REPLACE = ""1,1 0
500 0 0 2,1 250 300 0 0 1,1 300 500 0 0 2"}

Figure 7 - Event Manager Thresholds

Page 28 of 40

Interpreting the PCM and Event Manager Setting:

To interpret this we will break it down by the value you see:

Item Description
"/ AS/ EVENTSPRING Variable Folder
/ PARAM_SETTINGS Variable Folder
/ THRESHOLDS Variable Folder
/ PSLBAS-ADMINISTRATOR Application Class
/ __ANYINST__ Any Application Instance or could be a
specific instance
/ ADMCurNumProc" Parameter
1 This alarm is active
1 Border range is active
0 Begin value
500 End Value
0 Trigger when 0 means immediately on
alarm.
0 If trigger value something other than -0- this
would be the number of times before
2 State ALARM
1 Alarm 1 setting is active
250 Begin value
300 End Value
alarm.
1 State - WARN
1 Alarm 2 setting is active
300 Begin value
500 End Value
alarm.
2 State - ALARM

Page 29 of 40

Setting with Operator Overrides
Prior to the release of the PATROL 3.3 it was a common practice to write
parameter thresholds settings for the baseline properties of a parameter directly
to the KM. This resulted in a huge amount of effort and time in managing
parameter thresholds. Additionally, if an upgraded KM was installed you had to
migrate changes from one version of a KM to another. If you only had a few
servers this was no big deal, but if you had 50 plus, or 25 plus servers this
required a huge effort.

Operator overrides were introduced with PATROL version 3.3 and stored the
thresholds in the agent configuration database. Essentially it worked using the
following methodology. The first time a user set an operator override, the agent
would automatically add a new variable folder to the agent configuration called
__tuning__. A new folder was then created for each application class under the
tuning folder with a sub folder for each instance. The variable name was linked
directly to the parameter name. The agent would load the values set with
overrides over top of the developer settings and use the overrides. For example:

/___tuning___/NT_CPU/CPU_0/CPUprcrProcessorTimePercent

Values were stored numerically with each set of values tied directly to a Boolean
value of 1 or 0 indicating whether a setting has been created for the value.

Page 30 of 40

The authority or right to set thresholds using this method was dependent upon
the variable allowoverrideparameter in the patrol.conf file being set to true.

Operator overrides are similar to PATROL Event Manager and PCM. Operator
overrides uses 22 fields which contain either digital values or the actual state to
indicate the ranges as well as whether a setting is active or inactive. For example
you might see something like the following:

1, 365, 600, 1, 0, 500, OK, 1, 400, 450, WARN, 1, 450, 500, ALARM, 1, 1, 0, 0, 0,
0, EOD

Field Definition
Field Position 1: Is the override active?.
Field Position: History retention period.
Field Position: Polling interval? (Always -1 for
consumers.)
Field Positions 4, 5, 6 and 7: Border Alarms.
Field Positions 8, 9, 10 and 11: Alarm1
Field Positions 12, 13, 14 and 15: Alarm2
Field Positions 16 21: Trigger When?
Field 22: EOD

Page 31 of 40

Using File Overrides

This method relies upon the use of external files as a method for managing
parameter overrides for environments with a large number of agents. In this
method, parameter overrides are stored in one or more external files. The
PATROL Agent periodically checks if an external override file has changed or if
a different external override file should be used based on the setting of a time
based agent configuration variable. If a file or its contents change, the PATROL
Agent implements the new overrides. These settings can be stored in a single file
or in multiple files in the same directory.

In order to use file overrides a variable called allowexternaloverridemust be added
and set to true in the patrol.conf file under the agent rights section

This in turn allows the user to writes the overrides to a file which has precedence
over operator. The user sets the file location (Relative Path) in the agent
configuration database using a variable:

"/ AgentSetup/ ExternalOverride" = {REPLACE=File-Name"}

By default the agent looks for the file under PATROL_HOME/ lib/ admin
directory. In addition to setting the location the user defines a Poll Timethat tells
the agent how often to check the file for changes.

"/ AgentSetup/ ExternalOverridePolltime" The default is 600 seconds, the
minimum is 60 second.

In addition to the above settings the user creates a file named @timestamp file
(no extension.) When you store override definitions in a single file, the PATROL
Agent periodically checks the timestamp of the file to see if it has been updated.
If the file has been updated, the Agent implements the new parameter override
definitions contained in the file. When you store override definitions in multiple
files, the PATROL Agent checks the directory containing the files for updated
definitions. If the files contain new definitions, the Agent implements them.

Page 32 of 40

Example Parameter Overrides File
[/ NT_LOGICAL_DISKS/ / LDldDiskTimePercent]
ACTIVE=1
BORDER_ACTIVE=1
BORDER_MINIMUM=10
BORDER_MAXIMUM=90
BORDER_STATE=ALARM
BORDER_ALARM_WHEN=ALARM_INSTANT
BORDER_ALARM_WHEN_N=0
ALARM1_ACTIVE=1
ALARM1_MINIMUM=50
ALARM1_MAXIMUM=70
ALARM1_STATE=WARN
ALARM1_ALARM_WHEN=ALARM_INSTANT
ALARM1_ALARM_WHEN_N=0
ALARM2_ACTIVE=1
ALARM2_MINIMUM=70
ALARM2_MAXIMUM=90
ALARM2_STATE=ALARM
ALARM2_ALARM_WHEN=ALARM_INSTANT
ALARM2_ALARM_WHEN_N=0
ALARM2_DO_RECOVERY=NO

PSL Overrides

This is the process of using the PSL function set_alarm_ranges() to change the
alarm ranges of a parameter. This method is useful for intelligent Knowledge
Modules that determine their own alarm ranges during run-time. Additionally
this method could be used to quickly change a setting. This method overrides all
of methods therefore use of this method is not recommended for regular use as it
could be CPU intensive and resulting in problems if parameters are frequently
changed.

new_ranges= "0 1 99 0 0 0\ n0 80 90 0 0 0\ n1 90 99 1 0 2";
result= set_alarm_ranges(new_ranges,"","","","/ FILESYSTEM/ root/ FSCapacity");

Page 33 of 40

This ability to use psl to set or change ranges is dependent upon a setting in the
patrol.conf file under the agent rights section. Default is set to true.

[Agent]
define Agentrights allrights
allowpsloverride = true
end

Developer Thresholds and the Developer

As part of the application logic when working with parameters, most developers
will predefine some type of initial thresholds using quantitative measurements. In
order to do this they need to make a judgment based on observations of the
application during the testing and certification phase. Because of these
quantitative measurement settings, the PATROL, software can begin monitoring
a system directly after it is installed.

In some cases, these preset thresholds can lead to some confusion about the
PATROL Software, as it appears that everything is in alarm at once. One simply
must realize that once PATROL has been installed; the thresholds set by the
developer must be fined tuned based on collecting data for a short time period
and then changing the thresholds (base-lining) of course this is accomplished
once you know what is average or normal for the system you are managing.

In all the methods described for the process of setting of the threshold they all deal
specifically with parameters. In all cases this setting is based on defining a range of
digital (numeric) values. These ranges define the numeric values that you have
determined to be abnormal. The values are used as an automatic measuring tool of how a
component is working. If the agent collects a value that falls within the defined range, it
will automatically trigger an event and take any appropriate event action, which could be
notification like email or paging the correct individual.

Once a threshold is set, one can add automatic reactions (recovery) that will occur when a
specific condition occurs. For example, the monitored object is a process and the process
is not running. A recovery action could check to ensure that the process is not running
and then restart the process.

Page 34 of 40

This functionality is the result of monitoring the status of the object using relational
operators (greater than, lower than, less than or equal.) For each parameter, the agent
collects the raw data measurement, and then converts the quantitative measurement into a
status (based on what you define for the state). Once the raw data is collected and
interpreted by the agent the status, becomes the condition to determine the reaction. (Thus
automation occurs status of an object and setting of a threshold, are two separate
actions.)

When thresholds are set, the values collected by a parameter are used to determine the
status of the managed objects health, once obtained the status is input to a control loop.
Control loops are observations and actions using single, multiple, inner or outer
loops.

About Recovery Actions

A recovery action is an action that can be executed when the values defined for a
threshold for a standard or a consumer parameter falls within or outside a
certain range. Recovery actions are stored and executed only by the PATROL
Agent. They can be used to send an e-mail message, activate a beeper, tune a
system that is in a certain condition, or initiate an action that will execute a
recovery procedure and can be added by a developer directly to the parameter
definition or with the use of PATROL Configuration Manager or the Event
Manager KM.

When defining recovery actions, it is very important that you understand how
alert ranges (thresholds) work. A recovery action definition is actually performed
based on a range, and the state is merely an attribute of this range. This means
that you can define recovery actions on OK states as well as alarm and warning
states.

A parameter can store a list of recovery actions associated with different alert
ranges that you have set in the parameter thresholds. When you create parameter
recovery action commands or tasks, you can use PSL functions, built-in
commands, and built-in macro variables. Recovery Actions are identified
numerically and are executed in the order that they are created. The example
below is intended to demonstrate how recovery actions are handled. In this
example the alarm ranges were set at 50 to 75 for alarm1 and 75 to 100 for alarm2
with two "recovery actions" for alarm1 and two recovery actions for alarm2. The
parameter scheduled was based on a 10 minute polling cycle.

Page 35 of 40

Time Value Action
1:00 48 OBJECT STATE OK
1:20 69 CHANGE STATE A1 WARN
EXECUTE RECOVERY A1R1
1:30 72 STATE REMAINS WARN FOR A1
1:40 30 CHANGE STATE TO OK
1:50 61 CHANGE STATE A1 WARN
2:00 65 STATE REMAINS WARN FOR A1
2:10 76 CHANGE STATE TO A2 ALARM
2:20 79 STATE REMAINS ALARM
2:30 80 STATE REMAINS IN ALARM
NO RECOVERY ACTION EXECUTED

The primary point to make here is that even though at 2:30 the collected value
was still crossed a defined threshold no recovery actions are executed by the
agent. This is because it had exhausted the list of recovery actions.

Page 36 of 40

In General

To delve further into the setting of thresholds we should discuss how PATROL delivers
its automation. We could say that PATROL uses value based automation. Value based
automation is a reaction which is a consequence of observing values, gathered by an
agent. These values are numeric (digital) scalar quantities (measured or observed values)
Scalar deals with a single item or value, which contrasts with vectors and arrays, which
are made up of multiple values.

With this when a value is collected, it is compared with the scope (alarm range) set for
the desired values. The result of this comparison (a simple algebraic difference) is used to
determine whether an action should occur or not. Internally an agent uses several control
types, intrinsic, internal, external and intelligent. A result that crosses the predefined
scope of desired values will be interpreted as a condition automatically, which is used as
input for Boolean logic (i f, then) which in turn determines the action the agent should
execute.

The optimal actuation of control (the process of putting into motion) can be quantitatively
calculated from the observation. For complex calculations, intelligent logic can used as
part of a PSL script to calculate the reaction that the agent should take. Reactions can be
complex or simple one- line statements.

When the agent has completed its calculation inside the control loop, the developer closes
the loop as soon as possible to the origin of the observation so that the logic for the
parameter executes as efficiently as possible. How simple or complex a calculation is
depends entirely upon the developer who wrote the parameter script. However, one
should be aware that to provide complex monitoring the intelligent autonomous agent
must be on the same system as the monitored object with direct complete access to the
objects being monitored and actuators of the controlled object. The PATROL intelligent
autonomous agent will derive the final status of the object based on the collected value
and its comparisons.
When a threshold is crossed an event is generated. Events occur in PATROL for
multiple reasons in fact since everything in PATROL is an object; anytime an object
changes state, an event occurs. Therefore examples of events would include items like
values collected for parameter objects that fall into the defined alarm range, when a
console connects-disconnects to an agent, a state (object status) is propagated to a higher
object level and so forth. This is typically called event based automation. In

Page 37 of 40

PATROL, events are managed by an internal event management engine called the
PATROL Event Manager. To express what an event is on simpler terms we could say
that an event means that something has happened, is happening or has changed for an
object. PATROL uses its internal event engine for event-based automation.

Even though events are triggered automatically by PATROL, you can still integrate
PATROL with some other type of event management system. For more granular event
management you could implement the PATROL Event Manager Knowledge Module,
which forwards all events to a central location where they are processed based on
event rules that you define..

With the PATROL Event Manager Knowledge Module, you can define and manage all of
your thresholds and automatic recovery reactions for any parameter in a single location.
Likewise, you can perform very granular event management for the handling of event
notifications. In most cases, you will notify someone that an event has occurred for the
managed object using some type of notification method like email, paging software and
so forth.

The PATROL event based automation engine keeps events in an event log as well as an
event repository. (Event repository is a location in memory) Every event is recorded as an
event record and is assigned a unique event ID. Event filters can be set at the source to
limit the types of event forwarded to either the PATROL Event Browser or another event
management system. An event record contains fields like the status, object name, the
time, the parameter object name, value, status and so forth.

The PATROL Event Manager engine allows for additional annotations to the event using
a descriptor that will allow the addition of additional information for event record
management. In addition, each event includes an editable diary field. For supporting the
monitored object, one can include a URL that can take a user responding to an event
immediately to a predefined web location where in depth detail could be provided for
how one should respond to an event that has occurred.

In conclusion, the management of thresholds and events does not have to be a
complex hard to understand process. The key is standardization. This means
choose only one method and use that method set and control all of your
parameter thresholds.

Page 38 of 40

BMC SOFTWARE SDK LICENSE AGREEMENT

THIS AGREEMENT APPLIES TO OPENING A PACKAGE, INSTALLING, PRESSING AGREE OR YES OR
USING BMC MODULES, THE ENTITY OR INDIVIDUAL ENTERING INTO THIS AGREEMENT AGREES TO BE
BOUND BY THE FOLLOWING TERMS, IF YOU DO NOT AGREE WITH ANY OF THESE TERMS, DO NOT
INSTALL OR USE THE BMC MODULES AND PROMPTLY RETURN THE BMC MODULES TO BMC. IF YOU
REJECT THIS AGREEMENT YOU WILL NOT ACQUIRE ANY LICENSE TO USE THE BMC MODULES.

SCOPE OF AGREEMENT. This Agreement is between the entity or individual entering into this Agreement (You) and
BMC Software, Inc. (BMC). This Agreement governs Your use of the BMC Modules, unless You agreed to a web-based
licenseagreement with BMC when ordering the BMC Modules, in which case that web-based license agreement governs
the use of the BMC Modules. As used herein, Complementary Product means any product of Yours that embeds or is
dependent for execution upon a BMC Module.

LICENSE. BMC grants You a non-exclusive, non-transferable, personal license (License) for one developer (the
Developer) (a) to copy and operate the BMC Modules for the sole purpose of designing, developing and testing
Complementary Products, provided that You acknowledge and agree that the right of embedding does not include a right
of distribution, and (b) to copy and operate Complementary Products (including any BMC Modules embedded therein)
solely for Your internal production purposes. You may not and agree not to: (i) copy the BMC Modules or the
Complementary Products except as expressly permitted in the immediately foregoing sentence, (ii) distribute, resell, rent
or lease the BMC Modules or the Complementary Products, (iii) use the BMC Modules for production purposes except as
expressly permitted with respect to embedded BMC Modules in the immediately foregoing sentence, (iv) disassemble or
reverse engineer any BMC Module, or decompile or otherwise attempt to derive any BMC Module source codefrom
executable code, except to the extent expressly permitted by applicable law despite this limitation, (v) release any
information to any third parties on the functionality or performance of the BMC Modules without BMC's prior written
consent, or (vi) provide a third party with the results of any functional evaluation, or benchmarking or performance tests,
without BMC's prior written approval. Additional usage restrictions may apply to certain third-party files or programs
embedded in a BMC Module applicable installation instructions or release notes may contain the relevant details.
Notwithstanding anything in this Agreement to the contrary, the licenses granted in this Agreement (A) do not grant You
the right to use any BMC Module (such rights, if any, are granted under a separate license), (B) do not extend to any
rights under any patents or patent applications under which BMC has any rights, and (C) do not extend to any use of the
BMC Modules in combination with any product, service or software other than the Complementary Product for which it
is registered and approved.

FEES. You agree to pay any shipping or handling fees associated with the BMC Modules. You is responsible for taxes, if
any.

TERMINATION. This Agreement terminates automatically if You breach any of its terms. Either party may terminate
this Agreement without cause on 30 days prior written notice. Upon termination, You must uninstall the BMC Modules,
and either certify their destruction or return them to BMC.

OWNERSHIP. BMC, or its affiliates or licensors, retains all right, title and interest in the BMC Modules and copies
thereof, and any intellectual property, informational, industrial property and proprietary rights therein. BMC neither
grants nor otherwise transfers any rights of ownership in the BMC Modules to You. The BMC Modules are protected by
applicable copyright, trade secret, patent and other intellectual and industrial property laws. As between You and BMC,
You retain all right, title and interest in any intellectual property, information, industrial property and proprietary rights
in the Complementary BMC Modules, excluding and subject to those contained in the BMC Modules.

CONFIDENTIAL AND PROPRIETARY INFORMATION. The BMC Modules contain valuable confidential information
and trade secrets of BMC. You may not use the BMC Modules other than as specifically allowed under the license granted
in this Agreement. You may not disclose the BMC Modules or any part thereof, to third parties, except that (i) You may
disclose the BMC Modules or parts thereof to Developer if Developer has obligations of confidentiality which are at least
as protective of BMCs confidential information and trade secrets as the provisions of this Agreement and if Developers
use of the BMC Modules is consistent with the terms of this Agreement, and (ii) if You use a Complementary Product
internally for production purposes, You may disclose the BMC Modules or parts thereof to its employees who are under
obligations of confidentiality at least as protective of BMCs confidential information and trade secrets as the provisions of
this Agreement, whose use of the BMC Modules is consistent with the terms of this Agreement, and who need to receive
such disclosure in order to install, operate, support or maintain the Complementary BMC Modules. You agree to use all
reasonable efforts to prevent the unauthorized use, copying, publication or dissemination of any BMC Module.

Page 39 of 40

WARRANTY DISCLAIMER. THE BMC MODULES ARE PROVIDED AS IS, WITH ALL FAULTS. BMC, ITS
AFFILIATES AND LICENSORS SPECIFICALLY DISCLAIM ALL WARRANTIES, INCLUDING WITHOUT

LIMITATION THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,
NON-INFRINGEMENT AND QUIET ENJOYMENT. BMC DOES NOT WARRANT THAT THE OPERATION OF
THE BMC MODULES OR THE COMPLEMENTARY PRODUCTS WILL BE UNINTERRUPTED, VIRUS OR ERROR
FREE, OR THAT THERE ARE NO DEFECTS.

LIMITS ON BMCS LIABILITY. IN NO EVENT WILL BMC, ITS AFFILIATES OR LICENSORS, BE LIABLE FOR
ANY SPECIAL, INDIRECT, INCIDENTAL, PUNITIVE OR CONSEQUENTIAL DAMAGES RELATING TO OR
ARISING OUT OF THIS AGREEMENT, THE BMC MODULES AND/OR ANY COMPLEMENTARY PRODUCT
(INCLUDING WITHOUT LIMITATION LOST PROFITS, LOST COMPUTER USAGE TIME, AND DAMAGE OR
LOSS OF USE OF DATA), EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, AND IRRESPECTIVE
OF ANY NEGLIGENCE OF BMC OR WHETHER SUCH DAMAGES RESULT FROM A CLAIM ARISING UNDER
TORT OR CONTRACT LAW. BMCS LIABILITY FOR DIRECT DAMAGES IS LIMITED TO THE GREATER OF (I)
THE AMOUNT PAID BY YOU FOR THE LICENSE TO THE BMC MODULE, IF ANY, AND (II) $1000.

VERIFICATION. If requested by BMC, You will deliver to BMC written certification relating to Your use of the BMC
Modules and/ or the Complementary Products in compliance with the terms of this Agreement. BMC may audit Your use
of the BMC Modules and/ or Complementary Products to confirm such compliance.

EXPORT CONTROLS. You will cooperate with BMC as reasonably necessary to ensure compliance with the laws and
regulations of the United States and all other relevant countries, relating to exports and re-exports (Export Laws). You
may not import, export, re-export or transfer, directly or indirectly, including via remote access, any part of the BMC
Modules, or any other BMC information or technology, in violation of any such laws and regulations, or without any
written governmental authorization required under applicable Export Laws. Neither the BMC Modules nor the
underlying information or technology may be downloaded or otherwise provided or made available, either directly or
indirectly, (i) into Cuba, Iran, Libya, Sudan or any other country subject to U.S. trade sanctions, to individuals or entities
controlled by such countries, or to nationals or residents of such countries other than nationals who are lawfully admitted
permanent residents of countries not subject to such sanctions; or (ii) to anyone on the U.S. Treasury Departments list of
Specially Designated Nationals and blocked persons or the U.S. Commerce Departments Table of Denial Orders. BY
OPENING THE PACKAGE, INSTALLING, PRESSING AGREE OR YES OR USING THE BMC MODULES, YOU
AGREE TO THE FOREGOING AND REPRESENT AND WARRANT THAT YOU ARE NOT LOCATED IN, UNDER
THE CONTOL OF, OR A NATIONAL OR RESIDENT OF ANY SUCH COUNTRY OR ON ANY SUCH LIST.

DISPUTE RESOLUTION AND GOVERNING LAW. ANY CONTROVERSY OR CLAIM ARISING OUT OF OR
RELATING TO THIS AGREEMENT, OR THE BREACH HEREOF, WILL BE SETTLED BY ARBITRATION
ADMINISTERED BY THE AMERICAN ARBITRATION ASSOCIATION UNDER ITS COMMERCIAL
ARBITRATION RULES IN HOUSTON, TEXAS IN ENGLISH. THE ARBITRATOR MUST FILE ALL FINDINGS
WITHIN 30 DAYS AFTER THE FINAL ARBITRATION HEARING. JUDGMENT ON ANY AWARD RENDERED BY
THE ARBITRATOR MAY BE ENTERED IN ANY COURT HAVING JURISDICTION THEREOF. NOTHING
CONTAINED IN THIS SECTION WILL LIMIT BMC'S ABILITY TO SEEK EQUITABLE RELIEF IN ANY COURT.
THE PARTIES WILL ARBITRATE DISPUTES IN CONFIDENCE. THIS AGREEMENT WILL BE GOVERNED THE
SUBSTANTIVE LAWS OF THE STATE OF TEXAS. CHOICE OF LAW RULES OF ANY JURISDICTION AND THE
UNITED NATIONS CONVENTION ON CONTRACTS FOR THE INTERNATIONAL SALE OF GOODS WILL NOT
APPLY.

U.S. GOVERNMENT RESTRICTED RIGHTS. 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
227.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.

Page 40 of 40

MISCELLANEOUS TERMS. This Agreement constitutes the entire agreement between You and BMC relating to the
matters covered hereby, and supersedes any prior or contemporaneous negotiations or agreements, whether oral or
written, concerning the BMC Modules and any related subject matter. This Agreement may be modified only in a
mutually signed, whether in writing or electronic, agreement between You and BMC. Neither Developer nor You may
assign this Agreement or any rights granted by this Agreement to a successor, except in the event of merger,
consolidation, or sale of all or substantially all of Your assets. Should any provision of this Agreement be invalid, or
unenforceable, the remainder of the provisions will remain in effect. The parties have agreed that this Agreement and the
documents related thereto be drawn up in the English language. Les parties exigent que la prsente convention ainsi que
les documents qui sy rattachent soient rdigs en anglais.

BY OPENING TTHE PACKAGE, INSTALLING, PRESSING AGREE OR YES OR USING THE BMC MODULES,
YOU ACKNOWLEDGE AND AGREE THAT YOUR AUTHORIZED REPRESENTATIVE HAS READ THIS
AGREEMENT AND THAT YOU INTEND TO BE BOUND HEREBY, AS IF YOUR AUTHORIZED
REPRESENTATIVE HAD SIGNED THIS AGREEMENT IN WRITING. THE INDIVIDUAL EXECUTING THIS
AGREEMENT WARRANTS THAT HE OR SHE HAS THE AUTHORITY TO ACCEPT THE TERMS OF THIS
AGREEMENT FOR YOU AND ON HIS OR HER OWN BEHALF.

v.02.05.04

The ABS's of Parameters and Thresholds PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

The ABS's of Parameters and Thresholds PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

Page 1 of 40

Susan E. Miller BMCS:CE

Anda mungkin juga menyukai