RE: DDS Screens To Java

> From: Hall, Philip
>
> Although this route doesn't create 'Java screens', it generates
> HTML on the
> fly and caching seems to be non-existent...
>
> BTW: Java screens in my book would be a (JFC)Swing interface.

That's an important point, Phil.  A "Java" screen to my mind is a
thick-client Swing application running on the PC, as opposed to an HTML
interface running in a browser.

The other issue is whether you actually convert the RPG programs to Java.
Currently, all commercial solutions that I am familiar with leave the
application written in RPG.  They either modify the application to use a
different interface, or screen scrape the 5250 data stream.  The former
reduces your interactive requirement, the latter requires no modification to
the code.

There are several HTML vendors (myself included).  A commercial conversion
to HTML using one of these tools currently starts at around $20,000,
depending on the size of the application and the size of the box.  There is
also a variable amount of consulting required.  The RPG programs stay as RPG
programs, but the interface is HTML.  Some of these are screen scrape
solutions, some use program modification.

There are also a couple of thick client vendors.  The last I heard, Jacada
has both a screen scraper and a program modification interface to thick
screens.  Linoma Logic (whom I partner with) provides a product/service
offering designed to help you move your applications to a client/server
architecture that supports a thick-screen interface.

The other options are to roll your own, using e-RPG (Brad's technique),
e-deployment (my technique), or Nathan's relational data framework.
Nathan's is the only one with a license fee, but his is the most complete of
the three.  Both e-RPG and e-deployment are more of a technology concept
than a product.

Joe