Object Naming

The System/38 had objects in both the operating system and in the MI. Two different groups of people in the development organization defined and named these objects. One group defined the CPF objects, which were renamed OS/400 objects with the announcement of the AS/400.³ The other group defined the MI instruction set and the MI system objects.

---

³Speaking of names, Rochester systems never used the name “operating system” prior to the AS/400. Operating systems were supposed to be complex and scary to most customers. Names such as Control Program Facility and System Support Program were somehow friendlier and less threatening. To everyone’s surprise, when the PC introduced the Disk Operating System (DOS), no one was concerned; hence, the name change to OS/400.

---

The good news is that sometimes there is a one-to-one mapping between an OS/400 object and a system object at the MI. They are the same. The bad news is that sometimes they are not the same. All OS/400 objects are made up of one or more MI system objects. In other words, the relationship between OS/400 object types and MI system object types is one-to-one or one-to-many, never many-to-one or many-to-many. You will see an example of this in the next section. Before continuing, we need to clarify one more point of confusion.

Even when there is a one-to-one mapping of an OS/400 object to an MI system object, the objects may have different names. For example, OS/400 has an object called a library. There is an equivalent system object at the MI, but there it is called a context. How could this happen? The answer goes back to the System/38 days and the two different groups of people with two different naming philosophies.

One of the philosophies said this: If you are going to come up with a new system, you should rename everything. The reason is to force people to go in and understand the new structure. If you are going to implement a library, and you call it a library, someone will say, “I know what a library is; I worked on another system that had a library.” Of course, that other system’s library may be totally different. If you give the library a new name, such as context, no one will have preconceived ideas about it. Glenn Henry, the System/38 programming manager, advocated this naming philosophy. The group who defined the system objects at the MI used this approach, and they created some very strange names.

The other group was responsible for naming the operating system objects. This group followed Thomas Edison’s approach to naming: Use a name that sounds familiar, even if it isn’t exactly the same. Back in the days when Edison was selling electricity, he decided to use names familiar to everyone who used natural gas. Thus, he would talk about the electric main coming into the house just like the gas or water mains do, even though a main is a pipe or a duct, and electrons don’t usually flow through pipes into a house. He also called the heating element on a stove an electric burner, so that people who were familiar with gas burners would accept the electric stove (honest — the electricity in the heating element is not “burning”). Edison would have liked the operating system group.

OS/400 Objects and MI System Objects

Several object types are available in both OS/400 and the MI. Table 5.1 lists the types of OS/400 objects. For comparison, Table 5.2 lists the MI system objects. Keep in mind that we continue to add functions and even object types to the definition of the AS/400 with each release. The object listings in both Table 5.1 and Table 5.2 are reasonably complete for the purposes of our discussions in this and the following chapters, but all objects may not be included.

Some of the OS/400 objects in Table 5.1 map one-to-one with the MI system objects in Table 5.2, but the name of the object in each set may or may not be the same. An example where the names are the same is a program. The library (context) object is an example where the names are different.

Other OS/400 objects have a one-to-many mapping with MI system objects. Figure 5.1 shows an example of this. The OS/400 database file in our example has five MI system objects, and it is composed of four different types of MI system objects (two are spaces in our example). The actual number of objects making up a file can be much greater. A cursor exists for each member, and even a single-membered join file can own or refer to up to 32 dataspace indexes. In the next chapter, we look at the database and how these various MI system objects are related. For now, we can see the separate pieces.

Figure 5.1  OS/400 Database File Objects

One of the MI system objects is a data space. The database uses a data space to store the physical data, along with a definition of the fields in the database records. A second system object, called the data-space index, contains a description of how the data is to be viewed. In the next chapter, we will see how the data-space index provides a logical view of the physical data. The third object is a cursor that essentially accesses the records in the data space and uses the data-space index to provide the logical view. The cursor provides the open data path to the data space and also contains the user buffers. The fourth object is a space where the result of the database operation can be placed. This is essentially an I/O buffer. The final object shown in our example, which is also a space, contains the file description. This object’s only runtime function is to locate other objects.