From Textual "Green" To Graphical Presentation Of 3270 and 5250 Terminal Screens

From Textual "Green" to Graphical Presentation of 3270 and 5250 Terminal Screens:

Market statistics make it clear that text-based applications continue to dominate a large number of computer terminal screens worldwide and will do so for at least the next several years to come. And a cursory glance at the sales figures of mainframes suggests they won't disappear anytime soon either. Therefore, it is useful for IS managers to consider what approaches are available to add modern functionality to applications which may be perceived as "dinosaurs", but which nevertheless continue to run (and run quite well in most cases) many important institutions like governments, banks, insurance companies, hospitals and transportation. Thus, the current drive to make host applications accessible as graphical applications on intranets and on the Internet is both important and self-evident.

How to accomplish this conversion has been narrowed to three principal approaches: (1) the use of development tool kits; (2) the use of knowledge-based approaches, and: (3) the non-programmatic approach.

This approach is based on delivering to customers the traditional "green" screen emulation software with optional tools to make it "easy" to develop GUI screens. These tools may consist of AP's that simplify HLLAPI calls, or in a more advanced form, some "wizards" that produce VB or Java code where the users just "paint" the screens (form) using various objects from the toolbar. Some "wizards" provide the default form by connecting to a "live" terminal emulation session and converting the unprotected (input) fields into edit control objects while turning the other fields into labels. More advanced versions convert a set of predefined strings like F1,… F24 into buttons-- the popular "hot spots".

Typically these tool kits include a tutorial that walks a user through the process of customizing a simple screen, usually the very much familiar SIGN-ON screen. The whole process is normally accomplished in a relatively short time (under 30 minutes), thus supposedly offering proof of how simple it really is.

In the construction business this approach would be analogous to a lumber company selling a set of tools to unsuspecting customers, with a model of a doghouse that can be put together under one hour by persons without prior experience.

The reality, of course, is quite different. A real house is very much different from the dog house model. It has windows, plumbing, wiring, etc. The fancy wizards have a hard time distinguishing a literal on a screen from a protected output field, such as time and date stamps in headers. It usually takes a few days until somebody notices that the GUI screen always displays the same time and date. But this is just the beginning. Later on users discover that some input fields are much longer than 80 bytes. One good example of this is the command area on the system menus of the AS/400 system. Later in the project users discover that some fields change their attributes and formerly protected fields suddenly become unprotected and vise versa. In addition, crowded screens require much more space in a graphical representation than the green originals. In the end users give up working on the project and either cancel it, or hire professional "contractors" to do the job.

These hired contractors then typically try to expand the project by offering some "re-engineering" elements to the process, like combining two screens into one form, breaking up "busy" screens into a set of simple ones, etc., making the entire endeavor a costly, time consuming project.

