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

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