wp-understanding-the-aix-object-data-manager.pdf

Expert Reference Series of White Papers
Understanding the
AIX Object
Data Manager
1-800-COURSES www.globalknowledge.com

Understanding the AIX Object
Data Manager
Iain Campbell, UNIX/Linux Open Systems Architect, eLearning
Specialist
Introduction
AIX was first announced as a product in 1986 as the operating system (OS) for the PC RT, IBM’s first
commercial RISC processor system. At that time UNIX as an operating system was in its childhood—SUN
Microsystems had released SunOS in 1982, and HP-UX debuted in 1984. But at that point there was little
standardization across these UNIX variants—the Portable Operating System Interface (POSIX) standards
group within the IEEE were working on a set of standards for UNIX-like operating systems, but the first
of those would not be released until 1988, and it dealt largely with kernel internals, not issues of interest
to the systems administrator like input/output (I/O) device management, network configuration, or
package management.
The architects of AIX felt that including a simple database engine as an integral part of the OS and using
that database as a tool to organize configuration data would be a benefit to the system administrator.
Hence, the Object Data Manager (ODM) was born. If you are coming to AIX from another UNIX system,
the ODM will be new to you. Fortunately it is not so very complicated, and once you understand it, you
will find that the ODM meets its objectives, giving the AIX administrator a simple and consistent
interface to manage key areas of configuration data.
We will first look at how the ODM is structured, and then we will examine the range of information
the ODM manages (and also what it doesn’t manage). Finally, we will consider how we can interact
with these databases in order to meet the goals the architects had for the ODM, making AIX
administration easier.
Structure of the ODM
Strictly speaking, the ODM itself is not a database; rather, it is a database engine that operates on data
stored in a database. It is an object-oriented (OO) design, consisting of about 50 or so object classes. As
is the case with OO databases, each class has a name and a list of attributes for which each object in that
class will possess its own set of values.
Device Management
As device management is one of the key functions of the ODM, let’s examine a device example. If a
system has access to a disk, then we might want to know where that disk is located in the system,
what type of disk it is, if the disk driver is loaded and working, and what name we will use to reference
the disk.
To do that, an OO database might have an object class called devices, and that class might have
attributes like location, type, status, and name. Then, for each actual device in the system, there would
be a corresponding object entered into that class.
Copyright ©2014 Global Knowledge Training LLC. All rights reserved. 2

So, consider a working SAS disk located in slot three of the internal disk cage; its object entry might look
something like this:
devices:
Name = disk01
Location = slot3
Type = SAS
Status = Up
A Fibre Channel (FC) attached LUN provisioned from a storage area network (SAN) might look like this:
devices:
Name = disk04
Location = SAN
Type = fc_LUN
Status = Up
And, if the type attribute is not restricted to disks, then an Ethernet card might look like this:
devices:
Name = ethernet01
Location = slot4
Type = Ethernet
Status = Up
Now, it may be that our SAS disk driver has some optional values that could be adjusted to optimize the
performance of the drive. For example, disk drivers might allow multiple I/O requests to queue up for
the drive, and we might want to adjust the length of the queue. So, we could add another attribute to
our devices class called queue, and our disk01 object might now look like this:
devices:
Name = disk01
Location = slot3
Type = SAS
Status = Up
Queue = 10
This works fine for one disk, but what happens if this queue doesn’t work the same way for an FC
attached LUN? Perhaps LUNs do queuing a different way, and need a different parameter, the value of
which will not be relevant for the SAS disk. So now our disk objects might end up looking like this:
devices:
Name = disk01
Location = slot3
Type = SAS
Status = Up
Queue = 10
SAN_Queue = null

