This is a small article about the AIX Object Data Manager, and is created by combining several sources, including this and this and this newer articles. I ran into the usage of ODM the first time we had an error referring to the CuDv database. Although I heard about it I didn't know what to do so I started searching and reading. One of the first things I notices is that there is not that much information about it. The redbook for example is last edited in 2004, 6 years ago. I can't find any new redbooks which are also referring to this, so I decided to combine all the information I could find so other people might find it useful.
The Object Data Manager, or ODM, is a set of utilities that AIX uses to keep track of configuration information. It consists of several (binary) files, in which objects are stored which describe system data.
System data managed by ODM includes:
Device configuration information
Predefined: Devices that AIX has drivers for or knows about, but are not currently installed or active.
Defined: Logical devices or drivers which don't map directly to a physical device. This includes network configuration, LVM configuration, and installed software information.
Available: A physical hardware device which is installed, configured, and in use.
Display information for SMIT (menus, selectors, and dialogs)
Vital product data for installation and update procedures
Communications configuration information
System resource information
ODM spreads its files over the filesystem. These three directories are all used for storing files related to ODM:
/usr/lib/objrepos
/usr/share/lib/objrepos
/etc/objrepos
You can see which one is the default by checking the ODMDIR variable on a system:
# echo $ODMDIR
/etc/objrepos
If you list all the files in this directory you'll see quite a list:
The first set of files that you'll need to understand are the Pd* files, which contain the predefined system objects. The entries in these files are loaded from the installation tape; under normal use, they should not be edited.
The Predefined Device object class file contains an entry for every known device on the system. It includes definitions for all of the configurable printers, expansion cards, device drivers, logical volumes, volume groups, and many more.
The Predefined Attribute object class file contains device-dependent information not found in the PdDv file but relevant to device configuration. These attributes become the default values if they are not modified. Modified attributes are written to the CuAt. The uniquetype field actually consists of the first three entries in the PdDv: type, class, and subclass. These entries are used to link the attributes to the specified device. This mechanism ensures a unique name for each device.
The Predefined Connection object class file contains information about how devices physically connect to the system.
The Customize Attribute files contain non-default values for the specified device. The default values are kept in the PdAt file. Both files must be searched to find all of a device's attributes. A defined ethernet adapter entry would look like that in the PdAt file; otherwise the entry would not exist.
The Customize Dependency object class file contains logical dependencies between devices. The file does not contain customized dependencies between two physical devices. If present, these would be in the CuDv file.
The Customized Vital Product Data object class contains customized data recorded on the topology disk for use by IBM Customer Engineers.
This warning is from the IBM Redbook:
Note: ODM commands should be used only when traditional methods of
system maintenance, such as SMIT, are ineffective. For a beginning
system administrator, it is recommended that you perform additional
reading and exercises before using these commands. Incorrect use of
these commands may result in a disabled system. The ODM commands
are described here for introductory purposes.
Command
Explaination
odmadd
Adds objects to an object class. The odmadd command takes an
The error we got I mentioned before:
sudo smitty chgsys
changing:
Maximum number of PROCESSES allowed per user
When you try this you'll get the error:
chdev: 0514-518 Cannot access the CuDv object class in the device
configuration database.
This is because of the variable ODMDIR. When you want to change the device sys0 (which is what you're doing) you need access to the CuDv database. The system can find the database by the variable ODMDIR. Although the user has this variable, you perform smitty as being root without the variables. A workaround for this problem is to change directory to the value of ODMDIR (in my case /etc/objrepos) and run the command from there. Smitty will look in the current directory for the CuDv database and will find it there.
---------------------
AIX: odmget examples
odmget -q"name=hdisk0" CuDv # get ODM object in the CuDv that describes hdisk0 disk device
odmget -q"name=hdisk0 and attribute=pvid" CuAt # get ODM object that stores the PVID
odmget -q"value3=hdisk0" CuDvDr # get major,minor number of special file for hdisk0
odmget -q"name=rootvg" CuDep # query ODM class to identify all LVs that belong to rootvg
odmget -q"parent=rootvg" CuDv # the same as previous command
Can be usefull when troubleshooting LVM related problems
