Understanding the AIX Object Data Manager
If you are coming to AIX from another UNIX system, the Object Data Manager (ODM) will be new to you. Fortunately, it is not so very complicated. This white paper explains how ODM is structured and how to use these databases in order to meet the goals the architects had for the ODM.
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.
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.