Re: Adoption of RPG OA (Summary)

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