DB2 Is the Next Logical eServer Convergence

by Timothy Prickett Morgan

IBM has at three distinct relational databases sold under the umbrella name of DB2: one for OS/400 servers, one for mainframe servers, and another for Windows, Unix, and Linux servers. Having watched the eServer hardware platform consolidation, which could result in the mainframe merging into the Power server line in coming years, I'm wondering if DB2 is next. I think it's time for IBM to revisit its relational database past, and dig deeper into the first such software it ever sold: the integrated database in the System/38 and the AS/400.

When IBM launched the mainframe's relational database, back in June 1983, the name Data Base 2 was meant to signify a break with the flat-file database management systems on its mainframes--the very ones that made IBM a household name and tens of billions of dollars. DB2 was promised for deliveries in the third quarter of 1984, and it slipped into April 1985, to the embarrassment of Big Blue. Not only that, but it embodied a radically different programming environment, and one that ate through computing power like it was candy. With the advent of DB2 V2, in April 1988, IBM beefed up performance such that a six-way 3090-600E mainframe with 256 MB of main memory could process 186 transactions per second (TPS), a 51 percent increase over the prior DB2 1.3 release. Still, it took many more years for DB2 to become established on the mainframe, mainly because the cost of using this technology did not outweigh the benefits.

IBM jumped into the Unix market in February 1990, with the RS/6000 AIX-based servers, and it took the company until October 1993 to get a Unix variant of DB2 (then called DB2/6000) to market. By May 1995, OS/2 was established as a midrange platform, Windows NT was just getting rolling, and this DB2/6000 was ported to other Unixes (HP-UX, Solaris, and Sinix), as well as to Windows and OS/2. In 1997, with DB2 5, IBM merged the DB2 Universal Data Base 2.0 from its Unix and Windows platforms with the Unix-based DB2 Parallel Edition, and this UDB product has continued to evolve separately from the mainframe's DB2 ever since.

It's funny to think that such an integral part of the OS/400 platform didn't even have a name for so many years. That is, of course, one of the many brilliant aspects of the System/38 and then the follow-on AS/400 architecture: relational databases were cumbersome, complex, and only suitable to be installed by rocket scientists and to be used by propellerheads. But by launching the System/38, IBM became the first company to not only commercialize the relational database (Oracle was pretty fast on its heels in getting its eponymous database to market for IBM mainframes and VMS proprietary minicomputers) but also to make the relational database the file system of the machine. No one else has accomplished this second feat yet, and in fact, with the introduction of the Integrated File System in OS/400 V3R1, in the early 1990s, IBM went in the exact opposite direction, grafting the OS/400 database file system onto a variant of the OS/2 High Performance File System to create the IFS.

I was just a teenager in October 1978, when the System/38 was launched, and IBM made some (though not enough) noise about the relational database at the heart of Control Programming Facility (CPF). The reason is simple: the cost per MIPS on the System/38 was an order of magnitude higher than that for mainframes. In 1980, after the System/38 had been shipping for a while, it cost approximately $3 million per mainframe MIPS for a high-end box, while mainframes of that era (and using much less MIPS-hungry flat-file databases) cost about $300,000 per MIPS. It wasn't until the advent of the AS/400, in 1988, when relational computing on the AS/400 cost the same per unit of power as flat-file processing on the mainframe--around $100,000 per MIPS. The System/38 was a little too costly for lots of budgets, even if it did have single-level storage and could be programmed to do things that a mainframe could not. It was a technology that was ahead of its time, from an economic standpoint, and that relational database inside what became the OS/400 only became economically feasible with the AS/400.

As I look back on the early 1990s, it is with a certain kind of sad but sweet irony that this is also about the time that IBM decided to move away from rack-mounted midrange AS/400 servers and toward non-standard boxes that don't fit into racks. IBM was selling rack-based machines back in the 1980s, when Compaq didn't even exist, but Sun Microsystems, Compaq, Hewlett-Packard, Dell, and then IBM all jumped on the rack-mounted server bandwagon in 1997, and I can assure you, that market exploded, and now it is the dominant form factor. IBM went in exactly the wrong direction with the AS/400 in 1994, when it went to non-standard tower machines that could not be racked. It also went in the wrong direction by putting disk storage underneath the skins of the AS/400, which it did for competitive purposes to try to keep EMC and a few other players out of its lucrative disk array business for the OS/400 platform. The industry started moving in exactly the opposite direction with racks and external storage, in fact, toward the technologies embodied in earlier AS/400 generations. And I think that, eventually, history will show that the original concept behind the database we came to call DB2/400--an integrated relational database with the capability of managing all kinds of objects in a more useful way than a file system--will prove to have been the right idea.

