Hey IBM! We Need a Native Web UI
Date Posted: December 01, 2008 12:00 AM

Many of us consider the System i to be the best platform in the world. We live by it, we embrace it, and we stay with it, although few outside of our circle understand why. Many consider us archaic when they see our green-screen interface or hear us say "AS/400." But we understand the reliability of our box. We know that with its integrated operating system and database, System i can do so much more than other platforms. For system operation and system management, it's hard to beat System i's simplicity and power.

As System i developers, most of us have exposed ourselves to languages other than just RPG or Cobol. Even so, most of us still prefer RPG when creating business applications. But we are missing something that other platforms have, and it's very important to our future and that of the System i platform. We need a native web interface for our existing applications. Third-party companies have provided them, so why can't IBM? The current solutions IBM offers aren't viable. However, I believe that if IBM develops a native web interface for the System i, it will profit the company in the future.

Why a Native Web Development Interface?

There is a community of experienced, business-savvy developers in the System i world that are extremely proficient in RPG. We can create business applications quickly, but we struggle with using interfaces other than our green-screen text user interface (TUI). We've never had a GUI or browser user interface (BUI) development method that's as easy to use as a WRITE, READ, EXFMT statement in RPG with a screen developed with DDS. Let's admit it: Using SDA or the screen designer in WDSc lets us get a TUI screen up and running very quickly, but we want the same efficiency with another UI.

If it were as easy to write to the browser as it is to a terminal emulator, most RPG developers would have made the transition already. If we could do an EXFMT HTMLPage1 statement in our RPG application, thus showing a page in the browser and receiving a response, we'd jump at the opportunity. If we could continue to use our initial sign-on logic and application security and not have to worry about variable state (something we are isolated from now), we would have already moved to the browser.

We need to be able to move TUI applications to a BUI — the interface of the future for all applications. This ability would allow us to keep using our existing skills, but move our applications to the browser, providing a huge benefit for the companies we work for by minimizing their investment in retraining and application retooling. However, we don't want to rewrite our applications. We need a solution that will let us move our application interface to the browser with minimal program changes.

Why IBM's Current Solutions Aren't Viable

Why don't IBM's current solutions work? First, there really isn't a solution. Outside of third-party applications and home-grown solutions, the most viable option has been CGIDEV2. CGIDEV2 is a toolkit of APIs for developing a web application in an RPG application. It still works today, but IBM doesn't support it. If IBM had adopted this toolkit, supported and enhanced it, we might have had our native interface in RPG by now.

HATS and WebFacing are two other current options. HATS has potential; as with CGIDEV2 though, it needs more face time and resources from IBM if customers are to embrace it. WebFacing doesn't have the same potential. No product that requires WebSphere is going to be widely adopted, because the cost to get the System i to perform as well with WebSphere as with a green-screen application exceeds an acceptable ROI for most customers.

In an iSociety Fireside Chat with George Farr last February (see the transcript at isociety.org/Chat20080206.html), attendees asked several times about a native web interface. Farr pointed to Enterprise Generation Language (EGL) as the probable solution. I've played with EGL, and I have nothing against it — but it's another proprietary development environment and language to learn. I don't see EGL gaining a foothold with RPG developers.

Why Doesn't IBM Give Us a Native Solution?

IBM has some of the sharpest, most devoted, and most passionate people that I've seen. I've had the privilege of talking with IBMers about development tools since Visual Age for RPG days. There is no lack of talent at IBM. IBM can provide a solution that would make RPG developers do handstands (not always a pretty sight) and create a new ILoveIBMForever.org blog site. So why hasn't IBM stepped up? I can think of two primary reasons (and I admit, both might be incorrect).

One reason for IBM's lack of action on the BUI front could be leverage or pressure from companies that already offer development tools. If you are a developer, I'm sure you can name three companies that have alternatives to WebFacing. An IBM-supported solution for RPG, executed correctly, would remove the need for these third-party tools.

