Re: Adoption of RPG OA (Summary) -- RPG400-L

Joe

Don't jump to your conclusions too quickly. Have you actually looked at the documentation?

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.

In the documentation, mention is made of the AID byte - I assume, not knowing any better, that this should provide that functionality - much of what happens is a combination of what RPG normally does, combined with things it does in reaction to events sent to it. As an example, some illegal IO combinations are stopped by RPG before they even get to the handler. The RPG status is set by the handler, and RPG sends an RNX message with that status, as it does now.

I do not think a short succinct statement such as you presented - that that will do to talk about this.

I doubt that ASNA will tell anyone HOW they do things. I have a slight idea of what Profound Logic does - the stuff they will explain publicly, that is. As for ASNA, WINGS is built on their Monarch architecture - it says that on their site. If you have seen that at work, you'll know what they are about so far as top-level behavior, anyhow. I've never seen it in action, so that's all I can relate.

All 3 modernization vendors have solved the issues you present, and have done so before OA came around. All 3 build on the principles they've used throughout their respective histories. You've done something similar with modernization - there's probably no reason you could not wrap your app in an OA wrapper and further simplify what developers need to do.

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.

Eh?

Vern

On 3/18/2011 2:01 PM, Joe Pluta wrote:

So the answer is "it cannot handle the cursor position in the PSDS". And
thus, every program that uses the PSDS for those sorts of things must be
rewritten - that includes all those programs that check the AID byte.
I'd love to see how well WINGS handles nested popup subfiles, but at
least that can be handled in the middleware (it ain't easy, but it can
be done). The PSDS is nearly impossible to work around - I should know,
it took me a while to do it in my PSC product, which did what WINGS does
about 10 years ago :).

You talk about using a stateful information structure - at that point
you've pretty much canceled out the primary motivation for the entire
RPG OA concept, which is to make it easy enough for people who can't
program a parameter list. I'd rather teach them how to write their code
as callable modules and use a true multi-tier design, but that's just me :).

Joe

For those who've not looked at the OA documentation, there is a data
structure passed to the handler. It contains a subfield for rrn - this
can be set by either RPG or the handler. There are also pointers to the
3 file feedback areas. AID bytes can be set there, for example.

The only thing we can affect directly in PSDS is the RPG status code, as
I remember. So far!

If a handler needs some kind of pseudo-cursor handling, it can keep that
in a stateful information structure whose pointer goes back to RPG and
is handed back again on successive calls of the handler.

WINGS uses the ASNA Monarch architecture - based on ASP.Net objects that
are generated from something on the IBM i, so far as I know. Then
developers work mostly with the ASP code.

That's about all I know - and actually a little more than I know,
probably. Maybe they ignore cursor position or replace it with something
to achieve the same end. I find that the details deep down are almost
irrelevant - the key thing is to understand top-level behavior - that
has let me write a DISK-style handler and cover everything with it.
Basically, make it behave at the programmer's level of use the same as
it does in native RPG IO, then it's all good.

Regards
Vern

On 3/18/2011 1:07 PM, Joe Pluta wrote:

How in the world does WINGS handle things like cursor position in the PSDS?

Joe

We are using ASNA WINGS, and it is true, other than best practice for the
HANDLER keyword, I don't need YALL/YINS much.
ALL of the rest of our work will be done in VS2010. Java Script HTML Code
behind language, deployment, manage projects in the studio.
We are hoping to leave the RPG untouched except for the HANDLER keyword.

Tom Deskevich
No stupid salutation