Re: handling handlers in RPG OA

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