Re: Adoption of RPG OA (Summary)

Hi Henrik,

<snip>
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!
</snip>

I teach ILE and RPG to our graduate IT intake each year and RPG itself is a difficult pitch. This is not unique to RPG OA.

<snip>
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.
</snip>

This is only the case if you purchase RPG OA and a Vendor product for the express purpose of"modernizing the UI". I installed RPG OA for the purpose of evaluating of the product itself. At present we have no intention of purchasing a Vendor product. You are falling into the trap of thinking that RPG OA would only be purchased as part of a vendor bundle. This is not so in all cases.

<snip>
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.
</snip>

This is a universal issue about providing content to client devices over the web and has nothing to do with how your RPG program interacts with the handler. Do you think an app written in java and running inside tomcat, serving pages through an instance of the apache http server running on unix/linux box would avoid these issues? It wouldn't.

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

I agree with this 100%.

<snip>
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".
</snip>

RPG OA is simply one tool. It doesn't replace evey other tool you have. Pick the most appropriate for the job. We bulit a test-case to geocode / reverse geocode an address via a simple chain. It worked beautifully. I see THAT kind of RPG OA usage as simple and elegant.

<snip>
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 ?
</snip>

100% disagree. It can take more than 5 minutes to teach BASIC procedure calls.

You've got 5 minutes to teach:
Basic procedure design.
Passing options: how to code safely when using options(*omit:*nopass).
The difference between passing by reference, constant reference, and value.
Return values.
How service programs work, binding by reference.

Many, many experienced programmers don't even know what causes a service program signature to change - or even (more dangerously) that you can completely change an interface and the signature does NOT change.

This is why we DO teach our developers these things, and it takes a little longer than 5 minutes to teach it all. :-)

<snip>
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.
</snip>

I disagree again. IBM implemented the Common Gateway Interface (CGI) to allow developers to build code to be called from a running HTTP server. In my opinion that is where IBM's responsibility ended. It was up to vendors and us "the community" to take it further. It was we who dropped the ball 10 years ago, not IBM. To do my part to address this I am just completing a simple RPG program that allows XMLi templates to be run as server pages - via CGI calls from the HTTP server. That is, the page stored in htdocs and is simply accessed via a URL (the page runs the RPG code - not the other way around - and doesn't need recompiling). I state this because I believe it will make serving RPG pages "effortless" and if IBM had built their codebase over a specific implementation (CGIDEV or otherwise) of CGI software then other opportnities (like this one) are lost.

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

We are the "community". It lives or dies at our hands.

Cheers

Larry Ducie