Readers, Vendors Weigh In on Native Browser Support

Brian Kelly seems to have hit a nerve when he suggested that what IBM ought to do is pull an IBM Rochester integration maneuver and tightly integrate its RPG and COBOL compilers with HTML and go so far as to make the Web browser a native device that RPG and COBOL programs can speak to without intermediaries. (See "Wanted: Native RPG and COBOL Support for Browsers".) It sounded like a good idea to an awful lot of you.

We'd like to thank the large number of you who sent in comments. Below is a selection of the comments we received.

The Readers Weigh In

Great article by Brian Kelly. What a boost this would be to programmers like myself, who will never likely get into the Java thing. Why can't IBM see that AS/400 users want to remain on the platform using proven programming methods? I work for a small hardware/software company, and every year a few customers move off the platform because they cannot find software that will run their business. Oh well, I'm closing in on that age where it will not matter one way or the other.

--Bob

The article by Brian Kelly cuts straight to the heart of the matter. I had given up hope for a simple method of working with browsers. I've worked on the System/38 and its follow-ons for just over 20 years and have enjoyed working on this versatile and easy-to-use machine. I have attended several of Mr. Farr's sessions at COMMON and walked away confused and wondering why I was having so much trouble with the "new stuff." Thanks for putting the customers' perspective out there in such a compelling and eloquent manner.

IBM, are you listening?

--Kevin

I enjoyed Brian Kelly's article. I wished Brian would have thrown a little love to Mel Rothman and Giovanni Perotti for their work in CGIDEV2, which also has a COBOL version. These people have toiled in anonymity to provide us with quality, free tools that leverage our expertise in languages we are already experts at.

I am also disappointed with IBM providing us "academic solutions" that cause us more problems that they fix. How is learning a new IDE (WDSc), a new programming paradigm (Java/Web), and buying new PC hardware that can run it going to dissolve my one-and-a-half year backlog on my heavily modified PRMS ERP package? I wonder if any of these "rocket scientists" at IBM have ever talked to their customers, but I think I already know the answer to that one.

--Name Not Given

This article by Brian Kelly is by far the best description that I have ever read of the reality of where I live. It correctly explains why I work on the i5 (to build business applications, not computer stuff). It accurately tells of my main frustration of the i5 (not being able to access the browser as a native device). And it explains why it has not, and probably never will, happen (IBMers and the Java/WebSphere solution). Thank you, Brian, for explaining it so well.

--Chris

No question about it. Brian hit the nail on the head. After trying WebFacing on our new i5, WebSphere is coming off our iSeries. We were even one of those few that bought some of his books on WebSphere. He is a good author, but this article is his finest piece.

--David

Yes!!! This is what we need! Can you imagine how much more we could do and how easily?

Who can we talk to? How can we spread the word? Is George Farr the one? Maybe we can flood his inbox with requests from the iSeries community. Grass roots is the only way this will happen . . .

--Mary

Thank you for Brian Kelly's excellent article. Please email 15,000 copies to whoever is in charge of IBM this week!

--Pete

Brian Kelly is exactly right: we need direct browser support in i5/OS. I believe the only way we're going to get it is to bring the entire Application Development toolset initiative to Rochester and to let "our people," meaning IBMers with the i5 as their only focus, develop it.

I am weary of hearing the Eclipse cheerleaders and their amen corner in Toronto tell us how great it's going to be, even as they're tucked safely away from the real world of evolutionary application development and enhancement. I do not believe they understand the business requirements or goals of contemporary i5 application development; few developers (or their employers) have the stomach for the learning curve, time-to-market, and expense required by WebSphere, IBM's Brave New World solution. It's a solution for IBM's revenue woes, but little else.

I have zero interest in running my applications on a non-i5/OS platform, so why do I care about WDSc, a bloated, bug-ridden, homogenized, cross-platform AD tool? Progressive developers in a mixed environment rely on a combination of WDSc, CODE, and SEU to get the job done; what does this say about the state of the i5 AD tools? What it says to me is that most of the tools are well past the age of drinking and voting: while hardware has moved from System/38 to CISC AS/400 to RISC iSeries to butt-kickingly powerful LPARed boxes, we were never able to get Toronto to get the bugs out of CODE, a terrific application.

