Re: handling handlers in RPG OA -- RPG400-L

Vern,

Thanks for taking the time to share your thoughts. I'm sure that *NATIVE can be achieved, but I guess I'd be asking why reinvent the wheel that IBM has already spent many years perfecting. Take an orange, mash it through a blender, hope to find a pip, grow a tree, to get an orange :)

It's the new interfaces (*HTML, *ANDRIOD etc.) that should be where the Handler writers time is being spent!

Crispin.

----- Original Message ----- From: "Vern Hamberg" <vhamberg@xxxxxxxxxxx>
To: "RPG programming on the IBM i / System i" <rpg400-l@xxxxxxxxxxxx>
Sent: Friday, March 11, 2011 7:32 AM
Subject: Re: handling handlers in RPG OA

Crispin

I understand your concerns - and I won't get into licensing, although I
do at times.

The other solutions offered seem to use the handler as a traffic cop.
Now the handler already is a driver for the several opcodes. It could,
however, as Barbara suggested, be a caller for different sub-handlers,
based on a value specified in the second optional parameter - the
user-information parameter. That parameter can have anything you need
that RPG itself does not provide to the handler and that will give the
handler more information it needs to take its course. This parameter
could include a value for what the final destination is - *HTML or
*NATIVE or *ANDROID are just some fanciful possibilities.

Then the handler would call another procedure that has the same
parameter structure as the original handler. Each subhandler would do
what it needs to do.

Now this is all off-the-cuff thinking. I have wondered in all this, how
do I use the original program for native display file processing. I
don't know if I have an answer, because, at first blush, the handler
supports all the opcodes you decide to support. But that support could
itself be selective. In other words, for the *NATIVE option, it could
support only OPEN and CLOSE, eh? Then on an OPEN, the original program
would simply be called as is - no handler keyword. The CLOSE would just
do basically nothing. This is a bit simplistic, I realize.

One problem here is that the handler-version of the original program
night want to get status codes back for each operation - that would be
difficult - or would it? Maybe one could send status through the main
handler back - main handler could receive messages from the original and
store for use in additional opcodes.

I certainly could be over-complicating this - but it does not seem
impossible to make use of the original program.

There is always the option of using the _RFILE C functions that Barbara
mentioned - of course, they can be used in RPG very nicely. They are not
for the faint-of-heart, IMO!

Please, no one take this as definitive - I'm just brainstorming here.

But at least one of the vendors who has a philosophy of multiple user
experiences from one source unit has an answer for this, I'm told. So it
isn't impossible.

HTH
Vern

On 3/10/2011 7:34 PM, Crispin wrote:

Vern,

The only solution I have been offered is a conditional compile, in order to
keep the same source. That means you end up with 2 versions of the programs.
That's just not practical.

I just don't get why no one thought that might be useful. While I doubt it
would have been easy, it surely couldn't have been out of reach of the
compiler team.

As Larry said, the other alternative is to recode the interface bottom up.
OA could have been an option.

I'm not even going to get into the licensing...

Crispin.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Vern Hamberg
Sent: Thursday, March 10, 2011 7:07 PM
To: RPG programming on the IBM i / System i
Subject: Re: handling handlers in RPG OA

Crispin

I believe Jon's printer file example here is about producing a browser
page from a printer file, not printing the result. The ability to either
have it be printed through some OUTQ or to display in a browser - that
is interesting.

The question of overriding the processing, selecting at run-time which
processing stream will be used, was discussed a lot in early meetings
about OAR. It would not be practical, probably, to compile the
developer's program to use the handler OR standard native RPG IO - and
I'm not talking just 5250 - printing does not use 5250, nor does
database IO. Various vendors - there are not many yet! - have solved
this is different ways, I believe. You had some replies on the thread to
which you refer from one of them.

So we move forward. This is an intriguing and beguiling and frustrating
new technology. So what else is new with innovation?

;-)

Vern

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