There comes a time when a bold move is required, when an incremental improvement is no longer enough. Our business users require the windowed components of Java Swing and other windowed programs that interface seamlessly with their desktop environments in order to be productive. We can do no less for them. The time has come to say that GUI
isn’t enough!

My experience has been that users want jam-packed green-screens with a lot of data and options and would prefer to have that same data in a real windowed interface with features such as multiple windows and drag-and-drop text editing—not just multiple fonts with little pictures and the drop-down menus of a Web page. Web pages have thus far been designed in a dumbed-down format with multiple page sequences that perform functions in ways that users have not accepted. Comparing a Web page with a Windows program is like comparing a child’s crayon drawing with a Rembrandt. On the other hand, I do understand we can’t develop suites of Windows programs instead of green-screens...or can we?

Using a browser-based interface for the AS/400 has two benefits: It is easy to map green-screen data to Web pages, and a browser is a natural emulator to replace 5250 emulators. What about functionality, though? I have never seen a user opt for GUI-ized green-screens yet, much less Web pages. The reason for the demise of green-screen systems isn’t the lack of a GUI interface—it’s because companies are choosing solutions that are windowed. The same functionality of green-screens in GUI Web pages or emulators is not enough to overcome keystroke-for-keystroke interaction with windowed component interfaces. A GUI isn’t enough.

We in the AS/400 community don’t have the clear interface development direction to perform the fundamental ease-of-use functions that our users expect and that we want to deliver. IBM needs to provide a standard visual interface to the AS/400 in Java Swing. Big Blue should leverage a new technology it developed, Page Description Markup Language (PDML), an Extensible Markup Language (XML) protocol, to display screens with data just as 5250 emulators do, but with windowed components. A smart Java Swing canvas program would render the screens from the PDML description coming from our AS/400 programs and allow us to provide as much windowed component processing as we want.

Java programs are as much an island as browsers or emulators are, however. Part of the bold move we must make is to provide a seamless connection to desktop programs while working with the AS/400. The smart Java canvas program needs to have a plug-in that works through the Java Native Interface to enable the exchange of data with office suites such as Microsoft Office and Star Office under Linux. This plug-in should

implement Microsoft technologies that provide for real-time data updates between programs and update data directly on the AS/400 as a green-screen entry would. Direct access to AS/400 data through a Java Swing interface using our legacy green-screen processing logic must be made available to the desktop environments of our business users for the AS/400 to provide a competitive advantage.

There is another bold move we must make. The program that our business users most rely on to supplement AS/400 business processing is the spreadsheet. We can bring the desktop into the AS/400 interface even more powerfully by creating a new kind of subfile: the spreadsheet. Existing subfiles could display in Java JTables but the new type of subfile would display in an AS/400 spreadsheet component. Data would display from the AS/400 and process against the AS/400 much like current subfile processing works. Macros and other spreadsheet operations would process against the entire AS/400 file or files. Data integrity would constantly improve, as all changes take place online instead of in offline files on desktops. There is no limit, actually, to how much we can integrate AS/400 data with desktop productivity programs and office suite components through the smart Java visual interface. This is the kind of bold move we must make to maintain relevancy for the future. Thick will beat thin. The users say so.