Re: Adoption of RPG OA (Summary)

LOL Joe - I've read the doc a lot and still can't absorb it all - there are things about how RPG works under the covers that, knowing a little more, might be helpful.

The state info is not specified in the developer's RPG program - it is only visible to the handler. It isn't extra parameter information - that extra info is in the user information parameter (optional) that is specified on the handler keyword of the F-spec - is that what you are thinking of?

There is really only one parameter passed to the handler - in there are 2 pointers, one called userinfo that points to the optional "parameter", the other called stateinfo that is to be set by the handler to point to a structure or variable the handler will use to preserve state. That second one has nothing directly to do with the developer utilizing the handler - it is completely internal to the handler. RPG engine guarantees that it will return that pointer to the handler on each call, once set.

That state info structure is one of the brilliant pieces - it lets you have file-specific information for each of possibly several files that are open at the same time. This - opening more than one file at a time - tripped me up at first, but now it just works and makes all good!

My comment on architecture was meant in a pretty general sense - not everything will fit into a native RLA-like model. I may have misunderstood your comment about the motivation to use the product. If so, smite me for a fool!!! <VBG>

Many of us agree with you - this would've been fantastic 10 years ago - it might end up being a day late and a Canadian dollar short. I hope not - I think it offers opportunities not easily available before. Still, we shall see.

Vern

On 3/18/2011 5:23 PM, Joe Pluta wrote:

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