The Four Hundred

Every couple of years or so, there seems to be another paradigm for computing that catches everyone's attention and calls into question everything that real-world IT shops are doing as they maintain legacy applications and create new applications. For four decades, CEOs and CFOs have been made nervous wrecks by this, and so have the IT managers and programmers who are stuck dealing with the rapid pace of change in programming technology. It's hard to know what languages to pick and what skills to build.

The threat of change, as much as real change, is what verifies the good things in life; change is what makes the world go round. It's good and it's healthy--as long as everyone doesn't get too distracted to get any real work done. Nothing makes companies think harder about the investments they are making, and makes programmers think about the skills they should be building, than a downturn in the economy. As we have reported in previous editions of this newsletter, companies are not hiring new entry iSeries programmers to build up the skills base for future products, and they are in many cases starting to let go of relatively inexperienced staff as they continue to pay a premium for those hot-shot coders who can make RPG (and in some instances COBOL) sit up and bark.

The two questions we have been asked with increasing regularity in recent months are what does the future of programming look like on the iSeries and what skills should programmers be building as they chart their futures? We don't have all the answers, but we talked to some people who have a pretty good sense of what is going on. This week we're taking a hard look at RPG, the main programming language on the iSeries and AS/400 platform, and what its--and therefore your--future might be. There is a wide variety of opinions on this topic, as you will see.

But before we get into all that, just a word of caution. There is no crystal ball that can predict the future. The best laid IT plans and projects come crashing to the ground because of unexpected events, like a merger or acquisition, a change in management, or other cultural changes that have to do as much with culture and fashion as they do with technical issues. It may pain you to read this, but the truth often hurts. The System/38, the AS/400, and the iSeries have never been cool or popular, and they are probably not going to be in the future. But they and their predecessors from the IBM Rochester midrange organization, which was established in 1969, have been innovative and effective machines in ways that Microsoft is still dreaming about.

We all talk a lot about why the OS/400 platform has a great architecture and how it has been able to absorb technological changes in compilers, processors, memory, I/O, and just about any other thing you can think of in the past 15 years. But we would argue that the real genius and risk of the System38-AS/400-iSeries platform was taken in the late 1970s, when IBM decided to create a midrange computer that used a relational database management system integrated with the operating system and a set of relatively simple programming languages to let companies with modest programming talents do the kind of sophisticated data processing that even IBM's mainframe did not have at the time. One might call the System/38-AS/400-iSeries something like Database for Dummies, in keeping with the tongue-in-cheek marketing of those familiar yellow books we all use.

