SHIFT

--- Sjoerd Hooft's InFormation Technology ---

User Tools

Site Tools


Sidebar

Recently Changed Pages:

View All Pages


View All Tags


LinkedIn




WIKI Disclaimer: As with most other things on the Internet, the content on this wiki is not supported. It was contributed by me and is published “as is”. It has worked for me, and might work for you.
Also note that any view or statement expressed anywhere on this site are strictly mine and not the opinions or views of my employer.


Pages with comments

View All Comments

aixodm

AIX Object Data Manager (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.

ODM

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 on the filesystem

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 Pd* Files

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.

PdDv

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.

PdAt

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.

PdCn

The Predefined Connection object class file contains information about how devices physically connect to the system.

The Cu* Files

The second set of files to understand are the Cu* files, which contain the customized system objects.

CuAt

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.

CuDep

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.

CuDv

The Customize Device object class file contains physical dependencies.

CuDvDr

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

CuVPD

The Customized Vital Product Data object class contains customized data recorded on the topology disk for use by IBM Customer Engineers.

ODM Commands

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.

ODM Errors

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.

You could leave a comment if you were logged in.
aixodm.txt · Last modified: 2021/09/24 00:24 (external edit)