| Previous | Table of Contents | Next |
Network computing and the Internet have brought the subject of object technologies to the forefront of the computer news. The growing use of programming languages such as Java and C++ is causing application developers to reevaluate their use of traditional languages and to look at the benefits of these new object-oriented languages. Like so many other technologies we think of as new, the use of objects in programming goes back more than 30 years.
Objects were first used in the late 1960s in programming languages such as Simula 67, which were used to write simulation programs (modern object-oriented languages such as Java, C++, and Smalltalk are direct descendants of Simula 67). A computer simulation program models the behavior of objects in the real world. In a similar way, business application programs model the behavior of real-world business transactions, which usually involve some business objects and the operations on those objects.
Operating systems also model and manipulate hardware and software objects, such as I/O devices and programs. Incorporating objects into an operating system seems to be fairly natural. Operating system vendors such as Microsoft, Apple, Novell/USL (UNIX Systems Laboratory), and Sun Microsystems have talked about building object-oriented operating systems, yet few are available. Next is one of the few vendors already shipping an object-oriented operating system, which it calls NextStep.
There is, of course, another operating system that is object-oriented. Since the introduction of the System/38, we have built operating systems (CPF and OS/400) around an object model.1 Furthermore, we didn’t stop with the operating system; we made objects a fundamental part of the machine design. As we discussed in Chapter 4, the MI is composed of two parts: instructions and objects. In this chapter, we look at the way the AS/400 uses objects.
1Some of us were very familiar with computer simulation languages in the late 1960s, which helps to explain why the System/38 was based on an object model. My own Ph.D. research used a computer simulation to model various virtual-memory designs. The actual decision to use objects in the System/38 came after we were involved in the Future Systems project as described in the Appendix.
The AS/400 is sometimes described as an object-based system rather than an object-oriented system. The two terms have meaning when we are discussing programming languages. For example, there are object-based languages such as Ada and object-oriented languages such as Smalltalk-80. Grady Booch2 defines the differences between an object-based and an object-oriented programming language. He says an object-based language does not have inheritance. As we introduced briefly in Chapter 3, inheritance defines a hierarchy among classes in which a subclass shares the structure or behavior of one or more base classes. Inheritance allows new object types to be created. Because AS/400 objects do not inherit from other object types, and because application programmers cannot create new object types, it is probably still more accurate to describe the AS/400 as an object-based system. No matter which name we choose, keep in mind that the AS/400 doesn’t simply use objects or incorporate objects; they are a fundamental part of the design.
2Grady Booch, Object Oriented Design with Applications, The Benjamin/Cummings Publishing Company, Inc., 1991.
An object is just a container. All user and system data structures are packaged within these containers. Further, the object is encapsulated, which, as we discussed earlier, means it is not possible to see inside. A system built around an object model supports machine independence. The reason for putting objects into the System/38 in the first place was to keep the details contained so they could later be changed without affecting user application programs.
Still another reason for using objects was integrity. The original System/3 was a byte machine, which means everything was on a byte boundary. The System/3 instructions had a single-byte op-code. Instructions occupied several consecutive bytes in memory, but there were no enforced boundary alignments for the instructions. This meant that any byte in memory could contain a System/3 op-code. Further, all the bits in the op-code were used to specify the operation to perform and where the operands would be found. Almost any combination of bits in a byte could be interpreted as a valid op-code.
This caused a problem to occur with the System/3 if a program accidentally branched into a data area: The processor would continue to fetch bytes and treat them as instructions. The program might continue executing for a long time, creating all kinds of havoc with the system. Debugging these problems was no fun.
Consequently, we were very sensitive to the System/3’s integrity problems, and to those of most any other computer system of the time. For example, in a conventional system, a string of bytes can be treated as almost anything. Bytes can be fetched from one part of a program and multiplied by bytes from another part of the program. The processor does not care that such an operation makes no sense. It looks only at bytes, not what the bytes represent.
These things do not happen in the AS/400. Instructions can work only on objects they are supposed to work on. Certain general instructions apply to all objects, such as the Create Object instruction discussed later in this chapter. Other instructions work only on specific types of objects. Thus, it is not possible to misuse an object on the AS/400 the way it is in a conventional system. The resulting integrity is greatly enhanced.
Another way to look at this is to note that, in most operating systems, anything in permanent storage is a file (in MS-DOS or MVS, a file is called a dataset). Files may have different uses, but the classification is largely conventional. You can read a program object as if it were a file. In OS/400, this is impossible (making one kind of virus impossible, at least above the MI), because the term file applies only to a small set of object types, and a program is definitely not a file. By the way, this caused some inconvenience in the System/38, because much of the information about objects was not available to programs. Numerous COMMON (an AS/400 user group) requirements were submitted to ask that all display commands (e.g., Display Output Queue (DSPOUTQ), Display Job Queue (DSPJOBQ)) have an option to produce an outfile, so that information buried inside objects could be read in a program. Rochester eventually provided this capability in some commands that did not originally have it (DSPOUTQ and DSPJOBQ still don’t). But Rochester’s comprehensive answer to the requests came in the form of APIs, extracted information about objects and system into a kind of space object known as a user space, which could then be read in programs more quickly than in database files.
| Previous | Table of Contents | Next |