the abs's of parameters and thresholds.pdf

of 40 Susan E. Miller BMCS:CE

The ABCs of Parameters and Thresholds

Author

Susan E. Miller BMCS:CE BMC Software Business School

August 25, 2004


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 logos, 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 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.

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


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 [email protected]

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.


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


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


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__ = / 3. Application Instance = //APP_INSTANCE 4. Parameters = //APP_INSTANCE/PARAMETER


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 active flag. The name of 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.


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 style of 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.


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


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.


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.


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.


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);


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.


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.


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.


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


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]


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


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)


{ 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);


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); } }


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.


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


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


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


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


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 0 Trigger when 0 means immediately on


would be the number of times before 1 State - WARN 1 Alarm 2 setting is active 300 Begin value 500 End Value 0 Trigger when 0 means immediately on


would be the number of times before 2 State - ALARM


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.


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


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 allowexternaloverride must 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 Time that 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.


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");


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.


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.


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

EXECUTE RECOVERY A1R2 1:40 30 CHANGE STATE TO OK 1:50 61 CHANGE STATE A1 WARN

EXECUTE RECOVERY A1R1 2:00 65 STATE REMAINS WARN FOR A1

EXECUTE RECOVERY A1R2 2:10 76 CHANGE STATE TO A2 ALARM

EXECUTE RECOVERY A2R1 2:20 79 STATE REMAINS ALARM

EXECUTE RECOVERY A2R2 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.


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 (if, 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


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.


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 license agreement 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 code from 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.


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.


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

Documents