Many people using OS/400 servers today don't know this history. But we dug out some old charts in the June 1995 edition of The Four Hundred (back when this newsletter was monthly and printed on paper) to show the big bet IBM was making. In 1980, a top-end System/38 cost about $3 million per mainframe 370 MIPS; granted, these machines didn't have very many MIPS, but IBM sure could charge a premium for them because the System/38 had the only relational database IBM offered at the time and a team of three programmers with some RPG skills could make it do a lot of useful work. (Oracle was just getting traction selling a relational database that borrowed ideas from IBM researchers a decade earlier, ideas that spawned the System/38's integrated database in the CPF operating system.) An actual mainframe only cost about $300,000 per MIPS at the time, by the way. It wasn't until the advent of the AS/400 in 1988 that the cost relational database processing on the IBM midrange platform came down to the level that mainframe customers paid for raw computing power--just over $100,000 per MIPS. IBM's DB2 relational database for mainframes was just starting to catch on in the early 1990s, almost a decade behind the System/38-AS/400 platform. In 1995, AS/400s were considerably less expensive than mainframes, at around $3,000 per MIPS, and continue to be about half as costly in terms of processor costs. In 2003, an iSeries probably costs only a couple hundred bucks per MIPS, or lower. We've come a long way, baby, and we did it for the most part using RPG to get at those databases on the OS/400 platform.

No, it's not a Role Playing Game, and it's not a Rocket Propelled Grenade. It's the Report Program Generator that is the beloved RPG. IBM's first RPG was designed in 1960 for the 1401 series of punch card machines (one would hesitate to call the 1401s mainframes), and RPG was further perfected for the System/360 mainframe in 1965. RPG II was one of the options available for the System/3, System/34, System/38, and then the System/36 (in chronological order), and as it evolved on those machines it was transformed from a report-generating program (so real hackers could get some real programming done, instead of being bothered by the suits for paper reports generated by these computers) into a full third-level procedural language that could be used to build real applications, just like COBOL, Fortran, Basic, and others.

RPG has been, and still is, the de facto standard for development on the OS/400 platform, although many other languages have been available on the AS/400 and iSeries platform. There are reasons for this. When IBM developed the underpinnings of the OS/400 platform (starting with the System/38), it put as much logic as it could as close to the hardware as possible (in the SLIC layer), and developed pre-built functions in RPG, called op codes, to give developers easy access to that logic. The result is that the OS/400 platform has developed a reputation--and quite deservedly so--as a rock-solid database server.

Developing in RPG gives you direct, easy, and powerful access to DB2/400, says Alex Roytman, an expert RPG programmer and the founder of Profound Logic, which provides productivity tools to RPG programmers. "The important thing for RPG is its roots: It's been there all along, and there's a set of operation codes that let you have stable, easy access to the AS/400 database."

Most of the object-oriented languages, like Java and C++, will use SQL to access DB2/400, which, Roytman admits, does provide flexibility. But the flexibility provided by SQL is a double-edged sword.

"RPG is not object-oriented, and that's really an advantage," he says. "With object-oriented database access, you generally specify field names as strings that are parameters to one of the functions in the object; whereas, in RPG, you're using the variables directly. The advantage is, you can't mess it up as easily. If you mess up a string in Java or Microsoft, it won't catch it and tell you, 'You can't do that.' At certain points, RPG is not as flexible as SQL would be. It's more rigid and stable."

Jim Duggan, an analyst who covers application development trends for market researcher Gartner, tells a similar story. "It's a database machine, and I'm going to push as much function out of that machine down into the hardware as I possibly can, so it's easy to administer," says Duggan. "The machine is so closely tied to the language" to provide a short path to the hardware. The problem is that other languages, like Java, can't exploit this machine as well, according to Duggan. IBM has arguably done a better job than other platform vendors in integrating Java into OS/400, but there are limits to how close you can get Java to the iron.

One easy and obvious way to gauge the future of application development on the OS/400 platform is to take a look at what the ERP vendors are doing. In its heyday, in the mid 1990s, the AS/400 and its integrated database made for an extremely popular platform on which to roll out ERP applications, and nearly all of the ERP vendors on the platform chose to develop using RPG.

When SSA Global Technologies was emerging from System Software Associates' bankruptcy three years ago, one of the first things it did did was develop an extension strategy. This strategy entails entering into OEM relationships with other software developers and private-labeling their applications, including CRM, supply chain, and business-intelligence software. To make this extension strategy work, SSA GT developed a middleware layer to make integrating BPCS with these other applications easier. As SSA GT has acquired other OS/400-based ERP systems, including PRMS, from Computer Associates and Infinium, it has been able to use this middleware layer to offer the same extension products to its new PRMS and Infinium customers.

The same extension strategy is being employed at Geac, developers of the System21 ERP system. In Early April, Geac announced the next generation of System21, called Aurora. One of the hallmarks of Aurora is that it was developed in RPG IV (also known as ILE RPG), which provides a number of benefits, explains Malcolm Rose, development director for System21. "ILE RPG provides a much more up-to-date source-code platform for us," Rose says. "It gives us a lot more op codes than we had available, and it's more amenable to reuse. We're able to create more modules that are more reusable, using existing technologies, in RPG, and that's important to us. Most important, it does make those particular parts of the system much easier to integrate with Java. And that's key."

Rose says the capability of System21 Aurora to interoperate with Java is an important part of Geac's development strategy, which, he says, is closely akin to SSA GT's extension strategy. "We're looking at continuing the core product in RPG ILE, and we've looked at developing extensions to the product in Java," Rose says. "We felt Java was the right mechanism for that. We certainly think, as we move forward, with Web services, that that outward-facing part of the system--the thing we publish to the world--is based on Java."

Intentia International has gone further in replacing its RPG code with Java than any other ERP vendor in the OS/400 space. The Swedish software developer decided in 1996 to rewrite its ERP application, called Movex, in Java. Movex NextGen, as the Java version was then called, began rolling out in 1999, and today, almost all new customers are purchasing Movex Java (as it is now known) instead of the older RPG version, says Gary Drake, a development manager at the company's Schaumburg, Illinois, location. Since February 14, 2002, the Java and RPG versions of Movex have been functionally identical. "Now, we're doing all of our enhancements in Java," Drake says. "We'll continue to support the RPG version for as long as customers need it."

Today, there is very little new development occurring in RPG, and most of the RPG work that is taking place can best be described as maintenance, such as Intentia's RPG strategy. Why is this the case? According to one popular theory, it's because of the decreasing relevance of the OS/400 platform. Some say that it is the inability of OS/400-oriented people to push and make decisions that affect their IT shops.

"In the old days, everything revolved around the AS/400," says Roger Pence, an education director with iSeries development tools vendor ASNA. "Everything that happened, happened because of the '400. Today, it's just another piece. The AS/400 is no longer the cornerstone of a network. The guys calling the shots are not OS/400-centric. Mostly, they're Windows-centric guys."

Stephen Rees, a System21 developer with Geac, sees the same thing happening with many System21 users. Many System21 users have a policy to keep all applications inside the firewall residing on the OS/400 server. "But they may have a different policy for Web-based applications, customer self-service, or collaboration applications. They may have to be on Windows 2000 or on Unix. Very often, the policy will be to run on a Windows 2000 server."

For the past decade--through client/server computing, then Internet computing, and now Web-services computing--applications running on the OS/400 platform have been gradually moving off the box, despite IBM's efforts to make it an open platform that can run all sorts of code. This is the result of economics as much as it is the result of the advent of truly distributed computing. The high cost of host-based computers initially drove all of these revolutions, but now it isn't economics that is driving it. Distributed computing, as embodied by the evolving Web-services paradigm, is being driven more by the desire to build different kinds of applications, ones that can run on any number of machines and can be dynamically allocated over a network, to those different machines on the fly. This is the exact opposite of host-based computing, as embodied by RPG running against a DB2/400 database on an AS/400.

The dearth of new RPG development has created a vacuum of sorts concerning the future of applications on the OS/400 platform. One way that IBM has sought to rectify this situation is by making OS/400 more Unix-like, first by adding Unix APIs and a C compiler in the 1990s, then through the Portable Application Solutions Environment (PASE) AIX runtime environment, and now through support for native Linux within logical partitions. Next year, IBM will offer full AIX instances running within logical partitions. Whether this has worked is debatable. To date, PASE has accounted for few relevant applications (SETI@Home is probably the most popular AIX application running on OS/400). While native support for the AIX may be interesting to some big iSeries shops that also have lots of Unix iron, it is not likely to affect the small and midsized shops that make or break the iSeries market. These OS/400 shops will probably get more out of native Linux than native AIX, if they do anything even remotely Unix-like at all.

Another source of new workloads for the iSeries is running Windows servers. Don't laugh. Some organizations, such as the Asian Art Museum in San Francisco, are purchasing new iSeries for the sole purpose of managing their Windows servers (for the full story on the Asian Art Museum, see tomorrow's issue of Midrange Stuff, OS/400 Edition.) Obviously, these Windows applications do not run on OS/400, and do nothing to promote native development for the iSeries. But they do illustrate the variety of ways in which IBM will serve its AS/400 installed base and try to keep the box relevant in changing times.

