Advanced Search
Home › Technical Documents › Tips › Tivoli › Enterprise Console › Multiple Inheritance in BAROC

Multiple Inheritance in BAROC

A little used feature of BAROC classes is multiple inheritance, which is the facility for a class to have two or more parent classes. For example, in the tecad_logfile.baroc file in the Default rule base we can see:

Open in New Window
TEC_CLASS :
    NFS_No_Response ISA [ Logfile_Kernel, Server_No_Response ]
    DEFINES {
        hostname: dup_detect = yes;
        severity: default = WARNING;
    };
END?>

This definition states that the NFS_No_Response class inherits from both the Logfile_Kernel and Server_No_Response classes. This behavior has advantages both in terms of the content of the class itself and when it comes to writing rules.

This tip will cover some of these advantages and also introduce a utility to aid in the creation and use of more complex classes such as these.

Class Contents

In the example above the NFS_No_Response class will contain all the slots from both the Logfile_Kernel and Server_No_Response classes. An immediately obvious use of this to reduce the size of a BAROC file while increasing its readability and manageability; a set of often repeated facets can be stored in a class which other classes can inherit from; rather than being repeated in a number of classes throughout the BAROC file.

The first question is what happens when a facet is included in both parent classes? The answer is that the classes earlier in the list take priority over the later ones. In this case Logfile_Kernel will take priority over Server_No_Response. Any facets redefined in the DEFINES statement will still take priority over all of the parent classes.

We can demonstrate this fairly easily by sending a "default" NFS_No_Response event using:

wpostemsg NFS_No_Repsonse LOGFILE

and then viewing it in the console.

If we look at severity we can see that for Syslogd_Nospace the default is MINOR as set out in the DEFINES statement, even though it is WARNING for Logfile_Kernel (inherited from Logfile_Base) and CRITICAL for Server_No_Response.

If we now take a copy of the Default rule base, delete the redefinition of severity for NFS_No_Response, compile and load the new rule base, and then resend the default event we can see that the default value for severity is now WARNING, inherited from Logfile_Kernel.

Rule Writing

One advantage of defining multiple parents when it comes to rule writing is that it possible to write a single rule that applies diverse set of events that does not need to be modified when new classes are defined.

For example - again working with tecad_logfile.baroc in the Default rulebase - if we wanted to write a rule that performed a certain action when an event arrived that indicated that a server might be down we could do either:

Open in New Window
rule: host_not_responding:
(
  description: 'Ping unresponsive host',
  event: _event of_class within
      ['NIS_No_Response','NFS_No_Response']
    where [
      hostname: _hostname
    ],
  action: ping_host: (
    exec_program(
      _event,
      'scripts/ping_host.pl',
      '%s',
      [ _hostname ],
      'YES'
    )
  )
).?>

or

Open in New Window
rule: host_not_responding:
(
  description: 'Ping unresponsive host',
  event: _event of_class 'Server_No_Response'
    where [
      hostname: _hostname
    ],
  action: ping_host: (
    exec_program(
      _event,
      'scripts/ping_host.pl',
      '%s',
      [ _hostname ],
      'YES'
    )
  )
).?>

The first advantage of the second rule is that it is more readable; in this example the list of classes in the first rule is quite short, but as this increases the rule will become progressively more unwieldy and its purpose will become less apparent.

More importantly though, we can make the second rule apply to new classes simply by defining them as a subclass of Server_No_Response (and some other class or classes) in our BAROC file: we no longer need to change the rule whenever we create a new class which we want this rule to fire against.

owlsrbclass.pl

The owlsrbclass.pl script is an enhanced version of the standard "wlsrbclass -d" command. The script provides more information about both the inheritance of the selected class and the facets of the class.

The syntax of the command is as follows:

owlsrbclass.pl

where and are the rule base being queried and the required class respectively.

An example output showing NFS_No_Response from the Default rule base is shown below.

 

Open in New Window
           Class: NFS_No_Response
            File: tecad_logfile.baroc
Parent Class(es): Server_No_Response, Logfile_Kernel
 Child Class(es):

Slot                 Type            Source Class         Facet      Value
==================== =============== ==================== ========== ==========
acl                  LIST_OF STRING  EVENT                default    [admin]
                                                          parse      no
adapter_host         STRING          Logfile_Base         default    "N/A"
administrator        STRING          EVENT                parse      no
cause_date_reception INT32           EVENT                parse      no
cause_event_handle   INTEGER         EVENT                parse      no
credibility          INTEGER         EVENT                default    1
                                                          parse      no
date                 STRING          EVENT
date_reception       INT32           EVENT                parse      no
duration             INTEGER         EVENT                parse      no
event_handle         INTEGER         EVENT                parse      no
hostname             STRING          NFS_No_Response      dup_detect yes
msg                  STRING          EVENT
msg_catalog          STRING          Logfile_Base         default    "none"
msg_index            INTEGER         Logfile_Base         default    0
num_actions          INTEGER         EVENT                parse      no
origin               STRING          EVENT
pid                  STRING          Logfile_Base         default    "N/A"
repeat_count         INTEGER         Logfile_Base         default    0
server               STRING          Server_No_Response   dup_detect yes
server_handle        INTEGER         EVENT                parse      no
severity             SEVERITY        NFS_No_Response      default    WARNING
source               STRING          Logfile_Base         default    "LOGFILE"
status               STATUS          EVENT                default    OPEN
sub_origin           STRING          Logfile_Base         default    "N/A"
sub_source           STRING          Logfile_Base         default    "LOGFILE"?>

A limitation of the script is that it must be run on the Managed Node where the rule base resides.