IBM Support for

[Guest.Visitor]

Hello everyone, I heard that IBM was going to "drop support" for E-RPG (CGI programming with RPG with some special APIs that read and write HTML). I'm not trying to spread any rumors, and I would be disappointed if this is true. If anyone has heard one way or the other on this, I'd appreciate hearing about it. I'm planning on learning some E-RPG techniques, hence my interest in the subject. Thanks in advance.

[Guest.Visitor]

IBM Support for

I haven't heard anything about dropping support for CGI in RPG. Not saying it won't happen, just that I've not heard about it one way or the other. What I have heard a lot about are IBM's new e-development tools that are set to debut on October 20. (hmmm...wonder if that was a secret? oh well...I'm tired of pussy footing around this topic. Time to share it, if you don't already know about it. If you do, please don't write to me to tell me how IKnowEverything.COM or whoever has already posted this information in triplicate six months ago. I truly don't care what the other guys are doing. I'm sure it's just grand, but I have enough to do without worrying about what they are doing too!) Basically, if you already own the Application Development Tool Set (ADTS), and, I think, have a subscription to IBM's software support, then you will get, for free, the following: (if you don't have the ADTS, it'll cost you $300): ADTS (includes SEU, PDM, DFU, etc..) CODE/400 Visual Age RPG Visual Age Java ET/400 Webshpere Studio Affinity/400 Web Facing toolset Basically, all of this, except for the Webfacing stuff and Affinity/400, has been available for purchase as separate packages before. IBM is now packaging it all into one inexpensive set for you to access. The ET/400, or Enterprise Toolkit/400 for Visual Age for Java used to only be available with the $2,500.00 Enterprise edition of VAJ. IBM is giving it to you for nodda now. The Affinity/400 is a new tool that is really cool. It's a Display File-like Pallet Parts page designer (and that's a mouthful). It lets you very rapidly generate Java GUIs using wizards (IBM calls them smartguides). You'll be able to leverage your existing knowledge of DDS to create java subfiles (tables), JSP's, call legacy programs from Java, call service programs, create HTML, Java Beans, etc.. It's the kind of tool that we RPG programmers have been clamoring for ever since Java hit the AS/400. It'll also let you build enterprise level apps using Websphere very rapidly. The web facing tool lets you very rapidly turn existing DDS files into JSP's. And by rapidly, I mean in seconds. It's very cool. MC will be bringing you much more detail on all of these products and what they'll mean to your shop (or what we think they'll mean to your shops, anyway) in upcoming issues, so stay tuned.

[Guest.Visitor]

IBM Support for

I'll always support it. Unless they take away the APIs (which work pretty good) or intentionally break them, I'll step up to the plate and help out as much as possible. I think it's a very good tool, and so do a lot of others. I know someone doesn't like eRPG. Someone posted a review at Amazon.com of my book under Al Barsa's name. It was a pretty nasty review and I've contacted Al to verify that it was not him who posted it. Brad

[Guest.Visitor]

IBM Support for

Do you mean like onMouseOver="javscript()" You should use double quotes. But, in doing so you do have to pass parms sometimes, so I'm guessing you mean: onMouseOver="javascript('parm1','parm2'") If so, you can get around it a few ways. Here are two. 1. Create a constant with the hex value for a tick. Then concat it where needed. 2. Use two consecutive ticks to tell the system you mean one... for example eval HTML = 'onMouseOver="javascript(''parm1'',''parm2''")' Hope this helps. LEt me know if I am off base from your question. Brad

[Guest.Visitor]

IBM Support for

Bradley and Shannon, Thanks for the info. The rumor wasn't anything that I took real seriously, but I thought that I would check. Thanks again.

[Guest.Visitor]

IBM Support for

I'd be interested in the source of the rumor. Maybe it has something to do with the cowardly post on Amazon. At least they didn't sign it "Frank Soltis". haha.. Brad

[Guest.Visitor]

IBM Support for

Brad, I can assure that the source of the rumor, had absolutely nothing to do with that Amazon post. The source was just from one of my fellow employees, who knew that I was interested in learning e-RPG. I was skeptical of the rumor, but I also didn't want to learn something that wouldn't be around for much longer. I just thought that it would be prudent to check, so I did. Thanks for the response. Again - sorry to hear about the bogus review. It makes me sick as well.

[Guest.Visitor]

IBM Support for

Hi Brad, I havn't read your book, but have appreciated your insightful answers and comments on the subject of web development. I think e-rpg has some weaknesses, however, and wonder if you could comment on them. My comments, however, are not intended to discourage people from e-rpg development or learning from your book. Program initialization for CGI is a concern to me. Particularly in high-traffic sites. If 100 people submit a CGI form at the same moment then 100 CGI programs get loaded to handle the requests (assuming enough HTTP server threads are active). In contrast, java servlets are usually pre-loaded, and ready to receive the next request. I know java is still slower than rpg, but I think the design concern is still valid. Another concern is a number of redundancies in e-rpg programs. You take your last program, and use it as a template for the next. You end up with several programs that are partly clones of one another. They share many common elements. For example, environment string and form variables must be parsed. A certain amount of code in every program is dedicated to this common requirement. In contrast, Websphere automatically parses form, environment string, and HTTP server variables for you. Another example of redundancy in my e-rpg programs, has been the loading of HTML from source file members into arrays. Another concern is the proper separation of Human Interface from program logic. In 5250 development, for example, the screen objects are separate from the program objects. They can be created, changed, and managed independenty of one another. In contrast, e-rpg combines Human Interface (HTML) and program logic (RPG) into one module. A change in the HTML can have a big impact on the program. Sorry for such a long post.

[Guest.Visitor]

IBM Support for

Nathan, You're right, there are some weaknesses, but with every language, you'll find strengths and weaknesses. I'll try and comment on your questions:

>Program initialization for CGI is a concern to me. Particularly in high-traffic sites. If 100 people submit a CGI form at the same moment then 100 CGI programs get loaded to handle the requests (assuming enough HTTP server threads are active).<<

Shouldn't be a problem with today's e-Machines. They're made to have more CPW in batch. It's the same as older interactive machines and 100 people loading Order Entry. You'll always have that problem.

>In contrast, java servlets are usually pre-loaded, and ready to receive the next request. I know java is still slower than rpg, but I think the design concern is still valid.<<

But how easy is it update a servelet, especially if it's mission critical? Does the user need to clear their cache? (I don't know.. im asking). And think how much more bandwith is used downloading 100 servelets compared to just HTML from eRPG.

