The AS/400 is dead, the iSeries is dying, and before long, so will OS/400 and i5/OS be dead.

We have been hearing this dreck for years, and this prediction has yet to come to pass. You do have to wonder though if it isn't a realistic possibility, given IBM's latest moves toward services and away from hardware (like the recent PC division sale) and the dwindling financial performance from the midrange division. But I can't help believing that the recent design changes that have resulted in the convergence of the alphabetSeries boxes into the i5 line adds longevity to the OS/400-for-i5 variant. But what if the doomsayers are correct? What if the demise of our beloved box is all but certain? Let's look at the core function of OS/400--its rock-solid database DB2--and examine potential exit strategies should the unimaginable occur.

Plain Vanilla

If you are a regular reader of my column, then you know I'm an advocate of open-source products and even more an advocate of open standards. One of the biggest reasons for this is because I detest the concept of vendor lock-in. By choosing products that use open standards and by designing my software to conform to open standards, I minimize the risk that any one vendor can dictate the terms and conditions under which I use its software. If everything has been designed using open standards, then jumping ship to another vendor is fairly straightforward.

For a database management system (DBMS), the measure of its standards-compliance is its conformance to the Structured Query Language (SQL) standard (currently SQL:2003) published by the International Standards Organization (ISO) and the American National Standards Institute (ANSI). If you examine the documentation of any DBMS, such as the commercial products IBM DB2, Microsoft SQL Server or Oracle, or the open-source products PostgreSQL, MySQL, and Firebird, you will find the product's claimed conformance to a given SQL version. (Recent versions include SQL-92, SQL-99, and SQL:2003. Each version is upward-compatible with its predecessor).

In theory, any software written to use a given SQL version should be able to use for its back-end any DBMS that conforms to the same or later SQL version. This requires that the programmers of said software limit themselves to the standard SQL data types, standard SQL data description language (DDL), and standard SQL data manipulation language (DML) defined in the SQL version.

So much for theory. In practice, it is unlikely that you will ever find a programmer who isn't tempted by one or more of the extensions grafted onto standard SQL by the designers of the DBMS he or she is using. Why do the vendors add those extensions? If you substitute the word "standard" with the word "generic," you quickly gain insight into the reason. For the most part, generic software doesn't take advantage of operating system features or hardware, since both of those assets can vary wildly from system to system. Since the name of the game with a DBMS is performance and data integrity, it's a foregone conclusion that the DBMS architect will add anything to enhance either or both attribute.

And then there is the marketing: Features help differentiate one DBMS product from another. Anything that makes it easier for programmers to write reliable software or for database administrators to manage the system also makes for good bullet points in the marketing brochure. Thus, DBMS providers have plenty of motivation to embellish the standard to keep up with their competitors.

The problem is that when you start using those enhancements in your programs, you become dependent on them, trading off some of your DBMS independence. Because all DBMSs have unique extensions too compelling to avoid, the likelihood that you'll ever find software that isn't in some way tied to a specific DBMS is remote. If you are using canned software, it is likely that you are stuck using whatever DBMS the software vendor dictates. (I find myself in that unfortunate circumstance right now with some software we currently use, where the DBMS isn't DB2 and the DBMS employed doesn't seem to be as wise as its name would imply.) If you are using DB2 on the iSeries and have written your own software (or have the source code), there are some interesting options.

Some Basic Assumptions

Based on my conversations with other i5 users, I have come to the conclusion that the vast majority of the applications currently in use do not use the esoteric DB2 data types (such as data links). They are simply straightforward business applications. Furthermore, most of the applications are written in RPG (and a smattering of COBOL), further limiting the data types to those defined within standard SQL. This leads to the desirable situation where migration from DB2 on the i5 to another DBMS isn't all that difficult. In a nutshell, you would need to recreate your database(s) on the target system (including the appropriate permissions) and then migrate the data from the i5 to the target. IBM provides tools that make this a straightforward process. With iSeries Navigator, you have the tools necessary to generate the SQL DDL for your schemas, which you should be able to use to duplicate the structures on the target system. If you have no other way to move the data from the i5, you can always use the unsophisticated CPYTOIMPF command to get the data into a form that you can presumably use to import it into your new DBMS.

This task isn't as onerous as it sounds, particularly if you have limited yourself to standard SQL in your software development. I have used this technique many times to move databases from DB2 to the superb open-source database PostgreSQL with good success. I have also used this technique to migrate databases from PostgreSQL to DB2 for use on my iSeries, another surprisingly easy task.

The complexity of database migration is directly proportional to the number of DB2 enhancements that you have in your DB schema. Whereas the DDL for creating the database is easily moved from DBMS to DBMS, the language for creating constraints, triggers, and extensions can vary, creating headaches during the transition. The easiest way to get an idea of the work involved is to fire up iSeries Navigator and generate the SQL from any schema. Take the output from that and feed it into a different DBMS, like PostgreSQL, and see what errors are produced. You're likely to see errors that include unknown data types (if you have used any DB2 custom types) and other errors caused by variations in the syntax of the SQL from DB2 to the target. The more you have stayed with standard SQL in your original design, the less editing the resulting SQL will require for use on the new platform and, therefore, the simpler the migration.

True Blue DB2

