| Previous | Table of Contents | Next |
Instead, this group looked at the APIs the most popular Unix application programs were currently using. Out of the thousands of Unix applications, they looked at 50 of the most popular and selected 1,179 APIs as the basis for a new standard they originally named SPEC1170. This name was later changed to Single Unix Specification, and this standard has now become the industry’s new definition for Unix. Among the APIs in this standard are some POSIX interfaces. New APIs continue to be added to this specification.
The obvious problem with all the API definition work was best described by someone at the National Institute of Standards and Technology (NIST) who said, “The nice thing about standards is there are so many to choose from.” With so many conflicting — and rapidly changing — standards, it has been nearly impossible for an application developer to create an application that is portable across all system platforms.3
3Later, in Chapter 11, we look at the Java programming language and its potential to at last create portable applications.
Further, these standards are not complete sets, meaning that in many cases an application may have to “go around” the APIs. Once this happens, the application becomes dependent on the underlying hardware and software. All the problems we saw in the processor-centric architectures re-appear the moment the software bypasses the API interface.
If, instead of just defining APIs for some specific set of applications (which is what an API-centric architecture such as the Single Unix Specification achieves), we create a formal definition of an API interface for all applications, then true hardware independence can be achieved. Further, if that interface definition is highly expandable, then additional APIs, such as those defined in the Single Unix Specification, can be added at any time to achieve application portability. This is the philosophy behind the AS/400 architecture, which defines a complete API set for all applications and never lets an application go around the APIs.
The Technology-Independent Machine Interface, which is usually just called MI,4 is the formal definition of the API interface for all application software and for most operating-system software. The hardware, along with all the operating-system software that must know the details of the hardware, is located below the MI boundary. We present the exact details of this structure in the following chapters.
4Recently, some have started to abbreviate the name of this interface as TIMI. I am not overly fond of the nickname “Timmy” (with apologies to anyone named Timothy), so I will use the older abbreviation of MI to describe the machine interface of the AS/400.
To understand how technology independence is achieved, we need to look briefly at how a compiler works. As we saw earlier, a compiler on a traditional, processor-centric system generates the binaries (the binary machine language) directly from the source code, sometimes going through an assembler step. In an AS/400, the compiler generates the MI code directly from the source code. This MI code is packaged into something we call a program template. In a second step, the AS/400 translator generates the binaries from the contents of the program template. The translator essentially performs the same function as the back end of a modern compiler does. Unless it is explicitly deleted, the program template is then saved along with the binaries in a program object. As long as the program template exists, the program is said to be observable. Whenever the program object is moved to a new hardware base, for example moving to 64-bit PowerPC, another translator built for the new hardware retranslates the program template into the binaries for the new hardware. No changes to the source program are needed, so we have technology independence. There is more to hardware independence than we have described here, but we will wait to give a more detailed description until Chapter 4.
The significance of this technology independence is immediately obvious to customers and ISVs alike. Upgrading to 64-bit RISC technology provides more than just a bigger processor. The operating system and all applications are immediately 64-bit software. There is no need to rewrite anything to take advantage of the 64-bit hardware. On day one, the RISC-based AS/400s had a 64-bit operating system and hundreds of thousands of 64-bit applications.
The architecture of the AS/400 has been called an advanced application architecture because it has achieved what many other computer systems are still struggling to achieve with API-centric designs. The AS/400 is already independent of its underlying technology. While it is very important to have independence from hardware, it is equally important to have independence from the details of the operating system. Again, the AS/400 has achieved this. The extendibility of the architecture means that newly defined APIs from other operating systems can be added, providing even more application portability.
“It’s in there; it’s all in there!” exclaims the TV commercial for a well-known brand of spaghetti sauce. Instead of buying the ingredients and making your own sauce, argues the narrator for this commercial, you simply can buy a jar of this spaghetti sauce and know that all the good, fresh ingredients you would use are already in there. Glenn Van Benschoten, the system product manager for the AS/400, likes to use the spaghetti sauce analogy when he is describing the integrated nature of the AS/400:Whatever you need for your AS/400, “It’s all in there.”
The AS/400 is an integrated system, and this characteristic sets the AS/400 apart from most other systems. Integration in a computer system means the various parts work together as a whole. The value of integration for a customer is that the system is easier to install, maintain, and use, which usually results in lower operational costs for a business.
If you were to ask a developer from Rochester why the AS/400 is a successful system, you would likely get the answer that Rochester knows how to build the best multiuser commercial systems. If you press a little harder and ask why, the developer will probably begin to compare specific features, such as the database or the security structure, with other systems. Yes, the AS/400 has a great database and a good security structure, but so do other systems. The value of the AS/400, which many of our developers either miss or take for granted, is that all components are designed to work together to provide a system that is greater than the sum of its parts.
| Previous | Table of Contents | Next |