>Another concern is a number of redundancies in e-rpg programs. You take your last program, and use it as a template for the next. You end up with several programs that are partly clones of one another. They share many common elements.

For example, environment string and form variables must be parsed. A certain amount of code in every program is dedicated to this common requirement.<< Again, this is all programming technique. Some programmers code the same subroutine in 100 programs, some use ILE and modularize. Same with eRPG. Parsing with the QzhbCGIParse API removes your concerns as well, since you can retrieve all or each of the values individually, as well as fields with multiple selection values. (a great wrapper for this API at source samples on www.netshare400.com)

>In contrast, Websphere automatically parses form, environment string, and HTTP server variables for you.<<

Websphere uses the same APIs that I use. eRPG is more "raw" and with the right subprocedures, can do everything WebSphere can do, and just as easy. I often say comparing Websphere to eRPG is like comparing Cold Fusion to Perl.

Another example of redundancy in my e-rpg programs, has been the loading of HTML from source file members into arrays.<<

This is one thing that I wish wouldn't have gotten out. A few writers used this technique because they copied source from the IBM manuals and modified them. I don't know how many people I've helped with these, and told them to get rid of those arrays. Storing the HTML in a member or in a file in the IFS is preferred. You'll notice in my book I never use an array to store HTML. That was on purpose.

>Another concern is the proper separation of Human Interface from program logic. In 5250 development, for example, the screen objects are separate from the program objects. They can be created, changed, and managed independenty of one another.

In contrast, e-rpg combines Human Interface (HTML) and program logic (RPG) into one module. A change in the HTML can have a big impact on the program.<< That's a valid concern, but with most CGI languages, you have this problem, so it is not unique to eRPG. Again, storing static HTML in a file in the IFS is the best way to help overcome this. Don't hardcode any HTML in your CGI programs that doesn't need to be there.

>Sorry for such a long post.<<

No problem. I hope my answers make sense. Brad

[Guest.Visitor]

IBM Support for