In spite of the fact that free-form RPG has a few more big steps to go, it's a strong, flexible language capable of driving a more complex environment than WORKSTN (but I'll admit to being confused as to why IBM's invested so heavily in RPG when it could have written a conversion program to convert RPG to PL/1).

Isn't it embarrassing that Mel Rothman and Giovanni Perotti, the loyal opposition, are the only ones with a clue? And while we're at it, isn't it embarrassing that IBM requires a Program Product (PSF/400) to print a graphic box on an *AFPDS printer?

Overall, I'm deeply discouraged by the state of IBM's development tools. It doesn't matter how good hardware price/performance is; at some point, the application functionality, look, and feel will make a difference. There's a lot of smoke coming from IBM on application modernization and penetration of the SMB marketplace, but only better AD tools and i5/OS support will light the fire.

Who's got a match?

--Reeve

As a 25 year RPGer, I read your article about native RPG support for browsers. First, let me say thank you for writing this. Maybe it will get the powers that be thinking in the right direction. I have struggled with this RPG, Java, WebSphere issue for a few years now and have not resolved it. I battled WebSphere, unsuccessfully, as I can't seem to get the hang of how to use this powerful tool. I've read books on it, tried to follow a step-by-step book on it, and went through the whole book, only to discover that the book was more about using Java with WebSphere than using WebSphere as a front end to RPG programs or the iSeries database.

I just don't see why I have to chuck everything I know and learn a new language that is confusing and complex. My other concern with learning a new language like Java is that leaves me at the bottom again should I have to leave or am forced out of my present job. It's true the RPG market is shrinking, but the Java market for a newbie must be even smaller. Plus, I'm at the stage of my life where I don't necessarily want to start over with Java.

I do most of my programs these days with RPG CGI, using the free CGIDEV2 utility that IBM provides but doesn't tell anyone about. This is the next best thing to having native browser support. If only IBM talked to regular programmers who make their living in the trenches, things might be better. Thanks again.

--Ed

Brian Kelly responds

Thanks to you all for the comments.

I know that IBM is finally thinking hard about delivering what we all want. Why it takes thinking is a phenomenon to me because all of us who know the platform know how invaluable such a facility would be. IBM would benefit immensely, so it is a puzzlement as to why IBM waits. Add a Web interface for command processing and the system is in the 21st century, far beyond legacy.

And Now a Vendor and a Product User Comment

The support you are requesting already exists. The DDS keyword HTML has existed since release VRM320 of OS/400. It allows data to be sent to a browser using traditional display file I/O. A host application program populates a program variable, defined as a program-to-system field using the HTML keyword, with HTML, Javascript, or other browser data and writes a record format. Here is a trivial example.

The DDS:

A           R HTMLSTUFFR
A             HTMLDATA    4096A  P
A                                   1  2HTML(&HTMLDATA)

The RPG:

FHTMLSTUFF  CF   E            WORKSTN
C  EVAL  HTMLDATA = '<h1>Truly Advanced Hello World +
C                   </h1><p><<font face="modern" 
C                   color="hotpink" + size="2">Hello World</font></p> +
C                   <p>Welcome to the modern world of RPG IV +
C                   and easy Web development!</p>'
C        EXFMT       HTMLSTUFFR
C        SETON                                        LR
C        RETURN

The above example shows hard-coded HTML, but it should be obvious that the HTML could come from anywhere. For example, it may be read from a stream file, a source database file, a data queue, or even be generated by another application. Style-sheets can also be used to control the visual aspects of the output to avoid hard-coding font sizes, type-faces, colors, etc.

If the client application indicates to OS/400 that it can accept HTML data, then OS/400 will send the contents of the HTML program variable to the client. One client that correctly handles embedded HTML in this form is aXesTS from Arterial Software.

