Re: Niels IceCap 5250

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