• RPG
• ILE
• Native I/O
• The Developer Roadmap
• The iSeries/i5
• IBM

RPG

RPG has a long history. In fact, it's one of the oldest programming languages, having recently celebrated its 40th birthday. This in itself is enough to get a lot of grief from a certain segment of the population, primarily the folks who insist that new is good and old is awful. I find that argument a little frivolous, since many of the "new" languages can trace their origins back to C, not exactly a spring chicken of programming. If you use curly braces or semicolons in your development, you're probably using one of C's descendants.

That's not to say that there haven't been significant improvements as the new languages have been developed. But the same can be said for RPG, except that the name hasn't changed. And interestingly enough, that lack of a name change may be one of the biggest problems for RPG, at least from a standpoint of perception among nonprogrammers. One client of mine noted half-jokingly that in order to sell an RPG-based solution to management, he may just use the term "ILE" and drop RPG altogether. And given the state of the language today, that's not a bad idea.

Some claim that RPG is a dead language, but nothing could be further from the truth. In fact, RPG has had more enhancements in the last five or six years than perhaps any other language--I'm talking about fundamental, paradigm-changing enhancements that push the language into the next generation. 1998 was a banner year for RPG, with the introduction of RPG IV and ILE. The addition of the subprocedure was a monumental shift, as was the concept of the service program. RPG antagonists quickly point out that such language features were a long time in coming, but that's not the point. The point is that the features were added--and with more functionality than their C-based counterparts (automatic parameter conversions are just one example). And IBM continues to add well-thought-out, often brilliantly implemented features that make programmers more productive.

I may not always agree with the compiler team, but one thing can be said: They don't do things without a lot of foresight. I may not agree with their vision, but I can rarely fault their execution. But more importantly, just the fact that so much development has been done obliterates the idea that IBM considers the language dead. IBM has spent more money on RPG and its free-form variant than any reasonable person could possibly expect a company to spend on a "dead" language. Look at how long it has taken to get some small features added to Java, like generics. In the same time frame, RPG got subprocedures and free-form syntax.

ILE

Here's another area that completely contradicts the idea that IBM considers the iSeries, RPG, and OS/400 dead (regardless of their marketing names). ILE is perhaps one of the most complete and fundamental underlying changes to a development environment ever attempted. The .NET folks insist that Microsoft has done just as well if not better, but there's one overriding difference: You can't move legacy Microsoft applications (something of an oxymoron, but you get the idea) to .NET; just ask the Visual Basic folks. Once again, the IBM teams did it right, and RPG programs move quickly and quietly from OPM to ILE with barely a whimper. Heck, you can run OPM and ILE together in the same environment, albeit with some common-sense caveats. It is this attention to asset retention that makes the iSeries such a powerful platform. Of course, that's also a problem for the people who make money from constant rewrites, which is something I'll address a little later.

Native I/O

Here, unfortunately, my view is less optimistic. It's not that IBM is abandoning native I/O, but there is a lot more focus on SQL. Of course, based on my benchmarks (see the IAAI Web site), improvement is necessary. At the same time, some of the new features being added to the database are skewed toward SQL use. For example, things like identity columns and encrypted data are pretty much reserved for SQL.

In fact, two different wars are being waged here. The first is the battle of DDL vs. DDS, which is a little like RPG vs. COBOL. Both are excellent ways of getting things done, and which one you choose is really a business decision based on the features you need. If you want a logical file that provides both selection and ordering of records, DDS is the way to go. If you need SQL-specific functions such as identity columns, only DDL will do. And the two can coincide quite nicely. I think it's sad that the features being added to DDL aren't being incorporated into DDS as well, but there are only so many development dollars to spend, and IBM seems to have made its decision.

The bigger issue is native I/O using standard RPG opcodes like CHAIN and READE (and their COBOL counterparts). Some of the features in DDL-defined files just aren't available to native I/O. For example, as far as I know, encrypted fields can't be accessed via native I/O operations. If this trend continues, it's going to be a real problem for RPG programmers. Not that we won't be able to get around it--we can use embedded SQL and move SQL-specific information into separate tables and access them via subprocedures--but I think this widening schism between SQL and native I/O is a problem. Until I can select or update a single record as fast with SQL as I can with native I/O, I don't want to see SQL get extra features.

