Other Pointer Types

A system pointer provides the access to a system object, but for some operations, we also need to manipulate the data contained in these objects. We accomplish this with other types of pointers that allow access to the internals of an object. Before I describe these pointers, I need to explain the internal structure of a system object.

A system object internally is divided into two major parts: a functional portion and a space portion. The contents of the functional portion are dependent on the system object type. For example, the functional portion of a program would contain the instruction stream for that program. The space portion of a system object (often called the associated space) is simply a byte space that is used as a work space. All system objects have a functional and a space portion, with one exception. A system object called a space has no functional portion; it has only a space portion.

A separate space portion is needed in an object because of the way the MI views memory. Remember, to be independent of the underlying technology, the MI has no idea of a memory in the traditional sense; it has only objects, and there is nothing outside of these objects. The pointers and the data created by system users need to be kept someplace. The space portion of the system objects provides this place.

Figure 5.5 shows two system objects, each with a functional and a space portion. The space portion can contain both pointers and data. In the figure, the space portion of the second object contains a system pointer that points back to the first system object. System pointers always point to system objects. Very little can be done to a system pointer, because it can only point to the beginning of a system object. Its primary use is to access the object. But what if we want to get inside the object and manipulate bytes?

Figure 5.5  System Objects

Because all system objects are encapsulated, it is not possible to manipulate the bytes inside the functional portion — it is not even possible to look inside this portion. The space portion, on the other hand, is used as a work space. We need some way to access information in this work space, and a space pointer provides the mechanism.

A space pointer looks very much like a system pointer. It is 16 bytes long and contains an address. The difference is that the address in a space pointer points to a byte somewhere in the space portion of a system object. So we can use space pointers to access and manipulate the bytes contained in this space.

Another major difference between the two types of pointers has to do with the operations that each can perform on the address. The address in the space pointer can be modified by the MI program to point to other bytes in the same space. The address in a system pointer cannot be modified. It can only point to the beginning of the object. If authorized, a user with a system pointer to an object can get a space pointer for that same object. The second object shown in Figure 5.5 also contains a space pointer that illustrates how this type of pointer provides access to the byte space of the first object.

In addition to system and space pointers, there are four other types of pointers at the MI. A data pointer is similar to a space pointer except that it contains the description of the type of data to which it points. This provides the capability to look at a string of bytes in a space and treat that string as any type of data. An analogy to this would be a pointer in the C language. An instruction pointer at the MI is used for branching in an MI program. It points to an instruction in the instruction stream of the program.

The four pointer types we have discussed so far (system, space, data, and instruction) were in the original System/38 design. A special version of a space pointer, the machine space pointer, was later added to provide access to internal machine storage. When ILE was added to the AS/400, a new procedure pointer was added. We use procedure pointers for the call/return operations, described in Chapter 4.

System Object Characteristics

We are now at a point where we can list the main characteristics of all system objects. We cover some of these characteristics in later chapters, but we list them here for completeness.

1.  System objects must be explicitly created with a CREATE instruction at the MI.

2.  A CREATE instruction references a user-supplied template, which contains the attributes and values for the object. The template is contained in a space object.

3.  The attributes of a system object can be materialized.

4.  A system object can be explicitly destroyed.

5.  All system objects have names if they appear in a context. A system object does not have to be named if it is never referenced in the library or file system. A system object used exclusively by the SLIC is an example of such an object.

6.  System pointers provide addressability to system objects.

7.  System objects have a space that contains pointers and data.

8.  System objects are created as temporary or permanent objects. A permanent object stays in the system forever, unless it is explicitly destroyed. This characteristic is referred to as persistence. A temporary object goes away whenever the initial program load (IPL) operation is performed.

9.  Temporary objects can be placed in access groups. An access group is another system object that allows multiple objects of different types to be bundled and accessed together.

10.  Authorization to system objects is monitored by the machine.

11.  Object use is synchronized through object locks.

The eighth characteristic, object persistence, needs some elaboration, because it sets the AS/400 apart from other systems. As noted, persistence simply means the object continues to exist in the memory system forever. Being in the memory, it can easily be shared among users. This is very different from a conventional system, which requires that information be stored in a separate file system if the information is to be shared or if it is to be retained for a long time. Later, we will see how the AS/400’s single-level store enables this object persistence.

Persistence of objects is extremely important for future support for object-oriented databases. Objects need to continue to exist even after their creator goes away. The AS/400 is uniquely positioned to exploit this characteristic of object persistence, whereas other operating systems will have to resort to storing their persistent objects in a separate file system.

Not every object needs to be kept forever. When it is created, an object is identified as either permanent or temporary. Permanent objects last forever; they are more costly because they tie up system resources for as long as they exist. A permanent object goes away only if it is explicitly destroyed. An example of an object that might be created as permanent is a data space, where database records are kept.