RE: PSC/400 and competing products

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: Booth Martin
>
> In my 'umble opinion all of these kinds of approaches are really only
> attempts to teach a pig to sing.  It's an ugly thing to see and the pig
> doesn't like it much either.

<snip>

> Products like Joe Pluta's product should be looked at, too.  His
> approach is sort of nifty.

Thanks for the mention, Booth.  I happen to agree with you on this issue.
My tool was designed to be a step on the evolutionary scale, if you will,
taking you from green screen to JSP.  This allows you to get your programs
on the web, remove your interactive tax, separate your business logic and
presentation, and develop an in-house JSP knowledge base, all within a very
short time frame and a reasonable price tag.

Any of the screen scrapers are technological dead ends, because those pieces
are always going to require the 5250 data stream (or worse, some proprietary
middleware engine).  With my JSPs, the JSP is as simple as this:

<table>
  <tr>
    <td>Company:</td>
    <td><%= jdspf.getFormattedField("COMPANY") %></td>
  </tr>
</table>

That's it.  Today, you use my middleware to get the data from your old-style
5250 program to the JSP.  But then you can easily rewrite the application to
use a server to popoulate a true data bean.  Just make sure your databean
supports the "getFormattedField" method, and you can use virtually the same
JSPs!

Now, you may never need that - you may be fine staying within the 5250
paradigm (and for lots of functions like file maintenance, it's probably
just fine).  But with PSC/400, unlike any other approach, you have a path to
the future, to true client/server design.

JavaScript on the browser side can be used to do all the even-drivent
processing you might need, and frames can be used for interactive
communications with the host.  I hope to write more about those particular
themes in one of my columns, or perhaps even another book.

Joe