RE: Saving the System i: Fight Rather Than Switch

From: albartell

All I can say is that it has been done with RPG DB access.  When we need
to
go out of the box more we can use embedded SQL, but for 95% of the work I
do
I can go the easy route of single record access.  That is how GUI tools
should be built.

Still not doing real well here, so I'll try to keep it brief.  But here's
the basic issue: block mode (e.g., 5250) interfaces are nearly an order of
magnitude easier than GUIs.

For example, when mapping a pure 5250 interface to HTML, you only need three
things: output data, input fields and buttons.  The output data is just
plain old literals, wrapped in HTML such as TD, but just literals strings.
Input fields are just text fields.  Function keys are replaced by buttons.

You might need to add a little bit of JavaScript to actually support buttons
such as F1 and PageDown, and also to set your fields to auto-uppercase or
numeric only.  Other than that, you've pretty much replaced the 5250
interface.

If you go to the next level, you immediately multiply your workload several
times over.  Let's start with something simple: function keys.  First, your
function keys are "defined" with two different things: the CFnn or CAnn
keywords which actually enable the keys, and then arbitrary text to show
which keys are enabled.  Figuring out which keys are enabled isn't too hard,
but grabbing the right text for each key can be a problem.

The function key may or may not have an entry on the screen, and there are
LOTS of programs that use F24 (More Keys) to switch between keys.  That's
not going to be acceptable on a GUI screen.  So you'll need to change your
logic to ensure that all your function keys are sent every time.  You also
need to be able to turn some function keys on and off dynamically, as well
as change their text.  And you may want to disable some functions in the GUI
(for example, if you have a key that invokes WRKACTJOB, it won't work in a
browser).

In the green screen, that's all just literals; they don't actually do
anything.  In the GUI, you have to format the function key in the way the
user wants (is it a standard SUBMIT button, or is it a special hyperlink
with an onclick() method?).  You may want some keys in different places on
the screen, as well.

It's quite complex, and that's just one tiny facet of the game.

Here are some others:

1. Using dots or spaces to position and format prompts, titles and other
literals.  This is simply not going to work in a GUI.

2. Creating long literals with an underline as a heading over multiple
columns.  These literals need to be broken up in to individual headings.

3. Handling popup windows.  You can use a popup window, a modal dialog (a
type of popup window) or use an absolutely positioned table.  Each technique
has its advantages and disadvantages, and you have to choose carefully.

4. Cursor positioning (in either direction).  This is a real hoot,
especially if you allow fields to be moved around the screen in order to
provide a better interface.  No matter what you do, the old row and column
concept tends to fly out the window.

And this is just to get the basic functionality of 5250 into the GUI.
That's why PSC/400 has two distinct modes, 5250 and the advanced version
(iQ).  The 5250 version faithfully recreates the green screen appearance and
requires a lot less effort; in fact, you can convert an entire system
overnight without any additional work.  The iQ tool turns your screen into a
true GUI, but it requires more effort, and in some cases extra programming
depending on the features you want.

Consider the concept of an action code.  We use these all the time on the
iSeries.  You have a subfile where you can type in an action code, such as 2
for edit and 5 for display.  Typically, we allow the user to type in
multiple actions on different rows.  Typically there's no editing from the
GUI; the action code is edited by the RPG code.  Yes, you can use the VALUES
keyword, but that's pretty rare these days, especially since it can't be
changed on a per line basis, which is often the case: for example, one line
on an order might be in a status where it can be deleted, but another line
is not.

While a 5250 user is used to this sort of screen, a GUI user is not.  GUI
users want to see some sort of point-and-click interface, be it a dropdown
or a popup in response to a mouse click.  They do not expect to see
unavailable options in the dropdown (or if they are there, they expect them
to be disabled).  Thus, you need to send a list of available options to
every line, and this is simply not in the bandwidth of the 5250 interface
(even with the newer GUI features).

Adding another twist on this, many GUI users don't even want a selection
field.  They'd rather access one line at a time in direct response to an
option; that is, they click on a line and select "Edit", and the Edit screen
immediately appears.  So, in effect, you need the selection box to not only
select an action code for the line but also to trigger a command key
interrupt back to the server; in fact, in this case, you probably don't even
want a visible action code!  Whereas, if you plan to support the multiple
select capabilities of the traditional 5250, you need an action code and
each selection only fills the action code; the user still needs to press a
submit button after making all their selections.

Again, with our iQ product, we allow you to use any of these techniques.
You can do everything from a standard multi-select subfile to completely
hiding the action code and having a popup menu appear on a mouse click that
selects an option and "presses the Enter key".  You can even have a
combination where a popup menu fills a visible action code without causing
an interrupt.  However, it's a choice you have to make and identifying that
choice to the user interface requires more information than the 5250 data
stream possesses.

I'm not saying that a native GUI is impossible, I'm not even saying it's a
bad thing.  I AM saying that attempting to graft it directly onto the 5250
interface without a lot of careful thought is a bad choice.  We've been
creating web-based GUIs for 5250-based program for many years now, and I can
state with certainty that it's a lot more work than you might think.

Joe