The early 1990s, when these development decisions were made for the OS/400 platform, was a tough time for the minicomputer business in general and for IBM in particular. IBM had been hemorrhaging red ink for years. There was a worldwide recession, too. IBM had started the PowerPC alliance with Motorola and Apple and was gutting AS/400 and RS/6000 server product roadmaps to get these machines on a convergence path that would be fully realized a decade later with the Power4-based servers. Being on the outside of IBM, it's hard to say why decisions get made. I know that out in the real world at this time, the whole idea of client/server computing was becoming established and, eventually, with the advent of Windows NT in the mid-1990s, OS/400 had to learn to deal with new data and file types. Storing PC-style data within OS/400 required a lot of computing oomph, and it was very costly, compared with grafting a PC-style file system onto OS/400. Rather than figuring out how to build a better mouse trap (by improving the performance of the database handling PC objects, perhaps using specialized I/O and database co-processors), IBM just chucked out the whole idea of a using a database woven tightly with the operating system as its main file system. If I had to guess--and I do have to guess--this was a decision made by management, based on short-term gains and product positioning, not long term vision. In other words, I would lay blame IBM Somers, not IBM Rochester.

How sad, how ironic, that this is exactly what Microsoft is trying to do with its future Windows server version (once it was called "Blackcomb," but Microsoft has cut back on the feature set and calls it "Longhorn") and the promised WinFS file system. So what is Microsoft trying to do with Windows and WinFS? You've got to laugh: it is trying to move away from the NTFS file system at the heart of Windows (which closely resembles the OS/2 HPFS at the heart of OS/400's IFS) and toward a file system that uses SQL Server as a data store for all information on the system.

If Microsoft succeeds in this effort, what the .NET-Windows environment will eventually be is a different implementation of the ideas embodied in the original System/38 and AS/400. I have no doubt Microsoft will figure this out, but I do know that it does not have the deep expertise in enterprise databases and enterprise operating systems that would allow it to get it right the first or second time. The third time's a charm for Microsoft, so that probably means whatever Windows that it can deliver in 2008, 2009, or 2010.

Part of my job (at least in my opinion) is to ponder the possibilities of how computing technology can be mixed and morphed into something new (or revert to something old and better). It was with this intention that I asked Jim Herring, the director of product management and business operations for the iSeries line, and his predecessor, John Reed, about the possibility of merging IBM's DB2 databases and getting down to a single database that supports mainframe, OS/400, Unix, Windows, and Linux platforms. When I asked the question, what I asked was if IBM had thought about converging DB2 to cut costs, much as it has done with Power-based hardware. And they said that IBM had, in fact, considered porting DB2 UDB for Unix and Windows to within OS/400 five years ago. I had heard such a thing, and it is a logical thing to ponder. But the data formats are slightly different, as are the interfaces to programs. That means companies would have to tweak and recompile their databases and their applications if IBM did this. So IBM scotched the idea.

What the company has done instead is to move features that are developed from one DB2 into the others. For instance, in a future OS/400 release, a feature called materialized query tables will be moved from DB2 UDB to DB2/400. (Yes, I still call it DB2/400, not DB2 UDB for OS/400, since the database inside OS/400 has very little to do with DB2 UDB.) Some features that sped up indexing were moved from DB2/400 to DB2 UDB a few years back. And to try to make it all look consistent from the outside, IBM has, to its credit, tried to get consistent management interfaces across all three DB2s.

This is all well and good, but it won't help when Windows 2009 and WinFS are available. IBM still has control over its operating systems and its databases, and it might make sense to get back to the future. Systems have so much excess computing power, and we have so much excess bandwidth, that the approach that IBM had with the AS/400 (using the integrated relational database as the file system for all applications) is economically and technically feasible. And while I admit that it may not make sense to converge the three DB2s together to create a single product, because of the disruptions to customers, it may be time to reexamine the convergence of the operating system and the database on the OS/400, AIX, MVS, and Linux platforms where IBM can do this. It was a good idea in 1988, but server processing capacity was too small and too expensive, which is why the DB2/400 database was ripped out of OS/400 and dropped alongside the IFS. Converging operating systems and DB2s will be a great idea in 2008, especially if IBM beats Microsoft to the punch.

One last thing. If IBM can get the Windows, Unix, Linux, and MVS bases to move to OS/400 with its integrated DB2/400 acting as the one and only file system, that would be even better!