devices:
Name = disk04
Location = SAN
Type = fc_LUN
Status = Up
Queue = null
SAN_Queue = 100
Now, what about our Ethernet card? Neither of the queue parameters matters to it, so its device entry
ends up looking like this:
devices:
Name = ethernet01
Location = slot4
Type = Ethernet
Status = Up
Queue = null
SAN_Queue = null
The problem is that each type of device has attributes specific to that device, and if we try to implement
all the possibilities in one object class—it doesn’t work very well, specifically, it isn’t very scalable. What
we could do is to create another object class that we can use to store data about device attributes and
their values.
If we want to use this approach to handle our disk queuing parameters, then our new attributes object
class might have objects like this:
attributes:
Type = SAS
Parameter = Queue
Value = 10
attributes:
Type = fc_LUN
Parameter = SAN_Queue
Value = 100
This can be easily extended to support a parameter value for an Ethernet card as well. So, for example, if
I have a Gigabit card:
attributes:
Type = Ethernet
Parameter = Speed
Value = 1000
Now we have some scalability. When the OS is working with disk01, its utilities can be coded to scan the
devices class to find the location, name, and other device attributes—and they can also scan the
attributes class for all objects having Type = SAS for performance parameters.

Some problems still remain, however. If we have several SAS disks and some are newer than others, then
the newer disks might perform best with a queue attribute larger than the value best suited to the older
disks. We cannot necessarily assume that because a disk is a SAS disk, it should use the same value for
any given attribute.
This can be solved by replacing the attributes class with two classes, which could be called default and
custom. For a SAS disk named disk01 needing a queue length of 10, these objects would be relevant:
devices:
Name = disk01
Location = slot3
Type = SAS
Status = Up
defaults:
Type = SAS
Parameter = Queue
Value = 10
For a newer SAS disk named disk02 needing a queue length of 20, an additional object is created in the
custom class:
custom:
Type = SAS
Name = disk02
Parameter = Queue
Value = 20
For this to work, it is only necessary to add code to specify that where it is possible to obtain conflicting
values for the same combination of device and parameter value then the value obtained from the
custom class will take precedence.
Now, what about that Ethernet card? Let’s assume it is a multi-port card (and most are). How can we
handle two sets of parameters using only one device object? We could add an attribute for number of
ports, but then how could we address the situation in which each port might need different parameters,
such as speed or frame size?
In this case, it makes more sense just to consider each port as a separate device. So, for our two-port
Ethernet card, we would have two devices objects:
devices:
Name = ethernet01
Location = slot4
Type = Ethernet
Status = Up
devices:
Name = ethernet02
Location = slot4
Type = Ethernet
Status = Up

We might have these Defaults and Custom objects if we want one of the ports to use jumbo frames:
defaults:
Type = Ethernet
Parameter = Jumbo_Frames
Value = no
custom:
Type = Ethernet
Name = ethernet02
Parameter = Jumbo_Frames
Value = yes
Package Management
So far, we have been using I/O device management examples. Let us now consider a different
application— package management. Most operating systems have some sort of package manager, which
is a system that allows each of the data files that make up the OS to be organized into groups so that
they can be selectively installed as desired and patched as necessary. How would we start to lay out our
object classes?
We will want to start with a class called files, whose objects might have attributes such as name, size, or
permissions, like this:
files:
Name = “/etc/passwd”
Size = 2344
Owner = root
Permissions = 644
We will also want an object class for packages, the groupings we will use to allow groups of files to be
managed as a single entity, which is really what package managers are all about. So, we might have an
object like this:
packages:
Name = “User Management”
Package_ID = 211
Now the goal is to organize files into packages, and also to add patch management so that our package
needs to have a version number. After adding this, our objects would be:
files:
Name = “/etc/passwd”
Size = 2344
Owner = root
Permissions = 644
Package_ID = 211
packages:
Name = “User Management”
Package_ID = 211
Version = 4.0.4

