Note that the CLM 4.0.x rules are different from the CLM 5.0.x and above rules in structure. The CLM 5.0.x rules capabilities are easier to manipulate and are more robust and are the recommended rules type for CLM 5.0 and higher.
The rules behavior resides in the MBeans, and so the behavior is reliant of the CLM version, which is what has the CLM Server Monitoring Plugin installed.

This is not dependent on CLM Server Monitoring Agent version, as CLM Server Monitoring Agent 5.0.1 and above have support for both rules types.
Using CLM Server Monitoring 4.0.6 rules in CLM Server Monitoring 5.0.0 will revert CLM Server Monitoring Plugin to CLM Server Monitoring 4.0.6 behavior, and is not recommended.

The example CLM Server Monitoring rules recommendations and examples are currently under development.

CLM Server Monitoring rules 5.0 and higher

The issue rules are defined in an XML document and sent to the server to install into the rules engine.
This provides the engine a way to evaluate resources as they are executing.
A rule is comprised of the target resource information (type and name) followed by 1..n number of action elements.

The rule set will be installed and replace the current one is it exists. The persist parameter is used to write to the issueRules.xml file

listRules

String

List of rules running in server

CLM 5.0 and higher example rulesets for jazz Applications

Attached to this page are example rule sets for specific CLM applications, created in CLM 5.0.
These are provided in order to give realistic examples of what a finished ruleset might look like for each of these CLM applications.

Represented are Jazz Team Server, Rational Team Concert (CCM ), Rational Quality Manager (QM), and Rational DOORS Next Generation (RM).
Each of the application rule sets are different, and may list specific services that that are unique to the specific application.

Notices for example rules

These rules were created for the CLM team internal systems, and are likely not applicable to your specific system.
These are provided only as an example of a larger rule set against the supported applications in CLM 5.0.1.

Running these rules may adversely affect your system and are not recommended. Do not use these rules on production, or any other stage other than experimentation.

These rules do contain javacore actions that may disrupt your system. It is possible with the rules to be put into a state where the CLM host stops responding due to an overwhelming abundance of javacore requests.

Rule example - build request monitoring in RTC

One instance of many where the examples might diverge from your system is the specific RTC application rules.
Example of BuildRequestLookupService BuildAgentLoopTask activity monitoring in RTC XML

Whereas we are using Rational Build Forge for our example, you may be using a different Build infrastructure.
Note that this specific rule takes action to create problem record if two tests pass on evaluating a service identified by resource name; the first a duration longer than 20 seconds and the second that the activity (identified through the activity name) be a specific Task. The rule also says to create a javacore if the Task activity takes longer than 100 seconds.