AIX ODM详解

This is a small article about the AIX Object Data Manager, and is created by combining several sources, including this IBM redbook and this old 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:

/etc/objrepos>ls ATM_PVC CuDvDr FRUB PDiagTask SRCextmeth errnotify CDiagAtt CuPath FRUB_SRC PDiagTask.vc SRCnotify history CDiagAtt.vc CuPath.vc FRUs PdAt SRCodmlock history.vc CDiagDev CuPathAt FRUs_src PdAt.vc SRCsubsvr inventory Config_Rules CuPathAt.vc MenuGoal PdAtXtd SRCsubsys inventory.vc CuAt CuVPD PDiagAtt PdAtXtd.vc SWservAt lpp CuAt.vc CuWxt PDiagAtt.vc PdCn SWservAt.vc lpp.vc CuData DAVars PDiagDev PdDv TMInput product CuData.vc DSMOptions PDiagDev.vc PdDv.vc config_lock product.vc CuDep DSMOptions.vc PDiagRes PdPathAt crypto_module CuDv DSMenu PDiagRes.vc PdPathAt.vc crypto_module.vc

There are two main sets of files, explained here:

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 second set of files to understand are the Cu* files, which contain the customized system objects.

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 Customize Device object class file contains physical dependencies.

The Customized Device Driver object class file is managed through special device configuration library routines to guarantee atomic changes.

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 ASCII stanza file as input and populates object classes with objects found in the stanza file.
odmchange	Changes specific objects in a specified object class.
odmcreate	Creates empty object classes. The odmcreate command takes an ASCII file describing object classes as input and produces C language .h and .c files to be used by the application accessing objects in those object classes.
odmdelete	Removes objects from an object class.
odmdrop	Removes an entire object class.
odmget	Retrieves objects from object classes and puts the object information into odmadd command format.
odmshow	Displays the description of an object class. The odmshow command takes an object class name as input and puts the object class information into odmcreate command format.

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.