So Windows NT could run on different hardware platforms, Microsoft defined what it called a hardware abstraction layer (HAL). HAL is a layer of code designed to protect the kernel of the operating system from platform-specific hardware differences. For example, HAL hides hardware-dependent details such as I/O interfaces, interrupt controllers, and multiprocessor communications mechanisms. Rather than accessing the hardware directly, NT calls HAL routines when it needs platform-dependent information.

Conceptually, HAL is similar to the MI but at a much lower level. Because a great deal of processor-specific code is still in the kernel, Windows NT is not hardware independent. Likewise, NT applications are not hardware independent, because they compile directly to the binaries of the specific processor. HAL does, however, allow for some additional integration between the NT application processor and the AS/400.

A new HAL, which allows devices to be shared and commands to be passed from one side to the other without a need to change NT, was created for the NT application processor. For example, rather than interrupting NT when an error occurs, the new HAL lets the errors be passed into the AS/400 for handling. Either the AS/400 side or the NT side can accomplish other administration and control functions.

The NT file system (NTFS) runs in an OS/400 byte space. Initially, only NT sees the individual files. At some point, NTFS could be integrated into the IFS, or some other mechanism could be used to make the files visible to the AS/400. Until then, ODBC can be used between the two server operating systems.

AS/400 e-server Models

We knew early in the 1990s that we could transform the AS/400 into a world-class server. We had an architecture that let us move into a full server environment without walking away from our traditional customers, most of whom were still using the AS/400 as a host-centric system. Our customers told us they wanted to evolve to client/server computing, but they didn’t want to disrupt their business to do so. This was not a problem for the AS/400. We did, however, have an image problem with much of the industry.

You see, most other minicomputer vendors also had decided to become server vendors, but they had a real problem. They could not transform their existing minicomputers into servers, and they had to abandon them. Just about every one of these vendors replaced their host-based systems with a new system, which usually ran a Unix operating system. Similarly, these vendors told their customers that if they wanted to move to client/server computing, they would have to walk away from their existing systems and move to the new system, which usually meant they also would have to convert or rebuy all their applications to use the new system.

Consequently, the computer industry would not believe we could turn an existing AS/400 into a server; so we decided to create some new server models to show we were serious about this market. This was not totally a marketing ploy, but it did give us the chance to optimize these models for better cost/performance on a server workload.

In September 1993, we introduced our first server models as part of the original AS/400 family. We announced the AS/400 Advanced Server models in May 1994; this original server family included two models, which covered the middle to the low end of the AS/400 market. In June 1995, we announced three new server models to cover the complete AS/400 range. We needed to optimize the performance of these servers for three functions:

•  Database serving

•  Communications serving

•  Batch processing

All these functions are more compute-intensive than interactive processing is. For a given server model, we needed more performance than the equivalent traditional model used for interactive processing. To accomplish this, we originally took some of the higher-performance IMPI processors out of the larger traditional models and repackaged them into the smaller server models. For example, we took the processor from our large rack-mounted F70 model introduced in 1993 and packaged either one or two of these processors in our smaller deskside package to create the first server models, the 135 and 140, respectively. We also ensured that these models had sufficient memory, disk capacity, and LAN connections to support the large processors in a server environment.

The higher-performance processors greatly improved the performance of server applications compared to the equivalent traditional models. The performance for network, database, file serving, and compiling operations also improved. With the introduction of the RISC processors, which had much higher performance than their IMPI predecessors, we found that we could use the same processors in our servers and our traditional systems.

Because the server models are not intended for interactive computing, the performance of traditional interactive applications, such as those using 5250 workstations, is de-tuned on these server models. The number of interactive workstations that can be attached to a server model is also restricted.

Customers who have both interactive and client/server applications can achieve the same level of server performance as they can with the server models by using a traditional model with one of the higher-performance processors. The traditional models have no restrictions for either interactive or server applications. The server models are special-purpose systems designed to improve server performance at a lower cost. For a client/server workload, the cost of a server model for a given level of performance will be lower than the cost of a traditional model.

The server models of the AS/400 have been so popular that with the e-series we decided to expand the range and even the type of e-servers we offer. One reason for offering new types of servers relates to changes occurring in certain business partner applications. For example, many newer business partner applications have moved to a multi-tier client/server software architecture. A three-tier architecture might have PC clients attached to one or more dedicated application servers, which in turn are attached to dedicated database servers. The server at each tier in this structure has slightly different requirements. So we now have compute-intensive application server models specifically configured for a particular business partner’s application. Look for even more specific e-server models as the AS/400 expands into new business environments.