The easiest migration of an i5 DB2 database is, of course, from one i5 to another. It's usually nothing more than a save-and-restore operation. The next easiest migration is from DB2 on one platform to DB2 on another platform. And in that category of migration, IBM has come through in spades! IBM has ported DB2 to virtually every conceivable platform--from PDA-sized devices to the big iron zSeries.

Of course, I'm most interested in DB2 running on Linux. A year or so ago, I tried it and found that it worked fairly well. The installation, however, was somewhat convoluted and troublesome, mostly due to the differences in the various Linux distributions. Now that Red Hat and SuSE are offering "Enterprise"-level distributions, IBM has an easy target for which to write their installation scripts.

You can easily and cheaply try this out at home. All you need is a PC with at least 256 MB of RAM and sufficient disk space, and you're good to go. (I can't give you a solid idea of what constitutes sufficient disk space because of the variations in package selection you may make during installation. I can say that 20 GB is more than enough to install everything.) Given that you can easily buy a PC that meets those specifications for under $400 nowadays, you won't break the bank building a development machine. My desktop machine is a two-year-old, dual AMD MP machine with 1GB of RAM and SCSI drives, so even though it doesn't measure up to the machines available now, it's no slouch either.

For the Linux distribution, I suggest that you use the Red Hat Enterprise Linux (RHEL) clone called CentOS, which is simply a recompilation of the source that Red Hat created for its RHEL, sans trademarked items such as icons and other graphics. It's kept up-to-date with Red Hat's errata and really is as close as you can get to RHEL without actually subscribing to Red Hat Network. The installation of CentOS is very simple. (You can find the docs on the CentOS site, but it's as easy as insert CD, boot CD, select Server Install, and answer a few prompts.) Although I haven't used it, there is a one-CD installation CD of CentOS that provides server-only capability. That one should be all you would need to get.

IBM allows you to download a copy of its DB2 v8.2 development edition for free. It's a huge download (around 500 MB), and all you need to do is be a registered user on the IBM site. I imagine that most readers of this column already are, but if not, registration is free. Once I had CentOS installed and updated, I surfed to IBM's site and downloaded the installer. It comes as a zipped tar file, so a simple tar -xzf DB2ExE82_Linux.tar.gz command provided me with a directory called simply "Linux." Within that directory were all of the installation files and documentation. Earlier, I said that I had tried DB2 for Linux once before and found the installation convoluted and challenging. What a difference a year makes!

Originally, I intended for this article to be about how to install DB2 on Linux, but once I actually did an install with this new version, I realized that such an article would be about one paragraph long. All I needed to do was change to the Linux directory and issue the command ./db2setup. The installation program walked me through the entire process, creating the necessary Linux users and groups required for the software to function properly. Literally within 15 minutes I had a working instance of DB2 on my Linux system. Now the task of i5-to-Linux migration is even easier, since DB2 on each system is compatible. The quick tests I did on my newly installed system showed that I could easily move DDL between my Linux and iSeries machine and have it function properly. Very nice!

Too Simplistic

Obviously, it's rather simplistic to assume that the only task of migrating from an iSeries is moving the database. That task is probably the least difficult thing to do. While the data is important, so is all of that RPG and COBOL code that actually works on your data to produce something meaningful. If you have been keeping your coding standards to current levels, then you are undoubtedly using service programs, stored procedures, and all of those other niceties that OS/400 provides. What do we do about them?

Gazing into my crystal ball, I don't see IBM killing OS/400 in the near future. I have yet to see any DBMS on any machine exhibit the robust, easily managed behavior that DB2 does running on OS/400 or i5/OS. Even if the box eventually goes away, I'm sure that IBM will provide some kind of migration path to keep your software investment safe. They have been doing that since the days of the System/38, and I have had no problems moving my software through all of the architecture upgrades thus far. If IBM were to force such a migration from OS/400, can you guess where the likely destination would be? Given IBM's recent investments in Linux, I think that OS would be a likely candidate.

If you accept the premise that IBM won't be killing OS/400 anytime soon, then why would you even be interested in DB2 on another platform? Good question.

What about using a Linux machine as a development platform for your Web-based applications? You may not always have an i5 around on which to do development, but you can certainly do quite a bit on a laptop or desktop machine--be it one running open-source Linux or a proprietary OS. This is especially true if you are using Java more and RPG less, like many are starting to do.

What about your Web application servers? Sure, the i5 can perform those functions very well, but if you are doing a proof-of-concept project, you may not have money budgeted for an i5. If that's the case, perhaps you can press into service one of those inexpensive PCs, at least until management decides to fund your project properly.

Finally, I'm always watching the technologies that are being moved to Linux. Experimenting with them is extremely inexpensive to do, and I believe that doing so gives you a less OS-centric/DBMS-centric view when designing software. This makes your software designs more agile and may help you later, when the unthinkable comes to pass. Pass the Tums!

Barry L. Kline is a consultant and has been developing software on various DEC and IBM midrange platforms for over 21 years. Barry discovered Linux back in the days when it was necessary to download diskette images and source code from the Internet. Since then, he has installed Linux on hundreds of machines, where it functions as servers and workstations in iSeries and Windows networks. He co-authored the book Understanding Linux Web Hosting with Don Denoncourt. Barry can be reached at blkline@attglobal.net.