An Engineered Approach to GUI

Until recently, the AS/400 has been graphically challenged. In the mid-1970s, the 5250 series of green-screen display that the AS/400 would eventually adopt were born. The screen's appearance has changed little since its debut except for fonts and color. The major changes to the user's interface were to the keyboard, with pseudo-windowing schemes coming later. However, the usefulness of those schemes was limited because of screen space constraints and the overlay of the green-screen's working area.

Then came various client/server and embellishment schemes. These ranged from using the AS/400 as a file and database server only, to attempts at interpreting the green-screen's contents and decorating it accordingly, also known as screen scraping. These schemes did not achieve the actual goal of creating applications that have truly interactive and intuitive graphical user interfaces (GUIs). Instead, these solutions just danced around the GUI problem, attempting to fool the application user into thinking the screen was easier to use because it was pretty. Clearly, there had to be a better way

As engineers, we decided to create an "engineered" solution. To begin, we defined the requirements from the viewpoint of the technical application developer, the application buyer, and the application user. Next, we bounded the problem by evaluating various approaches that took advantage of the AS/400's features. Then we created a set of specifications, minimizing any compromises to the requirements. Finally, we began building the solution with the plan to evaluate it against our original specifications.

The purpose of a GUI is to provide an intuitive and highly interactive user interface for both new and legacy applications that will provide a user with all of the desired functionality. Users expect applications that offer optimal performance and reliability. They want the data to remain on the host for security and to be able to maintain desktop stability. They also require efficient and easy access to information across LANs and WANs, with the ability to utilize highly mobile handheld computer technology from remote locations.

To that end, the product developer designs products that have simple logic and logistics for reliability and maintainability to reduce both development and support costs. The developer also wants the freedom to continue to develop in his language of choice, thus letting him preserve both his valuable talent and application software logic to create a simple to use application development environment. Developers are also looking to exploit the AS/400 system features and new technologies while creating or using programming components based on open standards. Finally, the developer wants to guarantee the availability of a formal training course.

Taking Advantage of the AS/400's Features

Obviously, the AS/400 has a lot of features, old and new, to sort through, which we did in order to identify those functions that made sense for supporting GUIs. The five that stood out are: RISC processor performance, batch mode's price performance, ILE language model, integrated TCP/IP sockets, and a full Institute of Electrical and Electronics Engineers IEEE) POSIX implementation.

Earlier AS/400 systems were CISC processor-based and showed performance that was inadequate to support a complex windowing protocol. With the advent of the server models, running programs in the batch mode became a bargain when compared to running them in the interactive mode. Other important features required for GUIs became available in the mid 1990s, including the efficient ILE language model, the American National Standards Institute (ANSI) support for ILE C, and the API implementations of POSIX and sockets.

PC windowing systems used on Macintosh and Wintel platforms were designed to be used by a single user from a local, directly attached keyboard and display The AS/400 is a multiuser system and can have hundreds of keyboards and displays. Therefore, a windowing system designed for remote operation is required. Remote windowing schemes can be grouped into client/server and networked categories. Typical client/server methods are either screen embellishers or use split-logic.

Screen embellishers, or screen scrapers, only decorate text screens in an attempt to make them appear graphical. All interactions are buffered, preventing interactivity. This outdated, text only design provided efficient use of low-speed communications but has little effect on making applications more intuitive.

Split-logic schemes are found in environments that use languages such as Visual Basic and Visual C++ to provide the user interface with the AS/400, serving only files and database information. A split-logic scheme requires data to be transported between the client and server, necessitating the invention of additional interfaces and protocols, and allowing true interactivity only with locally cached data. Split-logic prevents any rapid interaction with large databases. Of course, to support multiple client platforms, the client side components must be individually developed.

With major limitations to the screen embellishers and split-logic schemes, there are two networked windowing systems for consideration: Java/HTML markup/browser schemes and X Window.

Applications using the simplistic Java/HTML markup/browser schemes do not have the inter activity found in applications written for either Windows or Macintosh operating systems. Early in the 1990s, IBM considered putting the X Window system on the AS/400, but at the time, the system did not have the features to support the X Window system. X Window was designed to be nonhardware-dependent so that it could work on a variety of workstations. Also, X Window allowed these workstations to communicate interactively and efficiently with host-based applications over a network. Over time, X Window has gained the interactivity of the competitive windowing systems and the AS/400 has been given the features to support it, so we selected X Window for our solution.

The Final Specifications

To create a highly interactive GUI, we took advantage of the AS/400's batch performance and direct access to all APIs. To ensure the user interface would be intuitive, we went back to the original criteria we had defined.  Because all GUI functions should be available directly from the application's primary language, it is important to create a library of APIs. For example, if the logic is or will be written in RPG, only RPG should be used for the complete application. The complete application-specific software must remain on the server for security, optimal performance, simplicity of application design, ease of maintenance, and reliability.

The application also must be available from most workstations without any modification. We found that AT&T's Virtual Network Computing (VNC) software can convert the communication protocol used by X Window to a protocol that can be used by lightweight clients such as mobile handheld computers.

The final solution that we developed consists of a library of approximately 85 GUI APIs named "RPG Graphical Extensions/400." They are all directly callable from RPG. These APIs can be used to create buttons, radio buttons, entry boxes, plain list boxes with or without columns, file hierarchical list and file boxes, notebook style tabs, and more. Their syntax is easily readable and understandable, and their reliability and performance is outstanding.

For proof of concept, we decided to take an existing RPG green-screen application and convert the user interface to a GUI. The original application's user interface consisted of five green-screens implemented with subfiles for the various display lists. The drug information application shown in Figures 1 and 2 now allows medical personnel to search for information in a database containing 32,000 drugs in a GUI format. When the application is started, the first figure is displayed, waiting for the user to enter a drug's name or number. As each letter or number is typed in the text entry box, the list box located directly below responds with the closest match found in the database. When the drug of interest has been found, the user selects it by clicking the mouse. Immediately, the data appears in the tabbed, notebook-style window. The desired view of the data is selected by clicking one of the tabs.

We kept the original logic flow and database access portions and just replaced the source code in places containing 5250 screen I/O functions with calls to the GUI APIs. For the graphics workbench, we used an existing GUI builder that we ported to the AS/400 for the application's initial window layout. We then converted the GUI builder's output to RPG using a software tool we created and embedded into the application source code. The source code was then compiled using the ILE RPG compiler and linked with our API's service program.

Using RPG Graphical Extensions/400, we successfully demonstrated the drug information application using IBM's Network Station, AT&T's VNC mobile access environment, and a wide range of Wintel computers with six varieties of X Window display software.

 Mark W. Brown is a partner in eXport Ventures Corp. He has more than 20 years of experience creating electronic design automation (EDA) and commercial applications for UNIX, Wintel, and AS/400 platforms. He can be reached via email at markb@export-ventures.com.

Robert E. Dubke is a partner in eXport Ventures Corp. He has worked in product and advanced technology development as an engineer and programmer for more than 30 years, including Wintel and AS/400 platforms. He can be reached via email at bobd@export-ventures.com.

[ Home ] [ Up ]

Copyright © 1998 - 2008 eXport Ventures Corporation