The Object Data Manager: why AIX device and system configuration isn't in a file

What it is

The Object Data Manager (ODM) is AIX's database for system and device configuration. Its object classes live as files under /etc/objrepos (the default ODM directory) and /usr/lib/objrepos, but those files are binary object stores, not text to edit directly; corrupting one can stop devices, subsystems or SMIT itself from working. Device attributes, the System Resource Controller's subsystem table (SRCsubsys), and many kernel-level settings (via the sys0 pseudo-device) are all ODM objects.

The supported interface is a small set of commands, not an editor:

• lsattr -El <device> reads an object's current attributes (also used against sys0 for system-wide settings).
• lsdev lists device objects and their state.
• chdev changes an attribute and writes the result back to the ODM, going through the device method that also updates the running kernel state when possible.
• odmget reads ODM object classes directly and is safe for inspection; odmadd/odmchange/odmdelete write them and are normally reserved for documented or support-guided procedures, not routine administration.

Why it matters

Editing /etc/objrepos files by hand, or restoring them from an unrelated system, bypasses the consistency checks chdev/mkdev perform and is a well-documented way to corrupt device configuration. The supported workflow (lsattr/chdev/lsdev) is what keeps the ODM and the live kernel state in agreement.

Some attributes cannot be changed on a device that is open or busy — the classic case is the disk holding rootvg. For those, chdev -P writes the new value to the ODM only, without touching the running device, and the change takes effect after the next reboot. Without -P (the default), chdev tries to apply the change immediately as well as recording it in the ODM.

How to apply

• Inspect before changing: lsattr -El sys0 -a maxuproc shows a single attribute's current value.
• Change immediately where the attribute permits it (as root): chdev -l sys0 -a maxuproc=4096. Not every sys0 attribute is dynamic — enhanced_RBAC, for example, only takes effect after a reboot.
• For an attribute on a device that cannot be closed (for example a disk in an active volume group), add -P and reboot at a planned time to apply it: chdev -P -l <device> -a <attr>=<value>, then verify afterwards with lsattr again.
• Never restore /etc/objrepos from another machine's backup; if the ODM is suspected corrupt, work from IBM's documented recovery procedure instead.

Pitfalls

• Forgetting that -P alone does not apply the change — it only queues it for the next boot.
• Assuming every attribute accepts -P/-T (temporary); not all devices support every mode.
• Bypassing chdev with a text editor on ODM files "just this once" — there is no supported way to hand-edit them safely.