Data Capabilities

Because I described most of the data capabilities extensively in Chapter 6, my discussion of this investment area is brief. I have included this section because IBM’s efforts to enhance the AS/400’s data capabilities are among its highest-priority investments.

In Chapter 6, I said that a great untapped resource for many businesses is their operational data. As many businesses begin to understand that this data may be their most valuable asset, they are looking to their AS/400s to unlock the business intelligence in their data. After all, data is just a commodity; knowledge, on the other hand, offers the business a competitive advantage. So it is no wonder that data warehousing and data mining are among the fastest growing applications in business computing.

The most common implementation for a data warehouse — or even for a data mart, which is essentially a small data warehouse customized for a specific workgroup — is to use separate servers. The AS/400 faces tremendous competition from other vendors vying to put their respective systems and other databases into these configurations. Often, the decision of which system to use depends on the database’s capabilities. IBM’s goal for this investment area is to make sure the AS/400 continues to have a world-class database in this highly competitive environment.

The range the DB2/400 database covers also is extremely broad. At one end of the spectrum is the AS/400e entry server that competes directly with PC servers and their PC databases. At the other extreme is an MPP configuration with up to 32 systems in a cluster connected via OptiConnect. With each of these systems capable of connecting one or more terabytes of disk, the total database size is beyond anything that was imaginable just a few years ago.

A key area of IBM’s focus for DB2/400 in the near term is to maintain and improve database performance, especially SQL performance, across the entire system range, to ensure that performance remains competitive. The native interface to DB2/400 has usually enjoyed a performance edge over the SQL interface, but with more and more applications written to the SQL interface, that performance must be enhanced.

Another challenge facing DB2/400 (and every other database, for that matter) is how to deal with complex data types such as objects. As we move into an era of distributed object computing, the database will be called upon to handle these abstract data types. Although it is highly unlikely that any major database vendor will abandon a relational database model in favor of a full OO database before the turn of the century, new requirements certainly will be placed on current databases. While there are still no accepted standards in this area, organizations such as OMG are making proposals about how objects or components of an object can be stored in a relational database but accessed through an object database management system. IBM also has been looking at similar proposals for possible extensions to DB2 databases. If accepted, these extensions will be implemented in DB2/400.

DB2/400 will continue to be the backbone for AS/400 applications through Version 4. Functional enhancements and performance improvements will be made for AS/400 databases both large and small. Very large databases will be possible as the AS/400 experiences tremendous growth over the next couple of years.

High-End Growth for the AS/400e series

Performance and capacity growth will enable the development of the new software technologies we have been discussing in this chapter. At the same time, this growth will cost far less than it did in the past. In this and the following section, I describe the two major hardware initiatives for the AS/400e series to greatly expand the high end of the product line and to reduce the hardware costs for all systems.

High-end growth became a major focus area for the AS/400 in the early 1990s. Too many of our large customers were “hitting the ceiling” with their AS/400s. Their performance and capacity requirements exceeded what we could deliver. A primary reason for our move to PowerPC was to overcome these early performance restrictions in the AS/400. With the introduction of the RISC-based AS/400s, we were able to satisfy the requirements of those large customers with new high-end systems. But the demand for even more capacity and better performance has not diminished. New application models, as well as high-end customer growth, are continuing to push the AS/400’s performance envelope. We are responding to that demand with incredible growth in our AS/400e series. In this section, we look at two approaches to achieve this high-end growth: single systems and clusters.

The RISC Processor and How It Will Grow

I have always believed that you can never have too much horsepower in your car or too much processing power in your computer. Earlier, I mentioned that I drive racing cars. Even the car I use as my daily driver has 300 horsepower inside its Northstar (a name I have always liked) engine. I don’t often need that much power just to drive to my office at IBM, but it sure is great sport to “tickle those ponies” once in a while to make sure they are all awake. Just as I like powerful cars, I like powerful computers. My home PC has dual Pentium Pro processors. The difference between powerful cars and powerful computers is a matter of sporting fun versus business necessity. Business needs and the applications that serve them have been growing the demand for increased processing power in our computers for many years. Thus, with the introduction of the e-series, we increased the processing power of the AS/400 by nearly five times. That need for more compute power will continue into the future, and we plan to satisfy that need with even more powerful AS/400e systems and servers.

Several years ago, processor performance for the System/38 and the early models of the AS/400 was not considered critical. We used to joke that Pacific, the code name for the System/38, was an acronym for “Performance Ain’t Critical if Function Is Complete.” We consciously traded performance for function, knowing that eventually technology would bail us out of any performance problems. Our decision was correct; today we have both the function and the performance.

These early systems also were used predominantly for interactive processing applications, where processor performance is far less important than I/O performance. In Chapter 10, we saw how the AS/400 has been optimized over the years to have outstanding I/O performance.