Re: Niels IceCap 5250

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

Nathan Andelin wrote:
> > From: Joe Pluta
> > As I get more involved with the Rich UI architecture of EGL, it becomes 
> > increasingly clear that trying to extend the 5250 paradigm is not going 
> > to work in the rich world.
> >     
>
> You seem to be making two points with one statement.  First, that attempting to turn a 5250 application into a rich one won't work.  Second, that a "rich world" is on our doorsteps.
>   
Not "on our doorsteps".  In our homes.  On our desktops.  In our cars 
and our phones and our music devices.

Even in the business world the rich interface is pervasive.  While I 
used to see green screens everywhere, these days it's a rarity to see a 
green screen in any point of sale device or physician's office.  Granted 
a lot of midrange shops still have green screens and for the vast 
majority of pure data entry applications the green screen is perfectly 
valid - in fact, for some applications the green screen is still the 
best device - but that percentage is shrinking, not growing.

> Both points are valid.  But I'm still interested in some continuity, and a gradual transition from 5250 to rich.  And a rich UI is not needed for all applications.  Sometimes a simple prompt precedes a data area update, or batch job submission, for example.
>   
There already is a pretty good transition: 5250 to thin to rich.  
Really, the thin client is not so different from a 5250.  My only 
concern is trying to piggy-back it onto the existing 5250 data stream.  
But if you encapsulate your business logic, you can support first thin 
and then rich without having to change your business rules.  That's the 
real transition path for me.

> The thing that would be nice, would be to deploy both rich and 5250 under a single portal, to support both interfaces during the transition.  One sign-on.  Both environments.  A means of toggling between either.  A means of communicating between both.
>   
That doesn't do much for me.  I'd prefer to have 5250 users and 
graphical users, not make users jump between the paradigms except when 
necessary.  The idea of a 24x80 screen in the middle of a iPhone just 
doesn't do a lot for me <smile>.

Remember, much of what you guys are talking about doing I did a decade 
ago.  I just went a little farther: I took the constant part of the data 
stream and created HTML out of it, and then filled the holes with the 
data from the display file.  IBM took it a step further with Webfacing.  
The problem is that you really can't break out of the 5250 paradigm (and 
by extension the page-at-a-time thin client architecture of JSP or JSF) 
and stay in the block mode of the 5250 program.  I got around some of 
the limitations by using hidden fields, something that you can't even do 
if you use the 5250 data stream.

The only way to provide rich UI responsiveness is to completely 
encapsulate the entire 5250 transaction within a scripting language - 
you basically walk through the screens of the application, plugging the 
data from the incoming message into the fields and hitting virtual 
command keys.  You then have SOA-capable business logic functions.  Some 
of the modernization vendors already do this, but it's fragile and time 
consuming; one seemingly innocuous change to the display file can 
cripple the application.

But I'll watch with interest.  Feel free to ask questions; my guess is 
that you may run into a few issues I've had to resolve already.

Joe