"For a list of all the ways technology has failed to improve the quality of life, please press three."
--Alice Kahn

This month at MC Mag Online, we're talking about failure--or more precisely, preventing failure. And since I spend a lot of time talking about WebSphere and new user interface strategies, I think this month's quote is particularly apropos. Just because you can do something doesn't mean you should, and the cheapest answer isn't always the best answer. Automated answering services with five levels of menus and no fast path are perhaps the most obvious example of misplaced technology, but other things do come to mind.

For me, Windows server farms are a perfect example. Replacing a single iSeries with dozens of Windows machines "because they're cheaper" completely flies in the face of not only my own personal experience, but also that of the major consulting groups. Companies like IDC and Gartner have both recently reaffirmed the longstanding fact that the iSeries is a leader in total cost of ownership (TCO), online transaction processing (OLTP), and enterprise resource planning (ERP), eclipsed only by the venerable zSeries and occasionally a hugely expensive HP solution at about four times the price per transaction.

This is not to say that the iSeries is without weakness. The iSeries doesn't fare so well in certain areas. Native GUI and high availability (HA) are two of the iSeries' traditional sticking points. Since we're focusing on HA this month and HA is a crucial factor when companies make platform deployment decisions, this is a good time to address the entire iSeries deployment issue as a whole. So, today I will talk about...

1. The strengths of the iSeries
2. The weaknesses of the iSeries
3. WebSphere ND and how it addresses those weaknesses

Also, I have some notes regarding the pricing of the advanced edition of WDSc, as well as a couple of reports from the field on WDSc issues.

Strengths of the iSeries

As I mentioned, the iSeries has years of studies to prove that it beats just about every machine out there for OLTP/ERP processing and that the iSeries TCO is second to none. These are facts--facts that you should know, facts that are backed up by independent consulting companies, and facts that you should present to your management every chance you get.

Some of this information, such as IDC's TCO report, is available from an IBM Web site called Making the case for iSeries. This page is part of the iSeries Nation, a resource you might want to take advantage of, especially when the perennial "Why the iSeries?" question comes up. A little two-pager addresses exactly that question. The site also offers the 2001 version of Gartner's OLTP/ERP study. While IBM has only that older version, if you're quick, you may be able to see the 2003 version of the same study on the Gartner site before it becomes unavailable. The newer version basically continues the tradition: The only thing that beats the iSeries is another eServer (with the exception of the $8 million HP Superdome). And the only reason the iSeries loses at all is because of something called "market momentum," meaning that IBM doesn't advertise it, ISVs don't push it, and nobody knows about it. IBM may tell you that television commercials won't sell iSeries, but I think they're dead wrong. Microsoft and Dell have been playing the TV card for a long time, and IBM does it for its other servers, so it's high time the iSeries gets the same benefit. With market momentum, the iSeries would be unbeatable.

Here's an interesting point about the Gartner study: It says there's a shortage of iSeries programmers, and that's a contributing factor to the machine's low score. You and I know this to be grossly incorrect, and if we factored in the current high availability of RPG programmers, the iSeries would top everything but the zServer.

Weaknesses of the iSeries

People can find weaknesses about anything. When those issues come up about iSeries, you have to be able to address them. The good news is that as an iSeries advocate, you can do just that. For example, three primary issues always come up:

1. The iSeries is an outdated, proprietary architecture.
2. There is no integrated GUI.
3. An iSeries is a single point of failure.

Outdated? Proprietary? Not!

The first argument is one we've been hearing forever, and as time goes on, it's becoming less powerful. Microsoft has a vendetta against both Linux and the Java language, and it's clear that the Microsoft operating system is every bit as proprietary as OS/400. And while the .NET initiative may someday provide as much language interoperability as is already available in ILE, there is no better platform today for integrating multiple technologies than the iSeries. As IBM embraces open standards such as Java and Linux and Eclipse while Microsoft continues to turn inward and create Microsoft-only versions of everything, it seems to me that in the not-too-distant future, the iSeries will be seen as the open platform while Microsoft remains proprietary.

GUI? We Don't Need No Stinkin' GUI!

So that brings me to the two relevant issues: lack of GUI and single point of failure. It's true that IBM has never come up with a native GUI for the iSeries. Personally, I don't have a problem with that. Let's look at it from an ROI perspective: The cost of CPU cycles on the iSeries is and will always be much higher than the cost of the cycles on the desktop. That's the nature of distributed computing. The desktop workstation is a commodity with a lot less baggage: The requirements for security, backup, multi-user support, communications, and so on are so much less for the workstation that it can afford to have what is in effect a dedicated processor for each user, whereas in the case of the server, even in a multiple-CPU configuration, each CPU has to service dozens or even hundreds of users.

