Front End Development for AS400

20 pts.
Application development
PC/Windows Connectivity
Web development
Hi We have an application in AS400 for which we are thinking of developing a GUI front end for the users. The users will then be able to run the processes from their PC. I have not worked on any such application and so, I do not know anything of that. I have done some initial research on that and found out that we can have a client/server model or we can have a web based application model wherein almost everything important is handled by AS400. However, I have not been able to find out anything which will help me to find out how I should start for this task. Can anyone help me on that? Thanks

Answer Wiki

Thanks. We'll let you know when a new response is added.

In my experience, it really depends on the complexity of the application. I’ve created several GUI interfaces into our AS400. If you’re rewriting a report, or if it’s a simple application, or if it’s new development, web based applications are the best, but, if it’s a complicated application sometimes you best bet is to build a GUI over top of the existing application.

approaches I’ve taken in the past :
1) New applicaton, web based – I’ve written a huge number of reports, as well as moved quite a few simple applications to negate the need for unnecessary logins. When I write these, I connect directly to the database, so business logic needs to be reworked, or lost.
2) New applications GUI based – In one situation, I created a program to help move items around in our warehouse. it had it’s own logic, but it also needed to use our warehouse’s business logic. Since that logic was very complicated, it would have taken a long time to rebuild, and probably been very prone to bugs, so I decided to write the program’s logic seperate, and the actual move process using the Rumba session control, and the equivelant of a macro called by the GUI when necessary so that there was no need to rewrite the business logic.
3) Existing application – GUI : One of the processes in our warehouse was very inefficient. it required a lot of repetitive manual typing. I wrote a GUI application that maintained a record of session state, and a couple Rumba session controls to do all of the extra typing for the user, but using the same screens, and background logic. It’s the equivelent of a souped up macro, but it did increas productivity in on of our core functions by 1-200%.

Another option that I’ve heard of, but haven’t actually used is web facing. I know there are some tools that supposedly make it very easy to convert complicated RPG applications to web based applications, but we’re on a system where this hasn’t really made sense for us to do.

I hope some of this helps you make a decision on how you want to handle your project.

Good Luck,

Discuss This Question: 5  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Walter47
    You didn't specify any details about your application. But, I've had success in developing GUI screens using a screen option in DDM. My experience was for web based applications directly on an AS400.
    120 pointsBadges:
  • Leifjacobsen
    We have a development tool called IceBreak, which can be used to web enable AS400 menu's data etc.. Its pure browser based, no clients needed. I re-uses native code written in RPG/Cobol/CL and even C++. The idea is almost like MicroSoft ASP, and any development tool can be used. Read more at:, and try it for yourself, or we can give you a demo.
    0 pointsBadges:
  • Dalejanus
    There is a free tool called CGIDEV2 and/or EASY400. I have not used it, but it may be what you are looking for.
    0 pointsBadges:
  • NarasimhaReddy
    Our application runs on AS/400 with COBOL. We used IBM WebFacing tool to make the application web-enbled. We succeeded this & customer is running application on browser. This tool can be used regardless the programming language what you have used.
    225 pointsBadges:
  • IdratherBEFishing
    Well, this is deep subject. There are so many ways to make a GUI application that accesses data on the AS400. As mentioned in previous posts there's everthing from WebFacing to using using add-on packages such as Seagull where you continue to write software in green screen and the package converts the green screen to GUI that runs under a browser to using any number of PC based packages to create the GUI such as ColdFusion, Java, Visual Basic, etc. Over the last 8 years I have used several. So here's my humble opinion about what I think works best. First What if any experience does the support staff have in maintaining a GUI application that runs under a browser? I say to each his own. There are lots of ways to make a GUI application. In some shops I've seen ColdFusion used very well and in others Java or visual Basic worked well for them. The key here is not only the expierence level but whether the software used allows for good change control management. Dependant on the complexity of the application it is imperative that good change control be an integrated part of the actual panels developed such that you can upload the changes to the server seamlessly and know exactly which version is in use. The next decision is what will serve up the pages/panels. After trying several different offerings from IBM and others I like the simplicity of a Linux server running apache. Linux is very stable and so is APACHE. In 2004 we created a large application that handles between 40,000 and 65,000 concurrent users. Let me repeat that upwards of 65,000 users at the same time accessing the same server and the same data all with subsecond response time. In this shop they had very skilled Java programmers and the GUI pages were written in Java with a little visual basic. The whole was designed to run under an apache server and it ran quite well. You will note just about any server under the sun will support an apache server. So this means the appliaction itself can run on just about any server because of APACHE. In this case the APACHE server was run on 2 separate Unix servers in 2 different locations with fall over and load sharing such that it was designed to split the load so that about half the requests were serviced on a server at a time. All of the requests from both Apache servers connect with only One large AS400/Iseries. The trick here was that requests from the GUI application to the AS400 were all to compiled procedures that were made part of service programs on the AS400. The GUI application is allowed to read files/tables directly on the As400 however anytime the GUI application needs to add or change a record the request is made by calling a procedure on the AS400. This gives full troubleshooting and visibility/control to the As400 side where the data resides. In this particular application we had standard data such as name, address, and account information but also we had over 70 million jpegs of pictures stored on the IFS. On the AS400 there was one and only one procedure/program per table/file. This meant that all requests to add or change a record in a table came through one and only one program/procedure. We set up variables for the call so that we had parameters for each field in the table plus The name of the calling GUI application, the type of change add/change, date and time stamp, and a 512 byte result field. The procedure did a complete check of the data to be sure all the fields met editing criteria. If all was well then the change or add was made and the first bytes of the result field was returned with "success". If any of the edits failed like a duplicate was trying to be added or the state field didn't have a valid state, the result field was returned with "failed" in the first few bytes followed with the name of the failing field and the error message explaining why the update or add failed. This methodology maintains the veracity of the database files. When multiple updates were requested by the GUI application the GUI application is aware when an expected update didn't happen and why. We even developed a procedure using commitment control such that unless all of the updates to several files were successful we wouldn't allow the change to be committed. By keeping the actual adding and changing of data on the AS400 instead of allowing direct writes from the GUI application you make trouble shooting one heck of a lot easier. In addition before we committed to this methodology we found ways where the gui applications when trying to add or change records wasn't as consistant at enforcing data rules and the gui application thought it had updated or added a record when in fact the AS400 had not updated or added because of enforced restraints at the field level. Besides who wants to figure out which one of 20 or 30 panels is the offending page that is trying to put bad data in the files. I know this was long but I thought I'd pass along what worked very well for me. The application I described has now been in Production for 2.5 years and has sucessfully served more than 100 million requests.
    0 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: