Re: No 5250-based applications

Nathan,

You're not alone in the quest for a browser interface to replace 5250
data streams.

There have been threads about this issue in the past.  There have been a
couple of arguement against it:

1) stopping the user from pressing the browser 'back' button.

I'm no HTML guru, but I have written a couple of pages and know that you
could spawn a window for the 5250 like panel that does not contain the
'back' button.

From what I observe about the browser I use, when it first is fired up
the 'back' button is disabled.  Whatever page you first display is the
only main page ever processed.  All functions would happen in a window.

I know it's not a perfect solution, but it's the only one that I have
been able to come up with.

2) The amount of data that now must be pushed through the pipe.

Even a full 24x80 panel only contains about 1k of actual constant and
variable data.  The same in HTML is about 3k.  This means that your
network traffic will triple.

Some of this can be diminished by use of the browser cache facility. 
For example, on any given 5250 panel, how much is constant and how much
is variable data?  How often do the constants change?  Let the browser
cache the constants and your AS/400 program provide the variables.

3) (related to above) The time it takes to format an HTML page and all
the building/parsing that has to happen to exchange information.

This is one that I'm still kicking around.  What makes the 5250 so easy
to use is that within your RPG program you have an externally defined
file with all of the appropriate buffer mapping and parsing being
handled automatically.

If you use a mapped data queue or message, IMO, that's the same as going
back to internally defined files and you have the program
synchronization problems that RPGII and the S/36 had.  It's not an
impossible task to manage but it feels like a step backwards.

To avoid the above problem you build your entire panel on the fly and
this is where you start eating up machine cycles doing the same thing
over and over.  For example, inserting the variable data within the
constants.  The constants don't change so why should they be processed
every time that panel is displayed?

With this thread on the penalty that a 5250 device plays upon the
AS/400, maybe a goal of reducing the the 5250 workload is more
attainable than eliminating it.  At this point in time anyway.

I'm kicking around the idea of taking the guts out of our interactive
programs and have that workload performed by a batch program.  The
interactive workload becomes trivial and therefore not as likely to
trigger the governor.

For example, in our order entry function we have two main programs for
data entry (there are others but I'll keep it simple for this example) 
The first program adds an order, the second adds line items.  The first
program processes 16 files of which 3 are update/add.  The 13 input only
files could be removed from the program and the data could be delivered
by a batch record server program.  The second program uses 17 files, of
which 4 are update/add.  One of them can be converted into an input file
where the update is handled by a trigger.  The remaining files can,
again, be processed by a batch record server program.

The above order entry function would reduce it's file usage from 23
files to 6.  This goes a long way to reducing the interactive workload,
does not increase network traffic and allows you to stay with what works
until the hardware can catch up with increased demand that HTML would
place on the resources.

For all the threads that have occurred about file server programs, this
use (reducing interactive penalty), is the best justification for it's
existence.  Even at that, I would use it for read only purposes and
still let the OS and the main application program handle updates,
writes, lock contention, etc.

Like I said, this is an idea that I have been kicking around in my head,
but have not tried.  Especially under a stress test.  None of the
AS/400's I support have ever had the governor kick in.  I'm curious what
the interactive workload would be for data queue communication vs
straight disk I/O.  If someone knows the answer to that, clue me in.  If
the workload is similar, and as likely to trigger the governor, I won't
bother going down that experimental trail.  Or maybe message queues are
a better approach?

Yikes! I went on waaaayyy to long. :)  Got to get back to work before
the boss catches me.



"Nathan M. Andelin" wrote:
> 
<<snip>>
> 
> When I reach that point, I want the HTML user interface to offer performance
> and productivity comparable to it's 5250 counterpart.  I think that's
> possible, but depends partly on IBM.  It takes more CPU, memory, and
> bandwidth to generate an HTML data stream.
> 
<<snip>>
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---