aXesTS allows OS/400 programmers to develop Web applications using their existing skill set. Of course, they may need to learn some HTML, but most of this can be offloaded to Web developers. The OS/400 programmer merely needs to load and send the HTML data to the client.

This trivial example shows how output can be generated in a browser but data can be received from the browser by mixing HTML and traditional DDS input-capable fields in the same record format. Business data can easily be embedded in the HTML output and host applications can be extended to use new technologies, For example, pictures of employees can be added to an employee maintenance program, parts explosion images can be added to an item list, Flash and other multi-media deliverables can be incorporated in traditional host applications.

Using the HTML keyword in conjunction with aXesTS provides the most direct solution to Brian's request in a manner consistent with existing host application development and also supports standard DDS validity checking on input fields--something that is lacking in HTML forms. You can also manage which applications send HTML by changing or overriding the display file "ENHDSP" attribute.

--Simon Coulter, Arterial Software

Hello neighbor! I'm just down the Pennsylvania Turnpike in the Lehighton/Jim Thorpe area.

I enjoyed your article in Four Hundred Guru and wanted to point out that Advanced Business Link, makers of Strategi, have a product that we're using to create RPG to browser applications with complete report access. I write RPG 'servers' in a true ILE environment on the iSeries and write HTML, Style Sheets, and JavaScript (DHTML) for the browser. The data is delivered by the ABL piece, HSM using SSL at various encryption strengths or none. Using templates and standardization, we can create a number of display pages in a day. Pages that require user input and validation take a little longer, obviously, but they're supported very nicely. The possibilities are limited by the team's collective imagination.

Thanks for the great article!

--Bill

Brian Kelly responds

The aXesTS product is a terminal server. In other words, it gets installed on the AS/400 or i5 and it converts DDS to HTML/XML or whatever on the fly and it merges the content of the HTML keyword, which could be supplied by variable data from an RPG or COBOL program. I certainly would not suggest that this is not a good product. However, it is a product. It uses the HTML keyword that was designed for the old AS/400 HTML gateway product that was shipped with the AS/400 until a few years ago. The gateway does the conversion of the data stream on the fly.

This is very similar to iSeries Access to the Web, except that iSeries Access for the Web is a program that runs under WebSphere. This terminal server looks like it is a CGI-based product that does not need WebSphere.

I also believe that Strategi needs a PC or server outside the AS/400 to do its magic, but I am not certain.

The bottom line is this: Neither of these approaches are natural. They are more like CICS and Oracle than integrated transaction processing and integrated database support. They are add-ons. Typical AS/400 developers use PDM with SEU and SDA. They use IBM's tools. The closer that IBM can come to enabling these tools to be used (not perfectly) by their AS/400 shops in a natural way, the more inviting Web programming will become and the more shops will begin to use this stuff on the Web.

It is understandable that not all facilities can be available in Release 1 and perhaps all Web capabilities such as animations may never reach the AS/400 simple RPG development model. However, as much as gets done by WebFacing today should be able to be done natively on the AS/400. IBM could bring WebFacing inboard. For example, instead of on a PC, when a display panel is created, it can be "Webfaced" and the resulting JSPs and so forth can be loaded directly to an execution library that a semi-invisible, pre-installed WebSphere can dynamically use.

Just like nobody wants to see the 5250 data stream in raw form or the virtual terminal code that permits the displays to go to a PC even though the PCs are not running twinax and TDLC, nobody wants to see WebSphere. Moreover, nobody wants to see the JSP code that is produced by the GUI designer (SDA from DDS).

IBM needs to extend DDS, add some more capabilities to SDA and the GUI designer, and permit the compilers to access the new artifacts with the same op codes that are used for other files.

I love all the products that are trying to make up for IBM's deficiencies. However, I have no idea which is the best and quite frankly that evaluation task is one reason why few have bitten. There are lots more than these two out there and knowing what the plusses and minuses are for each of them is a daunting task. Especially if you are competing with Unix or Windows guys for management time.

The native browser support for RPG and COBOL idea is intuitive and it plays into existing skills and is more likely to get all the sleeping technical giants from beneath their sequoias if and when IBM chooses to please its loyal constituency.