We could go on to add information about prerequisites, installation history, file checksums, and so
forth—but this simple example illustrates how the ODM concept can be applied as equally to package
management as it can to device management.
Now that we have presented some simple examples of a hypothetical ODM, we will examine how the
real AIX ODM is structured.
Structure of the AIX ODM
The actual AIX ODM consists of some 50 or more object classes. The object data for each class is stored
in binary formatted files, each file containing the data for one class and named after the class whose
data it contains.
Most of these ODM data files are located in /etc/objrepos (objrepos is a contraction of object
repository). Some of the entries in /etc/objrepos are links to data files that reside in
/usr/lib/objrepos—these are classes that contain data that is read-only. Most of these read-
only classes are device related; the equivalent of the defaults class in our example database.
Data Managed by the ODM
It is useful to note that the ODM does not manage all AIX configuration data. The ODM is used to
manage data in seven distinct functional areas. Within these areas, all relevant data is managed by
the ODM (outside of these areas the ODM is not involved). These are the bodies of data managed by
the ODM:
Devices and Network Configuration
Data about all I/O devices and also network configuration data (such as IP configuration) are held
primarily in these core classes:
• PdDv (Predefined Devices) —- the list of all devices supported by this release of AIX
• PdAt (Predefined Attributes) —- default values for all device attributes
• CuDv (Customized Devices) —- the devices present on this machine
• CuAt (Customized Attributes) —- non-default attribute values
Referring to the example database we developed earlier, the CuDv class would be the equivalent of the
devices class, PdAt would be the defaults class, and CuAt would be the custom class.
AIX adds the PdDv class to support plug and play device configuration. Each AIX-supported I/O device
will report a unique identifying string to the kernel device configuration code at boot time. The kernel
code looks up that ID in the PdDv class to see if it finds a match. If it does, then the device is supported,
and the data in the matching object contains information about the driver module to be loaded by the
kernel to support that device.
If a device does not get recognized at boot, it could be because it is physically broken and unable to
provide the ID string when requested. Or, the ID string provided has no match in the PdDv class, which
implies that the device is not supported by the version of AIX that the machine is running. New device
support is added to AIX via the release of new Technology Levels (TLs), which will result in changes to
the PdDv class to support new devices.

There are more classes relating to data such as parent/child relationships (e.g., multi-port adapters),
paths to SAN LUNs, or Vital Product Data (VPD)—the term used by IBM to include hardware-specific data
such as manufacturer, serial number, or firmware version. Feel free to explore these on your own
systems using the commands we will show you.
Installed Software (Package Management)
The classes associated with the AIX package manager are:
• lpp —- description and install state of each package
• product —- pre requisite and version information for each package
• inventory —- individual file data, one object per each file belonging to a package
• history —- dates of most recent install or update events for packages
System Management Interface Tool (SMIT)
Located in /usr/lib/objrepos, the set of classes beginning with the string sm_ contain all the
data necessary for SMIT to function. This includes all of the menu/submenu structure, the questions in all
the dialog screens, the commands used to generate lists, and so forth. These classes cannot be viewed or
edited.
It is interesting to note that as the whole structure of SMIT is database-driven, it makes it easy for IBM to
maintain it as new functionality requiring additions and changes to the SMIT menus dictate.
Network Installation Management (NIM)
Should you choose to build a NIM server (and in any AIX environment, you should!)—all the data
required to manage network installation, backup, recovery, and software maintenance is stored in a
group of classes beginning with nim_.
System Resource Controller (SRC)
The SRC is an AIX utility that brings the ordered structure of the ODM to bear on the task of organizing
daemon processes. The classes beginning with “SRC” contain the list of all known daemons and the
details of the commands needed to manage them. The master SRC daemon (srcmstr) is started from
/etc/inittab at boot and uses the SRC object class data to give the administrator a consistent way
to manage daemons using the startsrc, stopsrc, lssrc, and refresh commands.
Error Logging and Kernel Dump Configuration
There are some very small classes that contain information concerning the configuration of the kernel
log and also kernel dump configuration.
It is worthwhile to note that OS configuration data that does not fall into these categories is not
managed in any way by the ODM. For example, no user account data, such as login information,
password management, and so forth is stored in the ODM. Also, the ODM holds no storage
management data, so no information regarding Logical Volume Management (LVM), file systems or
mount tables is stored in the ODM.
Finally, let us look at some commands we can use to interact with the ODM.

