Much has been made of IBM's apparent shift in marketing strategy for the iSeries. To many, it's seen as some form of capitulation, given the fact that WebSphere has a low adoption rate in the iSeries community. The flip side of that is that you need to qualify what "WebSphere" really means. Since IBM has literally branded everything related to development as WebSphere, the company is left open to attacks when any single WebSphere product is failing. For iSeries developers, WebSphere can be construed as belonging to one of several camps: WebSphere Development Studio Client (WDSc), the WebFacing tool within WDSc, the Java perspective within WDSc, or even the WebSphere Application Server itself. All four elements are targeted at completely different technical objectives, yet they have some kind of relationship/dependency on each other. Adding to the confusion are third-party vendors and competitive interests that seek to destroy the WebSphere initiative. While there's no question that the entire WebSphere offering has not succeeded on the iSeries, does that mean that anything that's related to WebSphere is bad?

You have to remember that WebSphere is just a name. So what's in a name? Plenty! WebSphere is IBM's brand, and it's in IBM's best interests for you to refer to "WebSphere development" instead of "Java development," particularly because Java is still Sun's property, not IBM's. While Microsoft was likely all too happy to let Sun struggle against its .NET initiative, it was less happy when IBM started using technologies like Eclipse to undermine areas where Microsoft has been strong, specifically in building a robust development environment. Today, one might look at the development landscape and have a hard time choosing a development strategy. If WebSphere is dead on the iSeries, should you consider Microsoft .NET or keep trying to stretch your RPG dollar?

Your first goal needs to be a change in mindset. To the dismay of some, categorizing something as "WebSphere on the iSeries" really doesn't make sense anymore. One of the realities of our community is that over the past 20 years, we iSeries loyalists have developed a bit of chip on our collective shoulders as we saw many technical feats released on other IBM platforms while the AS/400 was neglected or given the new feature later on as a sort of hand-me-down. We've become conditioned to looking for and reading about what's "on the iSeries" to the point that it's easy to miss the big picture. That picture is that the iSeries' best assets are its operating system and database. Like it or not, they really have nothing to do with the myriad RPG applications that have evolved here. If you can accept that fact and the fact that the demand for RPG applications has diminished in many of the vertical markets that made the AS/400 a success, then sit back and enjoy an article that shows where the iSeries belongs in today's market of server commoditization.

Many RPG advocates argue that RPG isn't dead; if anything, Java is dead! And from an iSeries-only perspective, they're right. RPG is still the dominant language executing on the iSeries. For many companies, RPG still makes sense and may not be replaced in our lifetimes. Unfortunately, IT decision-makers have a different mindset when it comes to purchasing or developing new applications. As the RPG talent pool grows smaller and demand for OO applications like Java or .NET increase, RPG jobs are simply harder to come by. So the question isn't whether Java or RPG is alive, dead, or somewhere in between. The question is what makes the most sense for your organization.

The amazing thing to me is that companies facing the issue of where to run Java applications are figuring this out for themselves. They're ferreting through the hype and picking the best tool for the job. That's why it's not uncommon to see Java applications running with WebSphere as their application server with a Windows database, for example. That company didn't read a vendor's vitriol about one particular ideology and then pour all the corporate resources into that one technology (although that happens). Rather, the company made conscious, intelligent choices about using the best tool for the job. As iSeries advocates, we need to start thinking that way because it makes the most sense and it guarantees the future of the platform. We can all continue to dress up RPG or IBM can enhance RPG so that it closely mirrors modern OO languages, but that strategy has no long-term future. It simply doesn't mesh with the buying habits of the IT decision-maker who doesn't have a preexisting bias toward the iSeries.

So we've come full circle to the WebSphere initiative again. Hopefully, I've made the point by now that this really isn't about WebSphere. If you want to choose the most popular development language beyond your iSeries-only scope, then Java is an excellent choice. I think it's fair to say that some iSeries advocates shudder at the thought of running a Java application on or off the iSeries. Common complaints are that Java is a "pig" or is too complex and that WebSphere is too complicated to manage. This is all starting to sound like a broken record, isn't it?

Well, Java can be a pig. For an iSeries site with just one programmer or two, supporting a Java application can also be a tough go. But let's not throw out the baby with the bathwater here. When properly configured, Java can run efficiently. We need to start thinking about how the iSeries can succeed in serving these kinds of applications instead of carting out the tired CGI vs. Java arguments.

Too often a project that potentially involves Java is seen as a threat instead of another way of proving the usefulness of the iSeries. Could the application be run elsewhere? Of course! In the end, the IT decision-maker will run the application where it makes the most sense. That doesn't mean the iSeries should have to be the weak sister and not host the application.

The iSeries Can Do It Better!

This is not a grandstand to run every Java application in the world on the iSeries. I think we all know that's not a reality. However, that doesn't mean that an application involving iSeries data should be run elsewhere, either. For all that RPG advocates make of Java's poor performance, little is made of the fact that DB2/400 has the world's best JDBC support of any database out there. That's right. Oracle, SQL Server, you name it--they all pale in comparison. Each non-iSeries database has its own pros and cons when it comes to JDBC support, but the iSeries supports the broad kind of data access you've come to expect when developing RPG.

Simply put, there is an enormous difference in the quality and functionality of the different JDBC drivers, even in drivers that access the same database. One of the biggest points to consider is the type of data access you're performing when writing a Java application. The JDBC specification provides for "updatable result sets" that provide enormous performance benefits whenever a file is opened, both for input and update/output (this is also referred to as an "internal" update). The flip side of this is that, most JDBC drivers allow an updatable result set only when the data is ordered. That means that replicating something like keyed access in RPG approximates the same degree of efficiency in Java only as long as it's run against DB2/400 directly. There are ways to do "external" updates that allow much of the same functionality, but that involves more coding and less efficiency. The table below shows the drivers and the feature sets that they support. These details change as time goes by, so this is based on recent testing and is not necessarily 100% accurate.

This is only one example, but it's a good one because it reminds us that the iSeries is not only an RPG application server, but also a flexible, efficient platform capable of hosting other applications. In this instance, the case can be made that you'll see better performance by running a newly proposed Java application on the iSeries than running it elsewhere.

The moral of the story is not to get caught up in terminology, but instead focus on picking your battles for running applications against the iSeries based on the inherent strengths of the platform. Even if the system becomes a data server only, that still means it was the best data server for the job, and that's not such a bad thing at all.

Chris Wilson (This email address is being protected from spambots. You need JavaScript enabled to view it.) is the Director of Software Tools for Advanced Systems Concepts, Inc. in Schaumburg, Ilinois. ASC's position on iSeries development tooling is to create ongoing iSeries extensions to its ABSTRACT application analysis tool, while helping companies migrate to Java with its RIO RPG-to-Java translation tool.