This chapter is intended to give an introduction to ODM, its terminology and an example of an ODM database. At the end of this chapter you can find a list of all ODM configuration files and descriptions of these files.
In the UNIX** environment, device configuration data and system management data traditionally have been stored in flat ASCII files or stanzas. Device configurations in such environments have also been static. System administrators either created or were provided with a configuration file (or a group of files) defining a set of installed device drivers. Advantages and disadvantages arise from this implementation. ODM database stores and maintains system data as objects with associated characteristics.
ODM has many purposes. Its primary functions are to maintain the RISC System/6000* configuration, associated devices, and the vital product database. In addition, it provides a more robust, secure, and sharable resource than the ASCII files.
ODM provides a reliable, object-oriented database facility for system management. This facility includes commands, C language subroutines, and an editor to create and manipulate device and system configuration data in a centralized database.
An object class is a file of the ODM database files that contains objects or group of objects with the same definition. An object class is conceptually similar to an array of structures, each object being a structure that is an element of the array.
An object, that is a member of a defined object class, is an entity that requires storage and management of data. It is an element defined by parameters called descriptors. You can see here an example of an object class and one of its descriptors:
class CuVPD {An object class is made up of one or more descriptors. Values are associated with the descriptors of an object when the object is added to an object class. The descriptors of an object and their associated values can be searched on and changed with ODM facilities.
char name[16];
short vpd_type;
longchar vpd[512];
};
CuVPD ---> Objet Class
vpd_type ---> descriptor
You can find a summary of this terminology in Figure 2.
Figure: Summary of ODM Object Class Definitions
You use the descriptors of an object and their associated values to define criteria for retrieving individual objects from an object class.
Most descriptors can be used in an object class as the search criteria:
# odmget -q "vpd_type=0" CuVPDODM supports several descriptor types such as:
CuVPD:
name = "hdisk2"
vpd_type = 0
vpd = "*Z00000*MFIBM *SN00521991*Z70899624 "
Terminal descriptors define the most primitive data types used by ODM. A terminal descriptor is basically a variable defined with an ODM terminal descriptor type. The terminal descriptor types provided by ODM are:
The ODM link descriptor is used to establish a relationship between an object in an object class and an object in another object class. A link descriptor is basically a variable defined with the ODM link descriptor type.
The ODM method descriptor allows the definition of an object class with objects that can have associated methods or operations. A method descriptor is basically a variable defined with the ODM method descriptor type.
The operation or method descriptor value for an object is a character string. The string can be any command, program, or shell script to be run by method invocation. A different method or operation can be defined for each object in an object class. The operations themselves are not part of ODM; they are defined and coded by the application programmer.
The method for an object is invoked by a call to the odm_run_method subroutine. The invocation of a method is a synchronous event, causing ODM operation to pause until the operation is completed.
This example discusses the components of ODM.
You can create an ODM database by creating a directory, such as my_odm_db, under your home directory.
# mkdir $HOME/my_odm_db
To use this directory as an ODM database, reset the shell variable ODMDIR to equal this directory.
# ODMDIR=$HOME/my_odm_db
# export ODMDIR
The ODMDIR shell variable is set automatically to the /etc/objrepos directory for every user in the /etc/environment file. Setting the ODMDIR variable to this new directory causes ODM to use that database instead of the system default.
To understand the concept of object classes and objects, you can create object classes following this method:
Note: Don't use a blank before the word class.
class Friend_Table {
char Friend_of[20];
char Friend[20];
};
class Enemy_Table {
char Enemy_of[20];
char Enemy[20];
};
class Fictional_Characters {
char Story_Star[20];
char Birthday[20];
short Age;
link Friend_Table Friend_Table Friend_of Friends_of;
link Enemy_Table Enemy_Table Enemy_of Enemies_of;
method Do_This;
};
The command odmcreate produces the .c and .h (include) files necessary for ODM application development and creates empty object classes.
# odmcreate Fictional_Characters.cre
With this command you create three object classes at the same time
The Fictional_Characters object uses two links descriptor, the first one to make the Friends_of descriptor link to the Friend_Table object class and a second one to maker the Enemies_of descriptor link to the Enemy_Table object class. To resolve the link, the Friends_of (or the Enemies_of) retrieves objects in the Friend_Table (Enemy_Table) object class with matching data in its Friend_of (Enemy_of) descriptors. The link descriptor in the Fictional_Characters object class defines the class being linked to Friend_Table (Enemy_Table), the descriptor being linked to Friend_of (Enemy_of), and the name of the link descriptor Friends_of (Enemies_of).
The Fictional_Characters object class has a method descriptor. With the method descriptor you can define an object class which can have active states. Active means that if a method descriptor has been defined to an object class, it is possible to cause operations to occur for each object in the class.
Fictional_Characters:
Story_Star = "Cinderella"
Birthday = "Once upon a time"
Age = 19
Friends_of = "Cinderella"
Enemies_of = "Cinderella"
Do_This = "echo Cinderella"
Fictional_Characters:
Story_Star = "Snow White"
Birthday = "Once upon a time"
Age = 18
Friends_of = "Snow White"
Enemies_of = "Snow White"
Do_This = "echo Snow White"
Fictional_Characters:
Story_Star = "Luke Skywalker"
Birthday = "A Long Time Ago"
Age = 20
Friends_of = "Luke Skywalker"
Enemies_of = "Luke Skywalker"
Do_This = "echo Luke Skywalker"
Friend_Table:
Friend_of = "Cinderella"
Friend = "Fairy Godmother"
Friend_Table:
Friend_of = "Cinderella"
Friend = "mice"
Friend_Table:
Friend_of = "Snow White"
Friend = "Sneezy"
Friend_Table:
Friend_of = "Snow White"
Friend = "Sleepy"
Friend_Table:
Friend_of = "Cinderella"
Friend = "Prince"
Friend_Table:
Friend_of = "Snow White"
Friend = "Happy"
Enemy_Table:
Enemy_of = "Cinderella"
Enemy = "Wicked Sisters"
Enemy_Table:
Enemy_of = "Cinderella"
Enemy = "Mean Stepmother"
Enemy_Table:
Enemy_of = "Cinderella"
Enemy = "Midnight"
Enemy_Table:
Enemy_of = "Snow White"
Enemy = "Sam"
Enemy_Table:
Enemy_of = "Luke Skywalker"
Enemy = "Anne"
Enemy_Table:
Enemy_of = "Luke Skywalker"
Enemy = "Wout"
Enemy_Table:
Enemy_of = "Luke Skywalker"
Enemy = "Kris"
# odmadd Fictional_Characters_List
# odmshow Fictional_Characters
class Fictional_Characters {
char Story_Star[20]; /* offset: 0xc ( 12) */
char Birthday[20]; /* offset: 0x20 ( 32) */
short Age; /* offset: 0x34 ( 52) */
link Friend_Table Friend_Table Friend_of Friends_of[20];
/* offset: 0x38 ( 56) */
link Enemy_Table Enemy_Table Enemy_of Enemies_of[20];
/* offset: 0x54 ( 84) */
method Do_This[256]; /* offset: 0x70 ( 112) */
};
/*
descriptors: 6
structure size: 0x170 (368) bytes
data offset: 0x2b0
population: 3 objects (3 active, 0 deleted)
*/
# odmget Fictional_Characters
Fictional_Characters:
Story_Star = "Cinderella"
Birthday = "Once upon a time"
Age = 19
Friends_of = "Cinderella"
Enemies_of = "Cinderella"
Do_This = "echo Cinderella"
Fictional_Characters:
Story_Star = "Cinderella"
Birthday = "Once upon a time"
Age = 19
Friends_of = "Cinderella"
Enemies_of = "Cinderella"
Do_This = "echo Cinderella"
# odmget -q "Enemy=Wout" Enemy_Table
Enemy_Table:
Enemy_of = "Luke Skywalker"
Enemy = "Wout"
First you create a file with a stanza with the object that you want to change. This file is called, for example, testchange.
Fictional_Characters:
Story_Star = "Cinderella"
Birthday = "never"
Age = 19
Friends_of = "Cinderella"
Enemies_of = "Cinderella"
Do_This = "echo Cinderella"
# odmchange -o Fictional_Characters testchange
# odmdelete -o Fictional_Characters -q "Age=19"
odmdelete: 1 objects deleted
# odmdelete -o Enemy_Table
odmdelete: 7 objects deleted
# odmdrop -o Fictional_Characters
As you can see, ODM database object classes have a special format, and it isn't very easy to update the base with a standard editor such as vi. That's why the ODM editor is a real advantage for ODM operations.
# odme Fictional_Characters
The ODM editor odme is really easy to work and you can work very fast.
Warning: Work on the ODM database of your system directory /etc/objrepos (see Object Classes in the ODM Database) with the ODM editor is not recommended for the beginner because the data of the /etc/objrepos are very sensitive for your system.
Information is stored and maintained as objects with associated characteristics. Objects are the entities that make up object classes.
The ODM interface (ODM commands see Using ODM Commands - Example) and the ODM editor allow you to work with the ODM database.
System administrators should use these tools only occasionally to solve system management problems, when they are sure that an ODM database manual update should solve the problem.
On the other hand, you may need to update the ODM database in some specific cases. For example to develop a new device driver. For more information see the publication Writing a Device Driver for AIX Version 3.2.
SMIT is in charge of the update of ODM database for you and the directory /etc/objrepos is very important for your system.
When something is wrong when you work with SMIT you may receive an error message which contains Method error; this shows that SMIT works with the methods descriptors.
COMMAND STATUS/etc/methods/cfgtty is the name of the program that has been executed through SMIT, when the user wanted to add an ASCII terminal, in this case. There is always an accurate message following the name of the method that failed.
Command: failed stdout: no stderr: yes
Before command completion, additional instructions may appear below.
Method error (/etc/methods/cfgtty):
0514-031 A device is already configured at the specified location.
System data managed by ODM includes:
The default object classes of ODM database are the following:
# cd /etc/objrepos
# ls
Config_Rules ------
CuAt |
CuAt.sav |
CuDep | use for customized devices
CuDv | (on the system)
CuDv.sav |
CuDvDr |
CuVPD ------
DAVars ------
DSMOptions |
DSMOptions.vc |
DSMenu | use for the diagnostics
CDiagDev |
FRUB |
FRUs ------
InetServ ------ use for TCP/IP product
MenuGoal ------
PDiagAtt |
PDiagAtt.vc | use for the diagnostics
PDiagDev |
PDiagDev.vc ------
PdAt ------
PdCn | use for predefined devices (not on the
PdDv ------ system, but could be)
SNMPD ------ use for SNMPD
SRCnotify ------
SRCodmlock | use for system resource controler
SRCsubsvr | management
SRCsubsys ------
TMInput
boot ------ use for boot time
config_lock ------ use for device locks
errnotify ------ use for error log
history ------
history.vc |
inventory | use for products installation and update
inventory.vc |
lpp |
lpp.vc ------
lvm_lock ------ use for lock of the logical volume manager
product ------ use for products installation and update
product.vc ------ use for products installation and update
sm_cmd_hdr ------
sm_cmd_hdr.vc |
sm_cmd_opt |
sm_cmd_opt.vc | use for SMIT menus
sm_menu_opt |
sm_menu_opt.vc |
sm_name_hdr |
sm_name_hdr.vc ------
In the directory /etc/objrepos is the ODM database of your system.
The CuAt object class is the Customized Attributes object class. It contains device specific attribute information that either the user or the system has customized and reflects the current configuration of devices on the system.
There are seven descriptors that define an object in the Customized Attributes object class. This object class is maintained by the system and by SMIT.
With the command odmget you can see the objects of the CuAt object class.
# odmget CuAt
CuAt:
name = "sys0"
attribute = "modelcode"
value = "0x0030"
type = "R"
generic = ""
rep = "nr"
nls_index = 0
CuAt:
name = "sys0"
attribute = "dcache"
value = "32K"
type = "R"
generic = "D"
rep = "nr"
nls_index = 15
CuAt:
name = "sys0"
attribute = "icache"
value = "8K"
type = "R"
generic = "D"
rep = "nr"
nls_index = 16
... (this output is truncated)
To run this command, your ODMDIR variable must be equal to /etc/objrepos because CuAt is under this directory.
# echo $ODMDIR
/etc/objrepos