Re: Adoption of RPG OA (Summary)

Vern,

Im afraid that you (and the 3 vendors) represent the biggest hurdle on IBM
I,
the OPM (Old Program Model) and OPT (Old Proprietary Thinking) - very
typical for IBM I programmers/companies.

When RPG OA was introduced it was a "feature" you just should buy and
then old RPG programmers could make their old 5250 programs into iPhone
Apps on the fly and hardly without investing any education into it - it was
sold only on the premise that you could reuse the DDS interface and EXTFMT,
READ, WRITE and UPDATE operation codes.

Now, at the scene we have 3 proprietary vendors - with black box
middelware -
to cover the scene - and maybe a few DIY who has the skills to go the whole
way, that is do the RPGLE code, do the handler code AND do the client
code.

Try to sell this concept to youngsters at M.I.T. - they will laugh all the
way out
of the auditorium, that will be empty before your presentation is over!

In fact RPG OA just introduces 2 layes of proprietary layes of middleware,
and is limited into what 3 rater small vendos has to offer in UI.

Tell me how on earth they will have to keep up in the development and
cover the increased numbers of devices - IE, Firefox, Crome, Opera, iOS,
Android ... the list list is actually very long - 5 browsers on stationarys,
6 platforms on mobile devices etc. etc.

Programmers has to give op the "one programmer can do it all" paradigm,
it is simply not possible any longer.

And I fully agree with Joe Pluta, why try to stick to OPM, when any else in
the world gets used to using plugins(classes) and subprocedure(metods)
I can frankly not see the difference in the overall method - and frankly
isn't it a
disservice to programmers that wants to move forward to keep them on
OP-codes
like EXFMT instead of learning them to call subprocedures(methods) that
basically
does the same, but is a lot more in tread of "modern programming".

It is actually a 5 minute learning curve - because a subprocedure call is
like
a CLLE command call - or if any ever has done some javascript coding - the
same!

doThis(parm1,parm2,parm3)

steeeeeeeap learning curve ?

IMHO opinion IBM has missed the target once again - they had the opportunity
with
CGIDEV2 - CGIDEV2 is just much more powerfull than RPG OA even though people
that lives on selling curses and write articles one day on CGIDEV2, then
next on PHP
and the third on RPG OA will disagree.

Had IBM "followed the breeze" back in 1998 when CGIDEV came around and
supported
the project we would now be at release 7.1 and most important had a commen
interface
and a way to do things to web apps on iSeries - and a interface most
programmers would
be familiare with, as a "de facto standard" - but that died with Mel's
retirement - even thoug
Giovannie keeps going on supporting the original code with a few changes and
making great
utilities based on it.

The bottom line is that there is no community around RPG OA - there is no
"new apps" in
the pipeline - its a "dead duck" ....


On Fri, Mar 18, 2011 at 8:40 PM, Vern Hamberg <vhamberg@xxxxxxxxxxx> wrote:

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

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.