SEAGULL’s client list included an impressive array of Fortune 500 companies; even IBM was employing SEAGULL’s products when it designed Graphical Access for the AS/400. We would be less than honest if we were to say that this did not influence our final decision to make SEAGULL our GUI vendor.

As primary developers for an AS/400 software vendor, we often have been put in the position of making decisions that ultimately affect our company’s fate. It is not a responsibility we take lightly, and we are painfully aware our decisions haven’t always been right. That said, we are currently feeling pretty good about a particular tactical decision we made some months ago.

Our company had been delivering business solutions for IBM midrange systems since the early 1980s. Our flagship product for the AS/400 consisted of some 2,600 display screen panels supported by almost one million lines of code. Although the product line had gone through numerous upgrades over the years, it still lacked that something special to make it stand out from other competitive products.

As a matter of fact, we were finding trade shows to be a real problem for us. Our products lacked the sizzle and “sex appeal” necessary to draw potential customers to our booth. We needed a GUI, and we needed it immediately.

Even though we were already aware of the importance of having a GUI, the GUI project was usually the first one to be set aside when other important issues, such as Y2K, percolated to the surface. We had already used IBM’s VisualAge for RPG (VA/RPG) to create some pretty impressive demos, but it became apparent that we would have to rewrite major applications in our product line if we wished to take full advantage of that particular technology. This happened to be the case with most GUI tools being offered to the AS/400 community. We had to accept the bottom line. Unless we changed something, it was going to be a long time before substantial parts of our product line were graphical. There just had to be a quicker way.

Walking the Straight and Narrow

We had pretty much settled on IBM’s VA/RPG. We felt it was a product that had tremendous potential, but, somewhere along the line, IBM appeared to have made a substantial shift in its product development priorities. It appeared IBM preferred that we throw out all existing applications and start over, writing applications in Java rather than make a concentrated effort to offer a graphical RPG programming environment. Although we certainly saw the need to begin employing new and burgeoning technology, did we have to throw out the baby with the bath water? Did IBM really expect us to retrain dozens of RPG programmers to use Java? Or were we supposed to create two separate classes of programmers on our staff? That prospect did not bode well for an environment in which we were trying to promote teamwork. And what about our 17-year-old flagship product with its million lines of RPG code? That system still worked very well and was competitive. It just needed a face-lift.

Watch Where You Step

We looked at dozens of GUI tools and products over the years. All of them had shortcomings. Some of the tools were too expensive; others were too difficult to use; and, like VA/RPG, almost all of them required that we begin rewriting our interactive user interface applications from ground zero. In many cases, we would need to begin with our existing database and redesign our applications from scratch, and we were looking at no small job when talking about an application with 2,600 screen panels. Even though most of the tools would allow us to keep our batch applications in place by using “remote procedure calls,” the bulk of our software had been built around the user interface.

Then, there were the “screen scrapers.” These tools had been designed to interpret the 5250 data stream and somehow come up with a GUI equivalent. Some screen scrapers were pretty slick, but they had their problems, most of which arose when we went into any screen panels that were really complicated.

Product longevity was also an issue. What if we were to spend hundreds of thousands of dollars rewriting our applications with a tool only to have the vendor go out of business or simply abandon the product line? Does anybody remember IBM’s RPG platform product that ran on OS/2? After a couple of years of marketing it, IBM decided that it wasn’t going to be such a profitable endeavor and withdrew its support. Those developers who had embraced the product were left with a white elephant and nowhere to turn.

No, we needed a tool that met three basic criteria:
1. It must have a viable future.
2. It must not require us to entirely redesign our user interface designs.
3. It must be easy to use and easy to train others to use. Just weeding out tools that did not meet our three primary objectives shortened the list significantly. As time passed, short-term cost of the tool descended on the list of requirements as surely as long-range benefits moved up on it. With our priorities finally established, it was time to begin our search.

Pounding the Pavement

The first part of the search was pretty easy. We were looking for a vendor that had an AS/400 GUI tool as the primary focal point of its business. We were not looking for a vendor that dabbled in GUI tools part-time. The vendor also needed to have an impressive client list: If it could make Fortune 500 companies happy, it would probably be OK for us, too.

Our second criterion was not so easy to fulfill. We needed a tool that did not require us to rewrite all of our user interface applications from the ground up. For the most part, any tool that met this particular requirement fell into one of two categories: screen scrapers or fourth-generation language (4GL) tools. Generally, the screen scrapers that tried to interpret and convert the 5250 data stream automatically fell short when it came to complicated subfile applications, while those that allowed for any serious customization were pretty limited in what they would allow you to do.

Use of existing RPG programming knowledge was what originally drew us to VA/RPG. It required only two days of training to get us to the point where we were producing viable GUI-driven programs, making VA/RPG an excellent choice if we were in a position to create a brand-new product line. However, that was not our problem. We needed to take our large, stable green-screen application and modernize it enough to ensure that it would remain a force in the marketplace. As much as we liked it, VA/RPG was not the right product for us because we would have to redesign all our interactive programs to run with a GUI.

