Patterns in HP  operations manager

Note: HP renamed the product called now HP operations manager way too many times. Also it is very inconsistent with using abbreviations. Here we will assume that the term "HP Operations manager" and abbreviations HPOM, OMU, and OVO  mean the same thing :-)

HPOM tries to reinvent the cycled reinventing regular expression of "patterns" and as always in such cases the result are horrible. They provide a tiny subset of Perl regular expression that is difficult to learn, difficult to use and that is providing limited opportunities for matching text patterns.

They call them proprietary pseudo-regex language "patterns" with their own proprietary syntax and semantic of key elements is far from being slick or interesting other that that it in pervert way reflects thinking patterns (or lack thereof) of HPOM architects. It's pretty sick implementation,  if you ask me :-).

One unique feature of HPOM is that regex simultaneously can contain the name of the local variable to which the value of regex will be assigned. For example, pattern 

<#.threshold>  

in Perl can be programmed something like

$MSG_TEXT =~ /(\d+)/; 
$threshold = $1; 

After that you can use a user defined variable somewhere else in condition (they are local to the condition).

Pattern can be more complex/perverted. For example:

<<#.uid> -eq 0> 

• Interactive - The command is executed from the command line and will prompt first for input string and the for pattern. After that it will report results including cvalue of any local variables that were set by the pattern.
• Batch - The command is provided with arguments that define file with data and file with pattern. To use files with the opcpat command, you need two files -- data file and pattern file. For example:

  opcpat -fp /tmp/test_pat -fv /tmp/test_dat

  It reads from each file one lines at a time. The line from he file defined by parameter -fp is used as input string, the line from the file defined by the parameter -fv is used as a pattern.

HPOM regex use several special characters:

•  <    >   -- Delimit the regex. For example:
  •  <*>  --  Matches zero or more alpha or numeric characters
  •  <#> --  Matches one or more numeric character. Like \d+ in Perl.
  • <@>  --  Matches one or more alpha or numeric characters up to a separator. Like regex \w+ in Perl
  •  < _> ( underscore) Matches once or more separator characters
• |  -- Or operator
• [        ]  -- Defines a group, typically as one of several alternatives separated by "|". Plea note that in Perl  "(" and ")" delimit groups, while "[" and "]" reserved for character classes.
•  ^ ( caret) --  Start of Line. If the caret (^) is used as the first character of the pattern, only expressions found at the beginning of lines are matched.
• $ --If the dollar sign ($) is used as the last character of a pattern, only expressions at the end of lines are matched. For example, the p~ttern des matches de in the line abode, but not in the line ab~dex.
• \  --  Escape character
• !  --  Not operator. Negated result of matching, so that success became failure and vice versa.

