RE: VARPG, VB and WebFacing

This is a huge question, John, and one which I have a vested interested, so
be sure to take my opinions with a grain of salt.

There are three basic architectures: client/server, server/client (or
redeployment) and remote database access (such as ODBC).  Redeployment means
taking an existing green screen program and adapting it for a graphical user
interface.  A true client/server approach, on the other hand, involves
designing servers which run on the AS/400 and are accessed from the client
via messages of some kind.  The third architecture, remote database access,
in which your actual business logic resides on the client, is one I highly
recommend against, for reasons ranging from performance to security to
database integrity.

To decide the correct approach, there are three questions, two of which are
specific to your own company, and one which is more general is nature.

The first specific question has to do with your deployment model.  Do you
want applications that can be deployed both as green screen and as graphical
clients (thick client and/or browser-based)?  If so, you want to take a look
at one of the three basic tools for green screen redeployment: screen
scraping, web facing or revitalization.  There are pros and cons to each
approach.  If, on the other hand, you want a purely graphical solution and
want to take advantage of things like multiple windows and drag and drop,
you probably want a client/server design.

The second specific question concerns what kind of skills you currently have
and which you want to build.  If you are primarily an RPG shop and your
developers are most comfortable with green screen applications, they will be
more productive, at least at first, in a redeployment approach.  They can
then eventually move to a client/server design.

The general question is one of architecture.  If you are designing an
application that in any way updates your database, I very much argue against
ODBC connection of any kind.  Even if you manage to get around the pitfalls
of performance and security, you still have the issue of changing business
logic.  If for any reason your business rules change, you must then update
the database logic on ALL your client machines simultaneously.  This can be
done, but it requires a lot of logistical coordination.  And if you miss
even a single client, the damage to your database can be significant.

If you have a query-only application, you may want to use ODBC; it's fast
and easy to implement, especially when you have SQL-capable staff.  But the
downside is that if your database layout changes, all of your client code
has to change as well.  By using a message-based client/server design, you
can insulate yourself from database changes quite effectively.  Another way
to insulate yourself is to use servlets and JavaServer Pages and a
browser-based interface.  This way, all your logic resides on the host, and
there is no need for any client software.  The primary limitation there is
the complexity of the graphics available.  But a major plus for this
approach is that any Internet capable machine now becomes a potential
client.

So, my recommendations are as follows:

1. If you have existing applications that you'd like to see on the web, a
redeployment approach is best.

2. If your programmers are very comfortable with green screen design and you
want your new application to run both green screen and GUI, then
redeployment is again a good choice.

3. If you want simple graphical applications, use servlets and JavaServer
pages in conjunction with a browser-based interface.  The architecture of
the servlets depends on the complexity of the application, and can be either
ODBC or client/server.

4. If you want robust graphical applications, use a thick graphical client
on the workstation which communicates with the host entirely through a
message-based client/server approach.

If you have any questions, feel free to ask, visit my website at
www.plutabrothers.com, or drop me an email.

Joe Pluta


> -----Original Message-----
> From: owner-midrange-l@midrange.com
> [mailto:owner-midrange-l@midrange.com]On Behalf Of John Bussert
> Sent: Friday, June 15, 2001 9:32 AM
> To: 'MIDRANGE-L@midrange.com'
> Subject: VARPG, VB and WebFacing
>
>
> Hi all,
>
> We are in the process of prototyping some apps in a graphical mode (x
> 5250 apps).  We have tried VARPG, and VB.  Not yet the webfacing tool.
> I have my own ides on these based on our experience, but would like to
> see what others are thinking?  The questions are thus:
>
> Other than VBs wide use on PCs is there an advantage over VARPG to use
> it?
>
> If the app will call programs on the 400 directly to do some processing
> (APIs as an example) does VARPG make more sense.
>
> With the restriction of requiring DB2 Connect on each deployed PC, would
> it make more sense to use VB with ODBC?
>
> Is the performance of VARPG faster than VB with ODBC?
>
> Is anyone using VARPG?,  If so, are you using embedded SQL?  Or
> generating Java with it?  (by the way you can't use embedded sql with
> Java since JDBC is not supported - or at least not anywhere we have been
> able to find)
>
> If there were good Java Tools (which I have not really seen yet) would
> that be a better approach?
>
> Are there any other questions / issues that should be considered as part
> of this?
>
> Thanks
>
> john
>
> John Bussert
> jbussert@swiftorder.com
> 847-289-8339
> Swift Technologies, Inc.
> www.swiftorder.com

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---