The second reason is that IBM wants us off RPG — and perhaps the System i platform — altogether. I know that sounds a tad extreme. No, I haven't been overcome by paranoia after watching too many X-Files reruns. The ability to get our current applications to a BUI with RPG deepens our reliance on RPG and the System i. But if a BUI is our future (and no native solution is forthcoming), and it is just as easy to use PHP, Ruby, or Java on the System i, our application base will eventually move to other platforms. At some point, the platform becomes unprofitable for too many quarters and we get the "Discontinued" memo from IBM. For IBM loyalists, that means keeping the hardware, but not the System i. I wonder how blue our blood will be if that happens. The truth is out there.

IBM Can Profit by Giving Us What We Want

A company has to make money to stay in business, and I'm a big fan of seeing IBM and the System i platform succeed. There are three ways IBM can profit from a native web interface — and have its customers smile when they open their checkbooks.

First, IBM should make the web interface development tool available in Rational Developer for System i (RDi). RDi has a price tag, unlike WDSc. Until IBM makes WDSc unavailable, developers will stay with WDSc, but if IBM puts the web interface tool in RDi, developers will find a way to pay for the product. Second, IBM can make the web interface runtime a licensed program that customers pay for when installed.

The third way for IBM to profit from a native web interface is obvious. IBM will have higher hardware sales with ongoing maintenance revenue. Why? One reason is existing customer retention. We upgrade when we stay on the box, and IBM gets money. Another reason is that with a native interface, companies will have more sellable software products on the System i platform, thus more sales of the System i box.

Find the Right Strategy

All great companies survey their customers when developing their product strategy. IBM should do the same. IBM continues to bring new features to RPG with each release. If IBM surveyed the development community on what it needed for the next release and included the opportunity to prioritize a native web feature in RPG, I think we all know where it would rank.

Jef Sutherland is a System iNEWS technical editor and vice president of information services for Kampgrounds of America, Inc., in Billings, Montana.

Related Content:


 
  • rickjenn@optonline.net
    4 years ago
    Dec 04, 2008

    I'm afraid your second reason for IBM not giving us a native BUI - getting us off of the AS/400 altogether - is the closest to the truth, although it doesn't hit the mark exactly.

    Look at the IBM Corporation as a whole. Is it a hardware company the way it used to be, invested in the success of it's platforms? No! It's a services company. More than half of sales and profits come from that. Why would you promote a platform, the AS/400, that requires minimal outside services when you can promote Unix, Linux and Windows which require tons of help? That's the crux of the issue.

    IBM's long-term problem is keeping the thousands of customers invested in the AS/400. They have been trying anything they can, EGL being the latest attempt, to find a technology that replaces AS/400-centric RPG with something to that can migrate the customers to another platform and also keep them in the IBM fold.

    IBM is not invested in the long term growth of the AS/400 and hasn't been for over a decade. That is an obvious truth - just look at how they've managed the platform. So your desire for a native BUI will go unfulfilled, unfortunately, and eventually the dreaded "Discontinued" memo will come...not this year or next, but within a decade, when most of the AS/400 expertise has disappeared and customers have been forced to migrate to other platforms, willingly or not.

    • You must log on before posting a comment.

    Are you a new visitor? Register Here
     

    around the forums

    PASE - HTMLDOC (Scott's binary version) Error: please Help!
    Forum Name: RPG
    16 May 2012 01:58 PM | Replies: 3
    IFS directory structure
    Forum Name: Systems Management
    16 May 2012 11:52 AM | Replies: 2
    IFS folder/file authority
    Forum Name: Communications/Networking
    16 May 2012 08:45 AM | Replies: 6
    subscribe to this feed

    ProVIP Sponsors

    BCD

    Join Our Community!

    Subscribe today to iPro Developer! iPro Developer is packed with technical know-how for developers of IBM i, iSeries, AS400 and System i. Sign up now to get your full subscriber benefits including:

    • Code available for download
    • Full access to the online article archive (including all System iNEWS ProVIP content)
    • Downloadable ebook with past 6 months of articles
    • Discounts on eLearning classes, self-paced training, in-person events, and more!
    iPro Developer Newsletters
    • Get the Latest News
    • Product Updates
    • Helpful Tricks
    • Productivity Tips