The ODM from the Command Line
ODM class data can be manipulated directly, although this is very rarely necessary. Normally higher- level
commands such as lsattr or chdev are used, as we will see. However, you might want to do some
investigation to get a better understanding of the structure of the actual data a command (like lsdev,
for example), is operating on. How this can be done is outlined next.
Examining ODM Data
In order to examine the structure of a class:
# odmshow CuDv
This will give you a C syntax-like definition of each of the data types and names in the class specified as
the argument to the command, in this example CuDv, the customized devices class. Note that this is
describing only the structure of the class—not any actual object data.
In order to examine actual objects, do this:
# odmget CuDv
This will return all the objects in the class in stanza format, similar to the format used in the example
database earlier.
In many cases you will not want all the objects in a class; in order to select only the objects of interest,
you can add a query term, for example:
# odmget -q name=hdisk0 CuDv
More complex queries are possible using an SQL-like syntax:
# odmget -q “parent like ‘scsi*’ ” CuDv
# odmget -q “parent = scsi0 and connwhere=‘8,0’ “ CuDv
Deleting Objects
It is also possible to modify objects directly, although that is rarely necessary and should be done with
great caution, as there is essentially no error checking. If you make a mistake, it can be very difficult to
correct, so be very careful!
For example, consider the following:
# odmdelete -o CuDv
That will immediately delete all objects in the CuDv class, effectively crippling the device configuration
database! Fortunately this can be repaired by retrieving a copy of the file /etc/objrepos/CuDv
from a backup. Most AIX operations would continue in the meanwhile, although changing a device
would likely fail with strange errors until you can recover those lost objects.
An even more dangerous command might be:
# odmdelete -o CuDv -q “name like ‘en*’ “
That will delete only objects that match the query. If you know in advance which objects those are, then
you have a chance of getting them back. But if you don’t really know how many objects the query
matched it is too late to find out now because they’re gone. Again, the fix here would be to recover the
entire CuDv object class data file.

Creating and Changing Objects
If you want to create a new object or objects you can edit an ASCII text file containing the definition of
the desired objects in the same stanza format as you would see in the output of odmget. If you name
that file NewObjects.asc, for example, then:
# odmadd NewObjects.asc
will add the objects detailed in the file. One input file can create multiple objects, potentially in multiple
classes according to the stanza data in the input file.
Finally, you can also change object data:
# odmchange -o CuDv ChangedObject.asc
where the input file is again in the stanza format. Normally, an odmget command is used with output
redirection to a file to obtain the current values. That file can then be edited to reflect the desired
changes and fed back using the odmchange command.
These commands that directly manipulate the ODM are, as I mentioned, rarely (if ever) necessary to
know for everyday administration purposes, but if you want to get a better idea of how the ODM works
at the raw data level this is how to do it.
Let us conclude then by looking at the commands that you do use on an everyday basis, and see how
they interact with the underlying ODM.
AIX High Level ODM Dependant Commands
There are five key AIX commands that exclusively interact with the device management component of
the ODM. They are lsdev, chdev, lscfg, lsattr and cfgmgr. If you were to issue the
command:
# lsattr -El hdisk0
and then these ODM commands:
# odmget -q name-hdisk0 CuDv
# odmget -q name=hdisk0 CuAt
# odmget -q uniquetype=“disk/scsi/osdisk” PdAt
it should be clear where the lsattr command is getting its information. You will see that lsattr is
selective; it doesn’t report all of the data stored for hdisk0 in the ODM, just the parameters that are
the ones most useful in practice.
The format of the lsattr output is also considerably more human friendly than the verbose stanza
output format of the raw ODM data. Try this with lsdev and lscfg and you will see that these
commands choose a different subset of the raw ODM data to report.
If there are few objects returned by the odmget against the CuAt class, use chdev to change one of
the attributes of the device. You should now see a new object created in the CuAt class as a result, if the
parameter value you entered for your change was a non-default value.
If you wonder what the E and D flags for the lsattr command mean, a bit of experimenting will
show that using the D flag causes lsattr to look only in the predefined classes such as PdDv and
PdAt—the default values—while the E flag causes lsattr to instead report the union of the default
and customized class data, giving you the currently effective (hence E for effective) parameter values for
the device in question.