Thanks Brad, Since I've done quite a bit with CGI, all your answers were quite clear. For "server" development, my language of choice is RPG. I choose RPG primarily for performance and personal productivity. But often, us RPG developers can glean from other tools. That was my reason for bringing in a couple Websphere examples. By the way, when I raised the "servlet" example I was speaking of the component that runs on the AS/400 as opposed to "applets" that are downloaded to browsers. Servlets are like CGI programs - they generate an HTML response to browser requests. One difference is that servlets run within the context of an "application server" as opposed to being loaded each time a new request is received. Like CGI, when you make a change to a servlet, it is then redeployed only to the host - not to the browser. One other question for you. For those web applications that require you to keep track of session variables across multiple HTML forms - do you have a technique you can recommend? Nathan.

[Guest.Visitor]

IBM Support for

>One difference is that servlets run within the context of an "application server" as opposed to being loaded each time a new request is received.<<

Just to clear the air, eRPG isn't loaded every time a request is made. This is an example of ILE in action. Sure, the first time the job runs it, it's loaded, but after that it doesn't load again.

>One other question for you. For those web applications that require you to keep track of session variables across multiple HTML forms - do you have a technique you can recommend?<<

Whew.. that's a big question. Generally what I usually do is either pass Query String variables or embedd hidden input fields in the page itself. I have used cookies, as well, but there doesn't seem to be an easy way to read a cook from an eRPG program (I wish there were). I'd love to hear other ideas. It would be neat to be able to set your own environment variables (maybe you can, I just haven't tried). Like if I could Say PutEnv('MYVAR_CUSTOMER':'45645') and it would create an environment variable and assign a value. I know you can do it with DOS. Brad

[Guest.Visitor]

IBM Support for

>Just to clear the air, eRPG isn't loaded every time a request is made. This is an example of ILE in action. Sure, the first time the job runs it, it's loaded, but after that it doesn't load again.<<

This is a good point. OS/400 does not actually unload a program until after a period of inactivity. So performance of frequently called programs benefits. I think the distinction I should have made was that the loading and unloading of servlets is controlled by the application server (or administrator) as opposed to being controlled by OS/400. Its a technique application servers use to eek out every bit of performance possible. An analogy would be a batch program that runs continuously - waiting for a request to be placed on a data queue. The same program may then be used to serve multiple clients. This can be more efficient than multiple program calls from concurrent clients. Actually, my point may be little more than splitting hairs. I'm just always on the look-out for ways to improve performance, increase efficiency, and manage scalability. Application servers attempt to address those issues. Thanks, Nathan.

[Guest.Visitor]

IBM Support for

Nathan, Advanced BusinessLink Strategi web server doesn't use CGI, separates data processing logic out of the HTML with corresponding HSM script files, and processes the web page scripts with any number of never ending programs in any mix of languages. With a small footprint, best web server cost performance, and no development seat with all the baggage that comes with that, multi-thousand dollar seat costs, proprietary 4GL languages, and program re-engineering, Strategi meets all the criteria mentioned in this thread for web page serving. However, existing RPG logic is rarely modularized enough to call without rearranging code to place in the server programs, and Strategi currently only generates web pages, not Java GUIs, so a strong argument can be made for replacing green screen calls with Joe Pluta's web page or Swing GUI calls or Jacada Innovator API calls. On the other hand, I've seen some powerful interfaces to existing logic accomplished without disembowelling an RPG system. My personal opinion is that serious business can't be done in web pages, but apparently I am out of step with the rest of the world or I'm one of the few who are naive enough to declare that the King is wearing no clothes. I came to that conclusion years ago as I watched effort after effort at products attempt to duplicate the density of information and functionality of green screens and/or the richness of the GUI interface, and do neither very well. At some point M$ will add enough features to IE that it will be good enough, but it will still require Windows, and probably 2000 at that, so what's the point? We had Windows programs and the whole point was cross platform. The sooner we get Java 2 on every desktop and past this IE is already there, Java has to be installed bs, the sooner we can do real work with an approach like Joe's, that is, a graphically rich thin client with subfile type processing. I have written some more ideas along these lines in this month's IMHO. Whether it be web pages or GUI programs, all the points that you made about performance will be addressed by never ending RPG server programs that implement business logic API's. This will continue to blow away the other approaches such as CGI and SQL packages and the like no matter how well cached, unless IBM just flat out cripples native I/O as a byproduct of their constant attempts at improving SQL performance for, ironically, those who could care less about the AS/400. Regards, Ralph