The key elements of HPOM pattern language as following (by default matching is case sensitive: 

• <*> String
• <n*> String of length N
• <#> Number
• <n#> Number of Length N
• <_> Matches a separator. Separators are space and tab by default, but can be redefined
• <n_> A String of N field separators
• <@> Word. Matches anything between two separators (space or tab). Separators should exist on both ends. Similar to /(\S+)/ in Perl. In version 9 The separator may also be matched using  <S>.
• | Or Operator
• <![]> Not Operator. The NOT operator ("!"  -- exclamation mark) must be used with delimiting square brackets, for example: < ! [WARNTNG] >
• [] Bracket Group
• <[].var> Assignment to var
• <<#> -ge n>
• <<#> -lt n> Less Then
• <<#> -le n> Less Or Equal
• <<#> -gt n> Greater Then

  HPOM patterns or regex allow the setting of variables within the pattern. The variable is specified after dot. For example:

 <*.vat> or <#.vat> or <@.var>

Case sensitivity and separators normally defined as part of a condition and can be changes if the need arise to have a different definitely then default. The default for each of these elements is:

• Case Sensitivity - On
• Separators - Space or Tab
• Separator characters are configurable for each condition. By default, separators are the space and the tab characters.
• Square Bracket Expressions The square brackets ([]) are used as delimiters to group expressions. To increase performance, square brackets should be avoided wherever they are superfluous. In the following pattern, all square brackets are unnecessary, the string abcdefgh is equivalent: ab[cd[ef]gh] Bracketed expressions are used frequently with the OR operator, the NOT operator, and when using sub-patterns to assign strings to variables.
• OR (|) Operator Two expressions separated by the special character vertical bar (|) matches a string that is matched by either expression. Implementing Message Policies Filtering Messages with Conditions 344 Chapter 4 For example, the following pattern matches the string abd and the string cd.: [ab|c]d
• NOT (!) Operator The NOT operator (!) must be used with delimiting square brackets. For example, the following pattern matches all text which does not contain the string “WARNING”: <![WARNING]>

  The NOT operator may also be used with complex sub-patterns:

   SU <*> + <@.tty> <![root|[user[1|2]]].from>-<*.to> 

  This pattern makes it possible to generate a switch user message for anyone who is not user1, user2, or root.

  Therefore, the following string would be matched:

  SU 03/25 08:14 + ttyp2 user11-root</pre>
  However, the following line would not be matched because it contains
  an entry concerning user2:
  

  SU 09/25 08:14 + ttyp2 user2-root</pre>
  

  If the sub-pattern including the not operator does not find a match, the not operator behaves like a <*>. It matches zero or more arbitrary characters. For this reason, there is a difference between the UNIX [!123] expression, and the corresponding HPOM pattern-matching expression <![1|2|3]>. The HPOM expression matches any character or any number of characters, except 1, 2, or 3. The UNIX operator matches any one character, except 1, 2, or 3.
• Mask (\) Operator The backslash (\) is used to mask the special function of the following characters: [ ] < > | ^ $

  A special character preceded by a backslash (\) results in an expression that matches the special character itself. Because a caret (ˆ) and a dollar sign ($) have a special meaning only when placed at the beginning and end of a pattern, you do not need to mask them when they are used within the pattern (that is, not at beginning or end of the pattern). The only exception to this rule is the tab character, which is specified by entering \t into the pattern string. The OR operator (|) can be used in the following fields of the match condition:

  • Node
  • Application
  • Message group
  • Object

Numeric Range Operators

The basic pattern for constructing complex expressions with these operators, is: <number--operator--[sub-pattern]--operator--number> The sub-pattern can be a simple numeric operator, for instance <#> or <2#>. Such a simple operator does not require delimiting brackets. Alternatively, it may be a complex sub-pattern, using delimiting brackets: <120 -gt [<#>1] -gt 20> It is also possible to construct a pattern by using only one operator: Error <<#> -eq 1004>

The 6 Numeric Range Operators:

• -le Less than or equal to
• -lt Less than
• -ge Greater than or equal to
• -gt Greater than
• -eq Equal to
• -ne Not equal to

Less Than or Equal To (-le) Operator

Example of use: <<#> -le 45> This pattern matches all messages containing a number that is less than or equal to 45. For example, the following message would be matched:

ATTENTION: Error 40 has occurred

Note that the number 45 in the pattern is a true numeric value and not a string. Numbers higher than 45, for instance, 4545 will not be matched even if they contain the combination, 45. Less Than (-lt) Operator

Example of use: <15 -lt <2#> -le 87>

This pattern matches any message in which the first two digits of a number are within the range 16-87. For instance, the message: Error Message 3299 would be matched.

The string: Error Message 9932 would not be matched. Greater Than or Equal To (-ge) Operator

Example of use: ^ERROR_<57 -ge <#.err>>

This pattern matches any text starting with the ERROR_ string immediately followed by a number less than or equal to 57. For example, the following message would be matched:

ERROR_34: processing stopped

The string 34 would be assigned to the variable, err.

Note the use of the caret (^) expression anchor.

Greater Than (-gt) Operator

Example of use:

<120 -gt [<#>1] -gt 20>

Matches all numbers between 21 and 119 that have 1 as their last digit. For instance, messages containing the following numbers would be matched: 21, 31, 41...101... 111, and so on.

Second example: Temperature <*> <@.plant>: <<#> -gt 100> F$

This pattern matches strings such as: ``Actual Temperature in Building A: 128 F''. The letter A would be assigned to the variable, plant. Note the use of the $ expression anchor. A “greater than” operator is also referred to as an Open Interval. Using “greater than equal to” operators creates a

Closed Interval.

Equal To (-eq) Operator

Example of use:

Error <<#> -eq 1004>

This pattern matches any message containing the string Error followed by the sequence of digits, 1004. For example, the following message would be matched by this pattern:

Warning: Error 1004 has occurred

However, Error 10041 would not be matched by this pattern.

Not Equal To (-ne) Operator

Example of use:

WARNING <<#> -ne 107>

This pattern matches any message containing the string WARNING followed by a blank and any sequence of one or more digits, except 107. For example, the following message would be matched: Application Enterprise (94/12/45 14:03): WARNING 3877

To Insert Expression Symbols in Pattern-matching Expressions

Any time you work with pattern matching, you can use the left and right mouse buttons to insert expression symbols.

To insert expression symbols, follow these steps:

1. Select the text you want to replace with an expression.
2. Right-click the selected text for a list of replacement symbol choices.
3. Select the symbol from the list.

Variables and Parameters of Pattern-matching Expressions

Any matched string can be assigned to a variable, which can then be used to recompose messages or be used as a parameter for action calls. To define a parameter, add .parametername before the closing bracket. The ^errno: <#.number> - <*.error_text> pattern matches a message such as the following:

errno: 125 - device does not exist and assigns 125 to number and device does not exist to error_text. Variable names may only contain alphanumeric characters as well as underscores (_) and hyphens (-). The following syntax rules apply:

(Letter | '_'){ Letter | Digit | '_' | '-' }

In the syntax above, Letter allows letters and ideographic characters from all alphabets, and Digit allows digit characters from all alphabets. Rules Used by HPOM to Assign Strings to Variables In matching the pattern <*.var1><*.var2> against the string abcdef, it is not immediately clear which substring of the input string will be assigned to each variable. For example, it is possible to assign an empty string to var1 and the whole input string to var2, as well as assigning a to var1 and bcdef to var2, and so on.

The pattern-matching algorithm always scans both the input line and the pattern definition (including alternative expressions) from left to right. Expressions such as <*> are assigned as few characters as possible. In contrast, expressions such as <#>, <@>, and <_> are assigned as many characters as possible. The variable will therefore be assigned an empty string in the above example. For example, to match the this is error 100: big bug input string, use the following pattern: error<#.errnumber>:<*.errtext>

In this example:

• 100 is assigned to errnumber.
• big bug is assigned to errtext.

Matching <@.word><#.num> against abc123 assigns abc12 to word and 3 to num, as digits are permitted for both <#> and <@>, and the left expression takes as many characters as possible.

Patterns without expression anchoring can match any substring within the input line. For example, the this is number<#.num> pattern is treated in the same way as the following: <*>this is number<#.num><*>

Using Sub-patterns to Assign Strings to Variables

In addition to being able to use a single operator, such as a star (*) or a number sign (#), to assign a string to a variable, you can also build up a complex sub-pattern composed of a number of operators, according to the following pattern: <[sub-pattern].var>.

For example: <[<@>file.tmp].fname>

Note that in the example above, the period (.) between file and tmp matches a similar dot character, while the dot between “]” and “fname” is necessary syntax. This pattern would match a string such as Logfile.tmp and assigns the complete string to fname.

Other examples of sub-patterns are:

<[Error|Warning].sev>

<[Error[<#.n><*.msg>]].complete>

In the first example above, any line with either the word Error or the word Warning is assigned to the variable, sev. In the second example, any line containing the word Error has the error number assigned to the variable, n, and any further text assigned to msg. Finally, both number and text are assigned to complete.

In most cases, pattern matching involves simply scanning for a specific string in a message. However, some mathematical operators are available to enhance the precision of the search. For example, if you type ERROR along with the TEXT keyword in MSGCONDITIONS block of the policy body, only message text containing the string “ERROR” (in any position) is matched.

Similarly, if you want to match text that does not contain a specific string (for example, “WARNING”), you might enter the following: <![WARNING]>

In this example, you use the not operator (!), together with the angle brackets that must enclose all operators, and the square brackets that isolate sub-patterns. Because messages that match a suppress condition are excluded from HPOM, you do not need to reformat messages or specify actions for matching messages.

If you used the ICASE keyword in your policy body, any combination of uppercase and lowercase characters composing the word, “warning”, can be matched. Here are a few examples of the many conditions you can use in the HPOM pattern-matching language:

• Error Recognizes any message containing the keyword Error at any place in the message. This condition is case-sensitive by default.
• panic When case-sensitive mode is not set, this condition matches all messages containing panic, Panic, or PANIC.
• logon|logoff Uses the OR operator (|) to recognize any message containing the keyword logon or logoff.
• ^getty:<*.msg> errno<*><#.errnum>$ Matches messages such as: getty: cannot open ttyxx errno : 6 getty: can’t open ttyop3; errno 16 In the first example, the cannot open ttyxx string is assigned to the msg variable. The digit 6 is assigned to the errnum variable. The anchoring symbol is used to specify that the digit 6 will be matched only if it is at the end of the line.
• ^errno[|=]<#.errnum> <*.errtext> Matches messages such as: <br>errno 6 - no such device or address <br>errno=12 not enough core.

  The blank space before the OR operator is critical. The expression in square brackets matches either this blank space or the equal sign (=). The blank space between <#.errnum> and <*.errtext> is used as a delimiter. Although not strictly required for assignments to the variables shown here, this blank space helps improve performance.

• ^hugo:<*>:<*.uid>: Matches any /etc/passwd entry for user hugo and returns the user id to variable uid. The colon (:) in the middle of the pattern is used to delimit the string passed to uid from the preceding string. The colon at the end of the pattern is used to delimit the string passed to uid from the succeeding group ID in the input pattern. The colon is necessary not only to enhance performance, but also as a logical string separator.
• ^Warning:<*.text>on node<@.node>$ Matches any message, such as Warning: too many users on node hpbbx, and assigns too many users to the variable text and hpbbx to the variable node. Details of Pattern-Matching Expressions Here are details about the expressions you can use in the HPOM pattern-matching language:
• Standard Characters Ordinary characters are expressions that represent themselves. Any character of the supported character set may be used. However, if any of the following special characters are used, they must be prefaced with a backslash (\), which masks their usual function: [ ] < > | ^ $

  If a caret (ˆ) and a dollar sign ($) are not used as anchoring characters (that is, not as first or last characters), they are considered standard characters and, as a consequence, do not need to be masked.

• Expression Anchoring Characters (ˆ and $) If a caret (ˆ) is used as the first character of the pattern, only expressions discovered at the beginning of lines are matched. For example, ^ab matches the string ab in the line abcde, but not in the line xabcde.

  If the dollar sign ($) is used as the last character of a pattern, only expressions at the end of lines are matched. For example, de$ matches de in the line abcde, but not in the line abcdex.

• Expressions Matching Multiple Characters Patterns used to match strings consist of an arbitrary number of special characters with semantic similar to regular expressions: 
  • <*> Matches any string of zero or more arbitrary characters (including separators).
  • <n*> Matches a string of n arbitrary characters (including separators).
  • <#> Matches a sequence of one or more digits.
  • <n#> Matches a number composed of n digits.
  • <_> Matches a sequence of one or more separator characters.
  • <n_> Matches a string of n separators.
  • <@> Matches any string that contains no separator characters. In other words, it matches a sequence of one or more non-separators. This pattern can be used for matching words.

NEWS CONTENTS

• 200102 : HP OpenView VantagePoint Operations for Sun Solaris Software ... ( HP OpenView VantagePoint Operations for Sun Solaris Software ..., )
• 200102 : OML9.01_Linux_AdminRef.pdf ( OML9.01_Linux_AdminRef.pdf, )

Old News

HP OpenView VantagePoint Operations for Sun Solaris Software ...

Pattern-matching Expressions <S> and <nS>

The pattern-matching expressions <S> and <nS> have been replaced with the new expressions <_> and <n_>. <_> matches a sequence of one or more separator characters.

<n_> matches a string of n separators. For compatibility reasons, the expressions <S> and <nS> still work in VPO version A.07.00 but may be obsoleted with future releases.

Operations Manager Administrator's Reference OML9.01_Linux_AdminRef.pdf

NODEPATTERN Pattern matching can be used to match nodes.

Note that pattern-matching is case insensitive. Two match types are possible:

• IPPATTERN:

Pattern matching using IP address of a node.

Example: NODEPATTERN IPPATTERN

"10.1.<*>".

• NAMEPATTERN:

Pattern matching using the node name.

Example: NODEPATTERN NAMEPATTERN "testnode.<*>".

APPLICATION Application name.

MSGGRP Message group name. OBJECT Object name. MSGTYPE Description of the message type.

MSGCONDTYPE Message condition type: • Match: Condition is true if the specified attributes are matched. • Suppress: Condition is true if the specified attributes are not matched. TEXT A string containing all or part of the message text. Pattern-matching may be used. Example: TEXT "^Path: /[dir1|dir2]<_>[dir3|dir4]" SEPARATORS "/"

SERVICE_NAME

A string containing the unique identifier of the service. Pattern-matching may be used. Example: SERVICE_NAME "Service<*> [A|B]" ICASE

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019