Frankly, I think some of the features added to SQL are simply there to override architectural deficiencies in the design and to make SQL the de facto standard for inter-machine communication. This is a misuse of the tool, in my opinion. What we need is a simple, collapsible message transport mechanism (by collapsible, I mean one that can use a verbose XML-like interaction for initial communications but can "collapse" to a leaner mechanism if the two sides agree) for program-to-program calls; then, we can let SQL just be the query tool it was designed to be.

The Developer Roadmap

If there's been a more misunderstood document than IBM's Developer Roadmap, I'm not sure what it is. I've taken the time to talk to both Greg Hurlebaus, the author of the roadmap, and Doug Fulmer, its primary proselytizer, and they both clearly agree that the idea behind the roadmap is not that all iSeries systems should be converted to Java and SQL with all programmers burning their RPG books.

The Roadmap was supposed to be a sort of guide to the various destinations available to iSeries developers. It was meant to show the breadth of possible configurations for systems development--from pure legacy all the way to pure open, with a wide variety of waypoints in between. It was not meant to indicate that pure Java development is the nirvana of application development that everyone should strive toward. There are any number of possible architectural approaches--using various combinations of technologies--that are perfectly viable destinations, based on your business needs. The idea that one size fits all was never the intent of the Roadmap, at least according to the folks closest to it.

The problem is that this is not a clear message from IBM: Some people inside IBM, especially outside the iSeries group, have gotten the idea that the combination of Java and Linux and SQL is The Best Answer For Everything. It's unclear to me how people with responsible positions in a computer corporation could get this idea; it reminds me of the grand move toward Unix and SQL that bankrupted SSA in the '90s: a technological decision made by executives over the clear objection of the technical management who knew better. The IBM powers that be might want to study the history of SSA; "those who don't learn are doomed to repeat" bears attention.

The iSeries/i5

What about the platform itself? If anything points to IBM's tacit acceptance of the strategic nature of the iSeries, it is the fact that it and the operating system are continually being renamed. This is purely a marketing issue, and IBM wouldn't waste its money on a horse it doesn't plan to keep in the stable.

In fact, the continued rebranding is simply a way to counter one of the most tired yet still effective complaints about the iSeries, namely its "proprietary" nature. By now, anybody who looks at it objectively has to realize that the iSeries is now the most open platform available, combining multiple languages and even operating systems, even as Windows becomes more proprietary; witness the removal of Java from the Windows platform. And while someone (who shall remain nameless) remarked that the iSeries has more names than Liz Taylor, it indicates to me that IBM is committed to the platform and the OS for the long haul.

How long that haul will actually be is an issue that remains to be seen, and I'll touch on that again near the end of this article. Once again, the mixed signals send unclear messages.

