× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



> From: Art Tostaine, Jr.
> 
> Thanks to all.  I'm aware of most of the 3rd party products, but since
> I'm not in that decision, it doesn't really matter.

Art, I wanted to let others answer before I jumped in on this particular
conversation.


> I was hoping to understand for myself really, what a browser based app
> can't do right, whereas a thick client, like Visual Basic, or Visual
> Lansa, can do it right.

The relevant points have all been made already.  Foremost, I think, is
John Earl's comment that the browser is NOT a bad interface.  When I
give seminars, I usually do at least one class on "Business HTML", in
which I show how you can, relatively easily, make a browser do most of
the things we take for granted in the 5250 world, such as auto-uppercase
or filtering non-numeric data or auto-advance to the next field or
recognizing function keys.  At the same time, the browser can do some
things you simply can't do on the 5250, such as dynamically changing
fonts and colors in reaction to user input - WITHOUT making a round trip
back up to the host.

There are circumstances where 5250 is better.  5250 terminals are cheap,
and anywhere you need cheap communication and don't need a PC, you can
save yourself some money.  5250 connections are usually more robust.  If
you don't have special code in your application, losing a network
connection means losing your session and starting a new one.  Type-ahead
from one screen to another is generally not supported in web-based
applications.


> I know that Joe Pluta's product would convert everything on the fly,
> and they would be done, but that doesn't make them .NET.  I wonder why
> they chose the browser instead of C++ (whatever).  I heard something
> they said about the browser making deployment of apps much easier, but
> done right, deployment is easy enough.

No, but it would make them browser-based, and without having to go
through a massive rewrite and retest of their business logic.  As John
pointed out, there are two arguments here: 5250 vs. Browser and .NET vs.
iSeries.

The beauty of the iSeries is that it supports BOTH interfaces.  And with
something like my product, it supports both from the same code.  You
could have heads-down data entry clerks inputting piles of data into a
5250 terminal using the exact same program that a client is using over
the web.  Try THAT with a .NET approach.

And remember, rewriting all of the code in .NET means testing all of it
all over again, whereas converting the existing application avoids some
or all of that potentially long and costly step.  Of the options posed
by Paul, each one has its own risks and benefits along those lines.


> I like the security point.  Their network was down like 2 weeks
> because of Code Red.  Of course, all the TELNET to As/400 apps worked
> fine.

The whole idea of moving my mission critical data to Windows is
frightening to me.

Joe



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.