| Previous | Table of Contents | Next |
Several object types are defined at the MI. Most of these are the complex data structures needed to represent information resources. One of the most important object types in the system is a space. A space is simply a chunk of bytes; it has no relationship to the physical hardware. The concept of a flock of bytes floating in the ether is difficult for many people to grasp. They want to tie this space to physical hardware. But the MI has no concept of physical memory attached to the space. It is absolutely independent of what is underneath.2
2AS/400 people like to talk about the single-level store. As we have just seen, there is no memory at the MI. Therefore, the single-level store is not visible at or above the MI; rather, it is part of the internal implementation of an AS/400.
When an MI program needs memory, it can use a space. There is no concept of registers, no concept of physical memory, and there are no memory addresses in the traditional sense. As an example, when an AS/400 compiler creates a program template, it has to put it somewhere; so it puts it into a space.
In addition to spaces, there are several other types of objects that we discuss in later chapters. So far, the only objects described are the ones in the MI, which are called the MI system objects. OS/400 also supports objects.
Several MI instructions work on programs. Because a program is an object, these instructions operate on the program as a complete entity. All of the instructions perform only those operations on a program that make sense. There is a Create Program instruction, but there is no Multiply Program instruction. Creating a program makes sense, but multiplying one program by another does not. The point is, instructions are specific to the type of object being manipulated. Instructions operate on the whole object, not some piece of data within an object. It is not possible to misuse an object, and this provides another major benefit of object orientation: integrity. Programs at the MI do the right thing. In this section we look at how to create a program, how to destroy a program, and how to materialize a program.
We create a program from a template, which is a predefined structure that describes all the characteristics of a particular MI system object. The code generation part of the AS/400 compilers generates this program template. All MI system objects are created from templates, which are contained in spaces at the MI. Because different types of objects have different characteristics, there is no one generic template; each object has its own unique template.
The Create Program instruction points to a program template. For the purpose of this discussion, there are two types of pointers: a system pointer and a space pointer (we will see later that other pointer types also are supported). A system pointer points to an MI system object, while a space pointer points to a byte in a space. Each of these pointers is 16 bytes long. Addressing at the MI is accomplished with a pointer. In fact, you can think of a pointer simply as an address at the MI.
Code below the MI implements the Create Program instruction. First, the space pointer in the Create Program instruction is used to access the program template. A syntax check of the program template is made to ensure that the template is correct. If it is, the translator is invoked to transform the MI instruction stream contained in the program template to the internal instruction stream. This internal IMPI or PowerPC instruction stream is packaged into an MI system object called a program. Finally, addressability to the newly created program is returned to the requester as a system pointer to the object. If there are problems with any part of this operation, the diagnostics are returned as an exception.
Any MI system object that can be created can also be destroyed. Just as there are MI instructions to create objects, there are instructions to destroy objects. A user at the MI level provides a system pointer to a program or any other MI system object and says, “Destroy it.” Of course, there is a catch: Not just anyone can destroy an object; the user must have the proper authority to be able to do so.
We discuss object authorization in more detail in Chapter 7, but briefly, for the purpose of this current discussion, it’s important to know that a user can have various levels of authority for any particular object. The highest level of authority allows the user to destroy an object. Usually, only the owner is allowed to destroy an object; but situations exist where multiple users may have that authority. Associated with each user in the system is a special MI system object called a user profile. The user profile, among other things, identifies the authorizations a user has to the various objects. When a user issues the destroy instruction, the system first checks the user profile to see whether that user has the authority to destroy the particular object before it carries out the operation.
| Previous | Table of Contents | Next |