Supercomputers have used this technique of synchronizing the spinning disks in an array for years to achieve high-performance data transfers into and out of the systems. The downside of this approach is that the array appears to the system to have only a single arm. Over the years, AS/400 systems have been shown to perform better when lots of disk arms are used. Reducing the number of arms reduces the number of parallel disk accesses that can occur, thereby potentially reducing the overall system performance. As the cost of these disk arrays comes down, so that many of them can be attached to a system, this may be a way to improve system performance without having to wait for mechanical performance improvements.

In Chapter 8, we saw that one of the advantages of the single-level store was that no application or operating-system software above the MI even knows about disk drives. Part of the reason for hiding the disks was the thought that someday this mechanical technology would be replaced by something else. Semiconductor disks (large semiconductor memories with battery backup) may provide one such possibility, but there are others.

Let’s now turn our attention to some of the software technologies that will take the AS/400 into the future.

Future AS/400 Software Technologies

Hardware technologies are governed by the laws of physics, so the future is fairly predictable. We can look at the work going on in various research laboratories around the world and identify with reasonable certainty when the hardware technologies being studied will be ready for commercial use. We can’t say the same for software. The laws of business govern software technologies — businesses have huge investments in their current applications, software development tools, and user training. To believe that radical changes can be made to all that application and development software in just a few years is unrealistic; it will not happen.

Look, for example, at the work being done on OO databases. Computer journals regularly report on some university or research organization’s new developments or new implementations of OO databases. Obviously, we can build very sophisticated OO databases today, but few businesses are willing or able to abandon their current relational databases in favor of something new. So as I discussed in Chapter 11, we can expect to see objects included within relational databases and accessed through an object database management system.

My point here is that while we might expect to see revolutionary hardware changes in the next 5 to 10 years, the software changes will be far more evolutionary. Purists will argue that evolutionary changes are not as good — that sometimes we must turn our backs on the old technology to realize the biggest advantage from a new technology. But of course, purists rarely run businesses.

Operating Systems

I began the Preface with a discussion of how our most modern operating systems are reincarnations of work done in the 1960s. That pattern is not likely to change soon, no matter how much the vendors tell us about the great innovations they are planning for some “new” operating system. Operating-system technology will be slow to evolve. By the year 2001, we should expect to still be living with today’s operating systems. Some of them will be enhanced, and others will go away, but the fundamental structure of the operating systems we will be using will remain unchanged.

Increases in hardware capacity and performance will keep most operating-system developers busy eliminating the limitations in their current designs. Rewriting a major part of the operating system to take advantage of 64-bit processors will keep Unix developers busy for the next few years. The 32-bit PC operating system vendors probably will not even bother to go to a full 64-bit implementation, other than to utilize a 64-bit address, until after 2001.

Similarly, OS/400 will not likely see major changes; enhancements will be the order of the day. Most of the changes we can expect to see in OS/400 will be those to support the new functions and features we have already discussed. In the early 1990s, IBM rewrote SLIC, which provides the base operating-system functions for the AS/400, to take advantage of the anticipated future growth in hardware capacity and performance. So OS/400 has a strong base on which to build for the future.

Global File Systems

One area of particular interest to me is file systems that support direct network-attached storage. As we begin to share disks among multiple systems in a network, being able to deliver data across that network with very high data rates becomes increasingly important. Engineers are good at quoting the peak data rates in megabytes per second (MB/sec) for the hardware alone. Peak data rates assume that infinite-sized files are being transferred with no software overhead. In the real world, file sizes are small and the file system includes lots of software overhead. Thus, the actual data rates are generally far below the peak the hardware could achieve.

Consider a simple example of two AS/400 RISC systems connected with OptiConnect over a fiber-optic SPD bus. The fiber is capable of transferring data at a peak rate of 1 GB/sec, which is approximately 100 MB/sec, assuming a few bits for error detection. Measurements show that the actual data-transfer rate between the two systems is more like 32 MB/sec, or about one-third of the peak rate. (I should note that being able to achieve a sustained data rate of 32 MB/sec across an SPD bus is still very good.) The reason for the data rate reduction is the software overhead involved. For each data transfer, the operating system software must execute a sequence of instructions. In Chapter 10, we looked at the SPD bus and the functions that must be performed in SLIC to accomplish an I/O operation. The SAN will be used for interconnections in the future, because it has a higher peak data rate and requires less software overhead.

For a file system where we are sharing disks between two or more systems, we have to add the disk seek-time overhead to the file-system software overhead for each transfer. We also must consider the size of the file being transferred, because approximately the same overhead is involved independent of the file size. This means that small files will have significantly lower transfer rates than large files. For example, a Sun Microsystems’ Network File System (NFS) running on typical high-performance Unix workstations can transfer 10 MB files at about 2 MB/sec and 40 MB files at about 6 MB/sec.