And IBM does have an answer to the question "where will new native applications for the iSeries come from?" One answer--and, many say, the answer--is Java.

IBM made the decision to promote Java as a core development language on the AS/400 platform years ago, and has backtracked a little since then so as to not completely undercut RPG. IBM seemed to be hoping, in the mid-1990s, that Java would replace RPG, but this was probably more fear than hope, and IBM positioned itself to totally embrace Java on the OS/400 platform in case that happened. This, of course, threw RPG programmers and their IT managers into a tizzy.

With the debut of OS/400 V3R1 in 1993 on the F series AS/400s, IBM rolled out RPG IV, a more object-oriented, modern version of RPG. This has been the last big change in RPG. Although Java was not around at the time, ILE RPG has more Java-like constructs and easier integration with Java applications. RPG programs can call Java programs and vice versa. By bundling all of its OS/400 development tools--including the old green-screen development tools and COBOL and RPG compilers and the new Java tools--into its Java brand, WebSphere, as part of the associated WebSphere Development Studio, IBM made its position pretty clear: RPG and Java will coexist.

"RPG III is dead," says George Farr, development manager for the iSeries tools, who works out of IBM's Toronto labs. "All of our host-based tools--SEU, PDM, SDA, RLU--are dead, and we need people to move away from them." Notice what he didn't say here: that RPG IV is not dead. In fact, Farr says that he has a list of at least 20 things that he needs to add to RPG IV to make it friendly in a Web services world. And he says IBM has been putting lots of effort into RPG since RPG IV, making big RPG enhancements in OS/400 V4R1 and V4R2 in the late 1990s and rolling out its biggest RPG enhancements in OS/400 V5R1 and V5R2 in the past couple of years.

"My message to OS/400 shops," says Farr, "is that it is no longer an RPG world and it is not a Java world. Customers can and should mix these environments. We don't want iSeries shops to convert their RPG code, but we do want them to build Java skills." Farr says that IBM is continuing to invest in RPG and will roll out new features, but he concedes that at some point in the future--how far away he cannot guess--there may come a day when RPG has gone as far as it can. For a program that is in its fifth decade, RPG has done a pretty good job of adapting.

