The Knowledge Base employs a defined directory structure to organize files and executables. Each subdirectory under the main kb directory is named for the type of files or executables it stores. When you install or create a cell, the default files define and create an empty Knowledge Base and directory structure. The default files are updated each time you create or modify rules or collectors. You can change these files with a text editor. Executables you create for the Knowledge Base must be in the correct subdirectory, as defined by the cell, or they will not execute. The host system you use determines where the executables reside.
The Knowledge Base directories exist in two locations:
• The default Knowledge Base exists in MCELL_HOME\etc\kb on Windows platforms and in MCELL_HOME/etc/kb on Unix
platforms. The installation process copies this directory into each cell created. This Knowledge Base is the default Knowledge Base in newly created cells.
• The cell’s working Knowledge Base is located in
MCELL_HOME\etc\<CellName>\kb (Windows) or
MCELL_HOME/etc/<CellName>/kb (Unix). The cell references this is the Knowledge Base during run time.
The manifest.kb file points to directories for class events, interfaces, records, rules, libraries, and actions and its location is
The default content of the manifest.kb file is: bin = bin classes = classes collectors = collectors data = data lib = lib rules = rules records = records Note
The manifest.kb file is used by the Knowledge Base compiler but not by the cell. It allows some flexibility when writing and testing Knowledge Bases.
The Knowledge Base directory (kb) has the following structure:
kb bin
A (Independent) h0 (HP10+)
l2 (Linux Red Hat 7.0 and 7.1) p4 (AIX 4.3) s5 (Solaris 2.5+) w4 (Windows NT 4.0+) classes collectors data lib records rules manifest.kb (file)
The bin Directory
The bin directory contains scripts and programs that execute during rule processing. The executables are in subdirectories specific to the host architecture. There is one default file, .load, in the bin directory. The .load
file specifies in what order scripts and programs should be presented to clients.
These three primitives in the bin directory execute programs.
• execute runs an executable on the cell. The executable is located in the <arch> subdirectory.
• get_external runs an executable on the cell and passes
information back to the cell by means of an interface. The executable is located in the <arch> subdirectory.
• confirm_external runs an executable on the cell and returns a boolean value. The executable is located in the <arch> subdirectory.
The classes Directory
The default installation of the cell contains a Knowledge Base with a single base, or root, EVENT class definition. You may extend this base class definition by adding additional slots for custom or localized information.
An example of the EVENT class definition is the following.
MC_EV_CLASS :
MY_EVENT ISA EVENT DEFINES {
source: default = MY_APPLICATION; my_slot: STRING,
default = ’Version 3.2.00’, parse = no;
}; END
The collectors Directory
Collectors enable you to view events in an organized manner with the console. The collectors directory contains definitions of the collectors in
.mrl files. The .load file indicates the order in which these files are loaded into the cell. You can define collectors hierarchically, which allows the console to display information that is easier to read. You also can specify the category of user who can view and act on the events in any collector.
Here is an example of a top level, or supercollector, template:
collector <CollectorName> :
{r[<Roles>]; w[<Roles>]; x[<Roles>]} END
User access to collectors is defined in the collectors.mrl file and any other
.mrl file in the collector directory, as long as the collector file name is added to the .load file without the .mrl extension. In the collectors.mrl file you define access to collectors by assigning user roles and privileges to each collector. Privileges consist of read, write, and execute.
User roles and the assignment of user roles are defined in the BMC Impact Explorer Server. See the BMC Impact Manager Administrator Guide for information on defining user roles and assigning roles to users.
The data Directory
The data directory contains instances of the base, or root, DATA class in
.baroc files. The .load file indicates the order in which the files are loaded into the cell. A data class has the same definition as an event class. Chapter 2, “The BAROC Language,” and Chapter 4, “The Master Rule Language,” contain a detailed discussion of data classes.
The lib Directory
In prior releases the lib directory contained the declaration and implementation of primitives the rules use. These declarations and implementations are now contained within the cell for the Knowledge Base rules to use. Appendix A, “Master Rule Language Reference,” for details on primitives and their usage.
The records Directory
A global record stores persistent dynamic information in .baroc files. Many rule processing phases use global records to retrieve the
information from the global record files. The .load file indicates the order in which the files are loaded into the cell.
The following is an example global record. RECORD test_rec DEFINES { slot_str: STRING ; slot_int: INTEGER ;
slot_list_int: LIST_OF INTEGER ; default = [1, 2, 3] ;
} END
The rules Directory
The rules directory contains the rules definitions. The source for rules definitions are the files with an .mrl extension. The compiled versions of rules are contained in files with the .wic or .pkg extension. The .load file indicates the order in which the rules are loaded into the cell.
2
The BAROC Language
2
This chapter describes the fundamentals of the BAROC language. The following topics are discussed:
• Basic Concepts • Inheritance
• BAROC Syntax Generalities • Class Definitions
• Class Instances • Enumerations • Global Records • Product Internals