The single most CPU-intensive activity in today's business environment is displaying graphics. Calculating the individual colors of millions of pixels on the screens as the user whips a mouse around requires a whole lot of CPU cycles. To me, this is precisely the kind of workload that should be distributed to the end user. In fact, that's always been the case. Back in the olden days, the 5250 terminal did most of the work of formatting the data and communicating with the end user; the host simply had to use the 5250 protocol to talk to the terminal, and the terminal did the rest. That's why the architecture was so powerful. Today, we can take advantage of a similar sort of distributed effort by using HTML to talk to browsers on the workstation. The browser does all the work of taking that standard HTML protocol and rendering it as a GUI.

The other option is the thick client, and while thick client applications are a necessity for certain users, such applications are rarely in direct communication with the host. Instead, the thick client usually talks to the host in short bursts. And in either interface, thick or thin, none of the graphic rendering is performed by the host. So, to me, the lack of a native GUI is not a shortcoming for the iSeries, but rather a smart architectural design decision, provided we can support thick and thin clients on the workstation using some easily programmed and readily recognized standard protocol.

Single Point of Failure

Single point of failure is a serious issue. Over the years, two basic styles of failure prevention have arisen: clustering a few redundant copies of expensive servers or hooking up dozens of cheap commodity boxes. But with the exception of a few specialized vendors, HA has not been the domain of iSeries shops. We've traditionally relied on our ability to have better than 99% uptime (99.98% scheduled uptime according to the IDC report) to avoid issues of availability. But in today's world of 24x7 requirements, we can avoid this issue no longer. A couple of recent bad experiences in the hardware arena (remember those 8 GB disk drives?) have made it painfully clear that the iSeries is not infallible, and the rapid pace of change in the operating system has led to similar incidents on that side of the platform. If you have only one iSeries running your application, any downtime is corporate downtime, and in today's global economy, downtime costs money.

Enter WebSphere Application Server Network Deployment

"WebSphere Application Server Network Deployment: A J2EE and Web services Web application server with advanced deployment services that include clustering, edge-of-network services, and high availability for distributed configurations."

That's IBM's nutshell description of WebSphere Application Server (WAS) Network Deployment, or just "ND" to us in the field. If we're referring to a specific version of the product, we might say WAS51ND, which is WebSphere Application Server Version 5.1 Network Deployment. ND addresses both the GUI and the HA issues of the iSeries.

Getting GUI

From a user interface standpoint, ND is like any other product in the WAS line, with full support for servlets and JavaServer Pages (JSPs) according to the J2EE standard. Version 5.1 supports all the latest open standards, including Version 1.4 of the Java SDK. This commitment to the Java platform is going to be even more significant as future releases of the SDK add significant enhancements to the language. And what it means today is that you can write iSeries applications that can communicate with any desktop on the planet--Windows, UNIX, Linux, Macintosh--with no software required other than a standard browser. And any J2EE application can be deployed on ND, even EJB applications.

ND also supports Web services, which are fast becoming the standard protocol for machine-to-machine communications of the type required for thick client applications. The UDDI Registry is a sort of yellow pages that allows applications to find information about Web services, while the Web Services Gateway makes selected services available both inside and outside the enterprise, even allowing secure invocation from outside the corporate firewall. Thus, you can deploy thick client applications both internally and even at client and vendor sites that access Web services on your network.

Availability Is Key

With ND, you can deploy applications across multiple servers to directly address the issue of failover. IBM has confirmed that you can have heterogeneous clusters, with iSeries and non-iSeries machines in the same cluster. With a properly designed application, this could greatly reduce costs. There are perhaps a half a dozen or more basic physical configurations for highly available Web applications. The differences involve separating the duties of application serving from those of load balancing and then configuring and deploying those components for backup purposes. For example, you can have 20 application servers, but if they're all supported by a single load-balancing server and that server goes down, all 20 application servers are rendered useless.

However, selecting a configuration is not as simple as just making it failsafe. Additional complexity leads to additional cost as well as performance issues. Your application can be configured in any of a dozen or more ways to achieve both performance and availability, and the particular configuration you use will depend highly upon your specific business requirements.

These topics, including benefits and drawbacks and examples of configurations, can be found in the IBM Redbook Patterns for the Edge of Network. Although this Redbook focuses primarily on Windows-based solutions, the iSeries can easily be inserted into various places in these configurations as needed. Also, the book talks about the discontinued WebSphere Edge Server product, but the capabilities of the Edge Server have been subsumed into the ND edition. All that aside, the book does an outstanding job of addressing just about every issue of clustering and HA networking you might imagine.

Odds and Ends

Here are a few miscellaneous pieces of information gathered from the field, from IBM, and from you, the readers.

WebSphere Pricing

