RE: It was simply an option for creating thick

["M. Lazarus" <mlazarus@xxxxxxxx>]

Jon,

 I think a big part of the lack of adoption for some most software vendors 
is that IBM did not take the next step in DB transparency.  VARPG should 
not care what DB I want to use or where it is.  This includes printing.  I 
know that I ran into that issue when attempting to create a VARPG app that 
only needed to run on the PC.

 One of the things I love about RPG is the integrated I/O.  I think that 
the focus of having the /400 as a server is great as a first pass (e.g. 
version 1), but by making that a limitation instead of one of the features 
doomed it to be a small niche product.

 -mark

At 9/22/05 09:37 PM, you wrote:
>  >> It was simply an option for creating thick client interfaces that used a
> language most AS/400 programmers were already familiar with.
>
> The other aspect as it pertains to this discussion is that by default VARPG
> accesses the OS/400 DB when you do CHAIN, READ, whatever.  It has limited
> support for handling local PC files other than through an ODBC interface.
>
> Having a thick client that was oriented around the AS/400 as _the_ server
> was a priority in the design and development of the product.
>
> Contrast that with ASNA (map to any DB via their engine); California
> Software (emulates a 400 on a PC), and VB (Windows based DB).
>
> Jon Paris
> Partner400
>
> www.Partner400.com
> www.RPGWorld.com