The PdDv class is central to AIX plug and play device configuration, driven by the cfgmgr command.
When you issue cfgmgr the ODM device database is rebuilt, and any drivers that need loading into
the kernel will be loaded and started. So, if you issue the command:
# rmdev -l hdisk1
and then look at the ODM objects that relate to hdisk1, you should find that they are all still there;
all that rmdev without the d flag does is to unload the kernel driver. Check the CuDv object for
hdisk1 and you should find its status attribute has the value 0, where it would formerly have had the
value 1. Issue cfgmgr, the driver will be reloaded and the status parameter will return to a value of 1.
If, on the other hand, we add the d option to the rmdev command:
# rmdev -dl hdisk1
then in addition to the kernel driver being unloaded the CuDv object for that device is deleted, as well as
any CuAt objects referencing that device. Issuing cfgmgr will get the device back and the driver
loaded, but any non default attributes will revert to default values, meaning that no new CuAt objects
will be created as a result of the cfgmgr command (except in the case of a disk that has a Physical
Volume ID [PVID], as that is stored permanently on the disk and is read into a CuAt object when the disk
is configured, indicating as mentioned earlier that storage configuration is not primarily managed in the
ODM; the ODM merely holds copies of the data that exists primarily on disk itself).
Package Management
The key high level commands for package management include installp and lslpp. Try
something like:
# lslpp -l bos.rte
and then:
# odmget -q name=“bos.rte” lpp
# odmget -q lpp_name=“bos.rte” product
and compare what you see. Note the lpp_id parameter value from the lpp class and use that as a query
against the other package management classes:
# odmget -q lpp_id=1 inventory
# odmget -q lpp_id=1 history

Conclusion
So, what does all this mean for the AIX administrator? Here are five key things to take away:
1. The ODM operates primarily in the background. The AIX administrator rarely (if ever) has to
interact directly with the ODM.
2. The ODM brings structure to the management of key bodies of data needed to configure AIX.
This allows for consistency in commands that can be built to implement device and package
management, among others.
3. The ODM does not manage data relating to user administration or file system management. It
does have objects relating to Logical Volume Management; however, the objects in these
classes are derived from LVM metadata whose primary and authoritative storage location is
located in LVM-specific data structures located on the disk storage itself.
4. Devices in AIX are all essentially plug and play devices. The list of devices supported being
determined by the Technology Level (TL) of the AIX release which in turn dictates the data
content of the predefined device object classes.
5. The System Resource Controller (SRC) is an offshoot of the ODM which brings consistency to the
management of system daemons by adding classes to the ODM to hold data about all daemon
processes supported by the release of AIX in play.
Learn More
Learn more about how you can improve productivity, enhance efficiency, and sharpen your competitive
edge through Power Systems training.
AIX, UNIX
IBM i
Linux
System Software
Visit www.globalknowledge.com or call 1-800-COURSES (1-800-268-7737) to speak with a Global
Knowledge training advisor.
About the Author
Iain Campbell is a mechanical engineer by profession. While responsible for managing several production
automation labs at Ryerson Polytechnic University in Toronto, he became distracted by UNIX operating
systems. His first experience of AIX was a PC RT used in the lab as a machine cell controller. Iain has been
teaching and consulting in AIX and Linux since 1997. He is the author of Reliable Linux (Wiley, New York,
2002), as well as several technical papers and curriculum material. He holds LPI and Novell certifications
in Linux administration, and is an IBM certified AIX Specialist.

wp-understanding-the-aix-object-data-manager.pdf

More Related Content

Similar to wp-understanding-the-aix-object-data-manager.pdf (20)

More from hellobank1 (6)

Recently uploaded (20)

wp-understanding-the-aix-object-data-manager.pdf