The price for WebSphere Development Studio Advanced Edition for iSeries (WDSAEi) was raised on December 9. You may have already seen some advertising to this effect. Basically, there are seven tier pricings and 21 upgrade options. Prices were raised on all of these features. While it's true that in some cases the new prices are more than double the previous prices, they're still less than the original prices from last March, and they're significantly less on the higher tiers. The entire price list, including last year's prices and the current savings over those prices, is shown in the following table.

My guess is that the prices were dropped in March because of certain sales expectations, which never materialized. Part of the problem may be that the only reason to use WDSAEi is to get EJB support, and as many of our industry experts have lately been saying, EJB isn't really the best architecture for business applications. I've been telling my clients that all along, so while the price rise is real, it's also not terribly relevant to those of us who don't use EJBs.

WDSc Meets the Real World

As we in the field use WDSc more and more, certain issues are starting to surface. Full-blown crashes have been reported: For some reason, the editor freezes up and eventually just terminates itself with a JVM code of 255. These occurrences seem to be associated with the jLpex editors, and those will likely get ironed out since the usability of the jLpex editors is a high priority for the WDSc team. For example, scrolling used to be an issue. If you held down an arrow key to scroll through a source member, the editor would occasionally freeze for a split second when jumping from one line to another. A recent release greatly reduced the jerkiness, and the WDSc team assures us that a future release will eliminate it entirely. This JVM crash issue is harder to diagnose because it's infrequent, so if you have this problem, please try to open a Problem Management Report (PMR) on the issue with as much background information as you can include. Meanwhile, I'm working with the Toronto lab to try to diagnose the problem. I'll report more in a future column.

Another problem involves upgrades and workspaces. A wonderful feature of WDSc is the ability to have as many workspaces as you need. The upgrade procedure is as follows: Log on to one workspace and perform the upgrades. Then, the next time you log on to one of your other workspaces, the upgrades will be applied to that workspace. However, the tool really doesn't keep track of all the workspaces, so upgrades aren't performed equally. There are a number of both good and bad ramifications to this architecture, but the worst one popped up recently: The most recent interim release caused a problem with all workspaces other than the one open when the upgrade was downloaded. The fix is to go into your workspace, find the folder named ".metadata" and under that, the folder named ".config." Rename it to something like "saveconfig" and then start WDSc for that workspace. The .config folder will be rebuilt using the latest plug-ins, and you'll be good to go. If you have any problems, just rename the saved folder back.

Also, there was a problem in which many of the iSeries-specific preferences (such as the LPEX settings) disappeared from the preferences dialog. The problem went away when I upgraded. The lab acknowledges the problem, and they indeed inserted a fix in the latest release.

Out in the user community, we're calling these things the "ragged edges" of WDSc. While many of the core features work flawlessly, the code comes up a little short in some areas--particularly the usability areas. These kinds of problems can frustrate a new user to the point of really creating pushback against the product acceptance. However, IBM is determined to fix these things. According to George Farr, it's important to understand that the product is built by many teams. (George also informed me that the proper abbreviation for the product is WDSc, not WDSci--it is assumed that WDSc is iSeries-specific, so no need for the "i"). The iSeries extensions, which are Toronto's responsibility, make up only about 10-15% of the code of WDSc. That's because WDSc is built on top of WSAD and WSSD, which are maintained in various IBM locations. Those products are in turn built on top of Eclipse, which is an open-source project, so by the time all is said and done, hundreds if not thousands of people are involved in the product.

Because of this, the PMR process is key to the development cycle. By submitting your problems as PMRs, they will get into the system and filtered to the appropriate people. Even though forums like David Gibbs' MIDRANGE dot COM are great places to interact informally with the WDSc developers, it's still crucial that bugs be reported through the PMR channel. This is especially important for things that are part of the base product like Eclipse or WSAD, because the Toronto lab doesn't have control over those teams. However, George assures me that if there are problems with the iSeries extensions (this includes things like the jLpex editors, the Remote Systems Explorer, and WebFacing), his team will address them as quickly as possible. And so far, this is exactly what I've seen.

If you've submitted a PMR but haven't received a satisfactory response, please let me know.

So Tell Me in Short Sentences...

In short sentences, I can sum up this month's WebSphere article as follows:

• The iSeries continues to get the praise it deserves from the technical community as an undisputed leader in business application serving.
• The iSeries also continues to get no recognition from the user community, thanks in no small part to IBM's lack of promotion.
• The iSeries has a couple of areas of perceived weakness.
• WebSphere ND has the potential to fill those weaknesses.
• EJBs are expensive, and WDSAEi is one more nail in the EJB coffin.
• WDSc is starting to experience some growing pains, but the Toronto team is determined to address any issues that come up.

See you next month!

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. Joe is also the author of E-Deployment: The Fastest Path to the Web and Eclipse: Step by Step. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..