Re: handling handlers in RPG OA

Larry

I agree - there are several very nice surprises I found when writing a handler. Sending back the appropriate status for the update without prior read is cool. There are other issues around that which I've had to address, and have found solutions for, with the generous help of the IBM developers and partner support.

The mechanism for linking state info with an opened file is also a lovely surprise, makes multiple file processing quite manageable.

Vern

On 3/10/2011 3:06 PM, Larry Ducie wrote:

Hi Vern,

<snip>
Would that not require using APIs to do the 5250 stuff? Or am I missing
something? Easily enough the latter!
</snip>

No APIs required. Your handler (if running in an interactive job) can easily have a display file attached - or call a program that does.

I have a couple of guys doing some research on handlers at the moment and they have a display file in a test handler that pops up a window detailing the request made and the parms passed. This was so they could check out what happens as you proceed through a test program.

Got to say - the OA routines are pretty slick. The two top features they discovered but didn't expect are:

1) The handler is called to close the file if you return from your program with *INLR on. Obvious when you think about it but it did get them excited when it happened.
2) If you get an update request and you didn't do a 'prior read' the RPG will throw an exception if you tell it you can't update. Again, as you would expect. But still nice to see.

I would certainly join the calls for a conditioning function (indicator??) on the handler keyword. We have talked about 'enabling' our programs for other output types - offer a HTML version of some screens for example. But it seems to be an all-or-nothing approach with handlers. We either have the 5250 screens or we have the screens in another form via OA. We can't (easily) have both. This is important for us because if we do decide to keep the original programs then writing a clone for OA (using compile directives) would be less preferable than simply writing a new CGI program to offer a HTML equivalent.

I would put the conditioning requirement ahead of any modifications to (as a random example plucked out of the air) program described printer file functionality - do we still use printer files?</grin>

Cheers

Larry Ducie