Using a 4GL product was also never particularly attractive to us because, from our perspective, the code produced was generally pretty weak. In addition, enhancements to the operating system and RPG language were usually not available in the 4GL tools for quite some time after the announcements had come from IBM.

The last of our major selection criteria was ease of use. Generally, this could be determined by talking to customers who purchased the tool and seeing how much training was required before they were comfortable with the product. In a shop like ours that had dozens of programmers, a four-week training course would be cost prohibitive. Tools that were intuitive enough to take advantage of existing knowledge would logically require less training.

During the course of our search, we found quite a few tools that were easy to use, but few met our other selection criteria as well. The longer we looked, the shorter the list became. When push came to shove, we decided to walk the Walk.

Take a Walk on the Wild Side

In the early ’90s, we took a look at the SEAGULL GUI/400, but it seemed too expensive and was not flexible enough to do everything that we needed to do. When we challenged SEAGULL to modernize one of our complicated green-screen scheduling applications, it failed to find a viable solution, as has every tool vendor since.

However, much has changed in the years that have followed. For example, comparing the price and performance of today’s AS/400 to one built in 1990 isn’t really fair, just as the contrast between PCs built in that same time frame is quite drastic. In addition, there are the operating systems, the programming languages, and the Internet! We could go on and on, but the underlying message here is comparing what SEAGULL’s products of the early 1990s could do with what they can do now is also not fair.

When we took a second look, we were pleasantly surprised. The first thing that stood out to us was all the big-name companies on SEAGULL’s customer reference list. IBM chose to use the SEAGULL GUI/400 to write their Graphical Access for OS/400 product, and companies like J.D. Edwards, Marcam, and Computer Sciences Corporation (CSC) Healthcare also appeared on the list. Obviously, SEAGULL had been able to surpass some reasonably skeptical scrutiny in order to assemble such an impressive list. At last count, roughly 4,500 developers worldwide were using its products to enhance and develop their software.

Because software modernization is the primary business of SEAGULL, we felt comfortable that the company would be around for a while, satisfying our first selection criterion.

Our next major issue was the tool’s ability to work with software programs we already had developed without requiring that we rewrite the entire user interface. This was where SEAGULL’s products shined and, in all probability, the reason that IBM chose to use it for their Graphical Access. Both SEAGULL’s GUI/400 and its newer J Walk product could run seamlessly over green-screen applications. They could read the 5250 data stream and then determine which GUI panel or panels to present. The GUI panels presented might be programmed to have functionality and features of their own, which might or might not be independent of the AS/400 panels underneath.

A good example of where we were able to exploit this feature was in a medical transcription product that we wrote many years ago. We designed the product to use the

AS/400 OfficeVision/400 editor because that seemed to be the only option at the time. Because transcription personnel needed advanced editor functions such as formatting, spell checking, and macro capabilities and transcription documents had to be shared and presented throughout the enterprise, our editor choices were limited. With J Walk, however, we could interface our AS/400 data with the Microsoft Word editor and store documents on the AS/400 or an attached network. Moreover, as we did with OfficeVision/400, our AS/400 data was still loaded automatically into the transcription documents, saving work and reducing errors.

We were able to exploit these capabilities even further by introducing graphics files into the transcription documents themselves, and we were also able to present our simple subfiles as business graphics without having to pass any data back and forth. The graphs could be presented in a number of different formats and printed to low-cost PC printers.

Another facet to our choice of GUI vendors was our existing clients. Because SEAGULL’s products translated the 5250 data stream into GUIs, we could run our green- screen product alongside the GUI. Our clients would make the decision whether or not to go GUI. They could go all GUI, no GUI, or mix and match at their convenience. As software vendors, this was important to us because our objective was to attract and acquire new business but not at the cost of our existing clients.

Finally, there was the ease-of-use issue. We chose four of our developers to attend a four-and-a-half day training course. As our projects neared completion, we required no further assistance beyond the initial training. We are not insinuating that this will be the case for all shops, but we have been pleasantly surprised with our results.

Talking the Talk

The best evidence that we made the right choice is the smiles now found on the faces of our marketing and sales people. We no longer send them to trade shows without the tools they need to do their jobs. No matter how good your product and support are, you will not attract much attention if you have the only green-screen software application in the exposition hall.

To see what they are smiling about, take a look at Figures 1 through 6. It is easy to see the extreme difference between our green-screen applications and our new GUI look designed using J Walk. Figure 1 shows what our new GUI AS/400 sign-on screen looks like. Figures 2 and 3 reflect a “before and after” look, as do Figures 4 and 5. In Figure 6, you get to see what can be done with the graphics capabilities of J Walk.

Perhaps Kermit the Frog was right: “It’s not easy bein’ green!” SEAGULL may be reached at 770-521-1445, extension 0. Their Web site address is www.seagullsw.com.

<>
<>
<>

Figure 1: Graphic artist Colin Burroughs designed CPU’s AS/400 GUI Sign-On Screen.

<>
<>
<>