From the technological point of view each user screen becomes a program that contains some of the business logic. It has to be maintained by the original contractors to keep in synch with changes in the legacy application. Additionally this approach is inefficient in the Internet environment where the client is working from a WEB browser. In the Java environment classes are packaged for delivery into cabinets (for MS Internet Explorer ™ or compressed (ZIPped) for Netscape's Navigator ™. The size of the Java applet has to be kept under a reasonable limit - under 1 Mb. This requirement forces the end users to break up the application into manageable chunks, which may not be easy to accomplish all the time. In addition, the user is forced to rely on the browser's cache mechanism when calling the same programs over and over again in order to avoid constantly reloading the huge applets with the associated delays.

This reliance on the cache mechanism of the WEB browsers may conflict with the network administrator's policy against caching HTML pages that may contain passwords.

This approach relies on access to source files of the screen maps for the legacy application. In some cases (e.g. GUI/400) a special program runs on the legacy platform and analyzes the screen (display) files in the compiled form. In any case, the result of this "intelligence gathering" is some sort of screen "album", which serves as input for the second phase--creating templates and refining them. For example, an occurrence of a string "F3=Exit" is deemed a good candidate for a replacement by an "EXIT" button, which, upon pressing, sends the F3 key to the host system.

Some products (e.g. GUISys) work with an extensive set of more than 700 rules-based pattern definitions associated with green screens and corresponding graphical interfaces. The end product is generated code, typically VB or Java, which brings us to the negatives of the first approach regarding business logic and size of the generated applets.

By having access to the display files or their original source code, some of the "gotchas" are avoided. Since the program can tell the difference between an output field and a literal, it knows which fields can be protected in some situations and unprotected in others.

The principal drawbacks of this approach are a long, steep learning curve and the need to do all screens in one shot - it is an all-or-nothing approach which requires freezing the maintenance of screens for the duration of the project.

A range of new products are beginning to emerge that deliver GUIized screens on-the-fly without involving any kind of programming or scripting on the customer's site. The extent of transformation from a textual "green" screen to a graphical is typically limited to the conversion of input fields into text edit objects, as well as converting easily recognizable strings containing references to function keys into button objects--the ever popular "hot spot" approach.

There are major advantages to this approach. The main one is the delivery of immediate results across the board, meaning that all screens, not just the selected minority, have the same look and feel. The second advantage is the minimal risk in regard to corrupting the host legacy application - no business logic is embedded in the solution.

The drawbacks are, of course, tied to lack of user's ability to do any customization outside the global scope where the users may have some limited options in choosing default colors, fonts, etc. There are no options to deliver services to a field level, like hiding some unused fields, translating the labels (screen literals) to a more meaningful expression, and no way to attach field context help files or list of valid codes.

This is the approach used by Advanced Transition Technologies, Inc. in their suite of ResQ! products. In addition to delivering GUI-on-the-fly "out of the box", these products allow end users to further customize the look and feel of the resulting screens, as well as delivering services to particular fields on particular screens. The approach is based on proprietary patented technology and does not involve any programming or scripting, either directly by the user or indirectly (by generating code behind the scene) for the user.

This approach provides all the benefits of a GUI "on-the-fly", including a small-sized applet as well as the benefit of being able to provide screen maintenance during the customization process. The ability also exists to customize down to the object level on every individual screen, in order to provide very intuitive, user-friendly screens that are much faster and easier for end-users to move through. Included are such capabilities as reordering the workflow, resetting tab orders, hiding fields, and creating group boxes that clearly delineate actionable areas from informational ones. Further, this approach significantly reduces the opportunity for input error by creating such devices as macros, check boxes and field descriptions and literals in native languages.

A further advantage is the minimal risk that this approach poses to the host application. No business logic is embedded in the solution. Since no code is generated behind the scenes, screens don't need to be rewritten when a change is made to the host application, as would likely be necessary under the knowledge-based approach. When an additional object is added under this approach, the screen automatically reverts to a default GUI which permits an administrator to easily reimport everything that is still relevant to the screen.

Importantly, this is not an "all-or-nothing" approach. One may customize individual screens over and over again, or not at all in the case of infrequently used screens. Because the process is all point-and-click, office administrators can be trained to do the customization work, meaning that rolling out a fully customized host application into a true Windows application will be much faster, and far less costly than any other approach that undertakes to do more than paint a more cosmetic front end.

Approaches generating programs per screen can accomplish the goal with a reasonable amount of effort and time. The drawback, however, is the need to maintain two sets of programs: in a dynamic environment where the host application is changing, two sets of development environments have to be synchronized. Further, screens that aren't customized under these approaches usually default to green screens, creating a jarring effect. An example is IBM's latest release of Client Access, in which AS/400 user screens are not GUI at all while the systems' screens are. The downside with applets generating code or script is that they also require far larger bandwidth, for in addition to the data stream per screen, programs/applets have to paint them as well.

The most efficient and least risky approach available today is the GUI "on-the-fly" without any customization. It is the most efficient because it delivers more graphical-looking screens without adding any additional services, and provides a persistent connection to the host in the event that changes occur to the underlying application. It is also the least risky since it carries no business logic. Finally, in terms of financial risk, it is limited to the cost of purchase.

About the author: Todres Yampel is President and COO of Advanced Transition Technologies, Inc., (AT2), a New York-based software development firm. AT2 provides legacy life-extending tools including (1) ResQ! for Windows, an intelligent front-end client that builds true Windows GUIs without programming, and which accommodates a rich set of plug-ins, and (2) ResQ!Net, a Java applet that automatically presents host applications as Java browser applications, with an optional customization module for extending the application's functionality. Mr. Yampel is the inventor of the patented screen recognition technology on which AT2's product range is based, and has been a senior executive with the CSI Complex System family of companies for 19 years.

©2003 ResQNet.com
All rights reserved. Contents herein may not be reproduced in whole or in part without written permission of publisher.
ResQNet.com. 33 Maiden Lane 8th Floor, New York, NY 10038 212-482-8080 Ext. 4816