The single most positive indicator of IBM's commitment, however, is the recent appointment of Mike Borman as the new iSeries GM. While I don't have anything negative to say about Al Zollar, I remember being a bit distressed when I read his comments that there would never be an iSeries TV ad. And while we're not inundated with iSeries ads, the few we've seen certainly indicate forward movement. But more important is that Borman comes from a $30 billion operating unit (that's billion with a "b"). From all accounts, he was quite successful running that unit; it seems unreasonable to think he was put in charge of a platform that was going away anytime soon. However, we all need to wait and see what Borman's ideas are before we pass judgment on this particular move.

IBM, the Great Miscommunicator

Those of us who use the box are hard-pressed to understand why nobody else understands it. It's as if powerful forces are conspiring to hide the iSeries from sight, using it only to keep a few recalcitrant ERP customers from revolting. And while that's certainly not true, there are some reasons that the system doesn't get the recognition it deserves.

What are the forces that align against the iSeries and the common-sense acceptance of the native tools that make the box the powerhouse that it is? Well, they're twofold.

First is IBM's juggernaut toward Java and SQL. I'm not sure who thinks this is a good idea, but apparently some people believe that developing one set of source code that generates code on every platform is a good thing. This is silly, of course. Code that runs everywhere typically runs poorly everywhere. You shouldn't use COBOL to write an operating system, you shouldn't use C to write an ERP system, and you sure shouldn't use Java to write business logic. The only winners in that scenario are the ISV who wants to write code for every platform and the hardware vendor who wants to sell lots of hardware. The end user gets saddled with bloatware that requires extra hardware just to run normally. Microsoft is a perfect example of the idea that bloat is OK. I have clients who need more memory and disk space on their laptops than on their iSeries.

Besides which, IBM has been out of the application software development arena for a while now. So why does IBM think it knows how to write business applications better than its customers do? If IBM were still supporting MAPICS, I might have more faith, but some of the tooling decisions make it seem that IBM has lost touch with the needs of its customers. I have to take IBM's view of the "future of application development" with a grain of salt. Tools, operating systems, languages--those IBM has down cold. Application programming? No offense, but let me do my own, thank you.

A second issue is the fact that the iSeries just doesn't make much money for other parts of IBM. WebSphere and DB2 are bundled in, and my guess is that not much iSeries revenue goes to those folks. Some dollars do go to IBM's Software Group for WDSc licenses and the like, further reducing perceived iSeries profits, but I'm sure it's not enough in the minds of SWG. Personally, I'd like to see a nice chunk of the iSeries sales--and even more importantly, the support costs--go to the WebSphere and DB2 folks, if they'd just stop treating the iSeries like the enemy. Think about it: The majority of support calls these days are not on RPG; they're on WebSphere Application Server and WDSC. And if they are on RPG, they're on embedded SQL. Since support is bundled in, why not direct some of that money toward the other groups and keep them happy? Yes, that would be less money for iSeries development, but we could offset that with more sales if IBM would just market the box appropriately.

In fact, that might also address one of the more recent complaints: that iSeries profits aren't what they were in "the old days." I'd like to see profits compared to revenue along the business units and see how the iSeries does. My guess is the iSeries stacks up pretty well there, which would mean that, dollar for dollar, selling more iSeries would be better than selling other stuff. But evidently that basic concept, like the concept of TCO, is no longer heeded at the executive level. But if IBM were to beef up sales of the iSeries, profits would jump as well. That would sure beat trying to do it a nickel at a time with the low-end boxes or all at one shot with the zSeries.

What Do I Want to See?

Recently, I happened to talk to Kelly Schmotzer, and she asked me this very question. That got me thinking about what I want not only from IBM but from our community as a whole.

What I want to see first and foremost is an end to the idea that Java and Linux are the answer to everything and that SQL is a good replacement for native I/O. The numbers clearly show that this is not the case, and the truth is that it does not make sense to have to buy triple the hardware to get the same performance just because my ISV doesn't want to support multiple code bases. The idea that Java will someday be a good language for business development is pure wishful thinking; unless you can show me an MRP generation written in Java, you're trying to sell me snake oil.

I want our community to stand up and tell IBM that we aren't giving up our iSeries or our RPG anytime soon. We're not anti-Java or anti-SQL or really anti-anything (except maybe Windows server farms); we just want to be able to decide our own future based on our own expertise and our own knowledge of our business.

Notice the use of the word "our." Here's where IBM is missing the boat, I think. What I want from IBM is options. I don't want to be sold their vision of the future; I want to be able to use the best tools to solve my business problems today. I know what tools I need, and I want IBM to make them available to me. This may well include Java and SQL, but only where I deem it necessary.

What I really want is a set of preconfigured systems, like high-end entertainment centers. I can pick the business logic server and the Web application server and the file server and the mail server and the desktop OS and the firewall, and I can configure them however I want, inside or outside my DMZ. I want to see maybe a dozen "standard" configurations, ranging from a zSeries solution to an xSeries blade farm, with starting costs and projections of yearly costs, including support and staffing. And I want several of those configurations to be iSeries-centric, with an iSeries as the central business processing unit. Options could be Linux or Windows desktops and onboard or standalone Web servers. My guess is that based on TCO, the iSeries would be a very popular package. There could be "boxed sets" of standard software and even consulting from BPs ("includes 400 hours of customization!"). Training packages. The whole nine yards.

Heck, IBM could even include Java-centric shrink-wrapped solutions that scale up from xSeries to zSeries as your business grows. But let's not make that the only option.
What I need most from IBM is choice. And I don't mean the choice of which hardware to run Linux on.

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, with WDSC: Step by Step coming out in just a couple of weeks. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..