Re: Adoption of RPG OA (Summary)

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

On 3/18/2011 2:40 PM, Vern Hamberg wrote:
> Joe
>
> Don't jump to your conclusions too quickly. Have you actually looked at
> the documentation?

Yup.  But I didn't study it in any depth at all.

> The stateful information structure is completely invisible to the RPG
> developer - they should never know anything about it. RPG manages it
> internally so that it can give the address back to the handler for each
> opened file. You MIGHT have a simple optional parameter to send
> handler-specific information. Maybe a WSDL URL. That's trivial. Or
> connection information could be kept in a data area or file member or
> IFS file. No big deal, mostly setup and one-time configuration.

I don't understand this statement.  The stateful information is extra 
parameter information that argues for an interface other than a SPECIAL 
file.  But whatever.  Barbara's statement that you have control over the 
INFDS (I did NOT see that in the documentation, my bad) makes RPG OA 
useful for 5250 emulation.  So there ya go.

> It may be that OA does not fit your architecture - so it goes. OA is an
> option, not a requirement. That it is not good for all applications does
> nothing, IMO, to strike out the motivation to use this product. There
> are ever so many other ways and reasons to use it - not just browser
> display of green screen applications. The possibilities are almost endless.

Got nothing to do with my architecture.  My architecture was designed, 
written, and made public a decade ago.  I just pointed out one of the 
pitfalls I ran across - the INFDS (which I erroneously called the PSDS, 
thus the confusion).  There are many others, to the point where 
developers are not going to be able to write their own middleware; it's 
definitely a vendor tool.  I'd love to see how some of the third party 
vendors do theirs; as I noted, nested popup subfiles (especially 
protecting the underlying fields) is a nifty little problem.

I see definite benefit in RPG OA as a workstation replacement.  I would 
have loved this about 10 years ago <grin>.  If you get a side benefit of 
using READ and WRITE instead of CALL, more power to you, but again I 
consider that very much a niche application.  I'm just not the type to 
use a WRITE statement when a CALL will do.  It's the same reason I'm not 
a big fan of using triggers for business logic.

Joe