Object Data Manager (ODM)

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.

What Is ODM ?

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.

Functions of ODM

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.

ODM Terminology

ODM uses an object-oriented approach to data management.
Three directories, in AIX V3.2, contain ODM database files:

Object Class and Objects

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 {
char name[16];
short vpd_type;
longchar vpd[512];
};

CuVPD ---> Objet Class
vpd_type ---> descriptor

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.

You can find a summary of this terminology in Figure 2.


Figure: Summary of ODM Object Class Definitions

ODM Descriptors

An ODM descriptor is conceptually similar to a variable with a name and a type. When an object class is created, its descriptors are defined like variable names with associated ODM descriptor types. When an object is added to an object class, it gets a copy of all the descriptors of the object class as its own general attributes. Values are also associated with the descriptors of an object when the object is added to an object class.

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" CuVPD
CuVPD:
name = "hdisk2"
vpd_type = 0
vpd = "*Z00000*MFIBM *SN00521991*Z70899624 "

ODM supports several descriptor types such as:
Terminal descriptor
Defines a character or numerical data type
Link descriptor
Defines a relationship between object classes
Method descriptor
Defines an operation or method for an object

ODM Terminal Descriptor

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:

short
A signed 2-byte number.
long
A signed 4-byte number.
binary
A fixed-length bit string. The binary terminal descriptor type is defined by the user at ODM creation time. The binary terminal descriptor type cannot be used in selection criteria.
char
A fixed-length, null-terminated string.
vchar
A variable-length, null-terminated string. The vchar terminal descriptor type cannot be used in selection criteria.

ODM Link Descriptor

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.

ODM Method Descriptor

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.

Using ODM Commands - Example

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:

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.

Object Classes in the ODM Database

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
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.

/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.

Directory /etc/objrepos

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 ------

Real Life Example

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