That said, IBM continues to make improvements to OS/400's Java Virtual Machine and has released benchmarks that demonstrated the AS/400's great Java prowess. Some of the more progressive ISVs, such as Intentia, took the Java message to heart and advanced in lockstep toward the Java goal. Today, Intentia has several customers in North America using the Java version of Movex, although the majority of the early Java adapters are in Northern Europe, says Intentia's Gary Drake. "Java has become a very powerful alternative on the iSeries," he says. "I think the iSeries is one of the best platforms for running Java."

There is room for interpretation on the Java-OS/400 issue, however. Because IBM created the OS/400 platform as a great database platform, languages like Java simply cannot take advantage of the platform's inherent benefits as rightly as RPG, says Gartner's Jim Duggan. "Java is opposed to the design philosophy of the AS/400," he says. "It falls short of what language exploits this machine well."

Pence isn't so diplomatic about Java on the iSeries, especially when it comes to WebSphere. "It's not that Java's bad; it's a great language. It's that IBM screwed up the entire package. Look at how big WebSphere is, the size of a '400 it takes to use it," he says. The new scaled-down version of WebSphere, WebSphere Application Server Express for iSeries, is too little, too late, he says. "IBM gets a complete pass on this. Where are the Java success stories?"

The reluctance of ISVs like Geac to promote an RPG program outside of the firewall speaks volumes about the problems surrounding the perception of green-screen interfaces. While RPG may be used to write rock-solid database applications, when it comes to user interfaces, the writing is on the wall: You'll get nowhere trying to sell an application with a green-screen interface.

"RPG is good for writing business logic, but it's not the language of choice for writing cool GUIs," says Roytman of Profound Logic. "For the Web, there haven't been good tools for RPG programmers. CGI and CGI Dev are not easy for an RPG programmer to grasp. This is where I saw an opportunity to develop a tool." That tool, called RPG SmartPages, converts RPG screens into HTML screens. It's like JavaServer Pages, only the logic of a Web page is written entirely in RPG.

Other ISVs, such as Geac, Intentia, and many others, have adopted Java as a standard for developing Web-based graphical front-ends. Still other ISVs use Java, various Microsoft tools for Windows environments, or various tools for mainframes or midrange servers that extend legacy applications to the Web.

When it comes to the next-generation of legacy integration, most software vendors these days are pointing to the potential of Web services to expose certain business processes embodied in legacy systems and deliver them across the Web in a pay-for-use model. Pence's company, ASNA, is closely aligned with the Microsoft .NET version of Web services. To put it bluntly, .NET is a clone of the Java language and the Java Virtual Machine runtime with a lot of XML glue that is--you guessed it--incompatible with Java and its Java 2 Enterprise Edition stack. (To be fair, it looks like .NET will be interoperable with J2EE, but that is not the same thing as compatible.) Whether or not you like Microsoft's approach, the fact is, .NET is going to get traction in the market just because Windows rules the desktop and accounts for about half of server shipments a year. You can't hold back a tide like that. And that is perhaps why Pence is keen on the potential of .NET at OS/400 shops. "One of the tenets of .NET is to reduce the complexity in this stuff that is inherently complex," Pence says. "We're working very hard to put into our developers hands effective tools to reduce complexity." Others, including Roytman, have said they are impressed with Microsoft's .NET tools as well.

Quite correctly, many people have come to the conclusion that the iSeries is being relegated to the role of a database machine by the advent of Java and .NET. But, remember, this is not the first time this alarm has gone off. Back in the client/server days, when everyone started thinking of two-tiered architectures with Windows on the desktop and the possibility of porting everything to Oracle databases to get some measure of portability in their applications, it looked like the AS/400 was doomed. Perhaps what saved it was the fact that client/server only solved half the problem by getting the client tier off the host machine. Perhaps what saved it was the fact that DB2 didn't yet exist on Unix machines, and Windows itself was just getting started on servers back then, and it certainly didn't have DB2.

These days, you can get DB2 on OS/400, Windows, Unix, and Linux, and a lot of applications are written from the ground up to use clustered application servers that are distinct from database servers, for precisely the economic and technical reasons many feared back in the 1990s. By making the OS/400 platform open, the door swings both ways. If you make it possible for applications to come onto the platform, you also make it easy for them to leave.

While IBM has ensured the permanence of something resembling an OS/400 server, the platform's real potential to contribute to today's heterogeneous IT department lays largely in its role as a database server.

"AS/400 shops today have two assets: their data and competent programmers," Pence says. "It's the green-screen user interface--that's the part that's got to go."

Next week, we'll tackle the issue of what skills OS/400 programmers should be developing to keep themselves current, relevant, and marketable. There are some difficult choices that programmers--and the managers who should be spending money on their training--have to make.