RE: Custom MONITOR handling

["Steve Richter" <srichter@xxxxxxxxxxxxx>]

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
Jon Paris wrote:
>  >> Is it possible to "throw" custom messages from a subprocedure?
>
> Nope - but I wish it was.  Hopefully Barbara or Hans are watching the
number
> of requests for this feature and we'll see it at some time in the future.
>
> You can of course cause an exception in one of a number of ways but if you
> want to supply your own code you're going to have to place it in a Global
> area or something.

Hans responded:

>John: I'd certainly like to see some improvements myself. But any
>improvements are probably going to work the way Buck described in
>his suggestion. That is, it would have to fit in with the whole
>OS/400 messaging protocol. Of course, a programmer can simply write
>his own easier to use wrapper for the send message API's, and then
>monitor for 1299 or 9999 (or whatever the default message id's are).

>But I'm still uncomfortable with the idea of using message handling
>for this type of thing. Although there are advantages to using a
>message based exception scheme, my own preference in this particular
>case would be to return an indication of success or failure using a
>status code.

I dont follow the problem of fitting rpg exception handling in with the
whole OS/400 messaging protocol.

Here is a way that the "Cee" APIs can be used to monitor for specific
message ids and either halt or promote those that are not monitored for.

Basically it functions the same as message handling in CL.

------------------------------------------------------------------
 /free
      MonMsg_Init( MonMsgCb ) ;
      pHandlerProc = %paddr(MonMsg_Handle) ;
      CeeHdlr( pHandlerProc: %addr(MonMsgCb): *Omit ) ;

  // run some monitored code
      MonMsg_BgnMon( MonMsgCb: 'CPF2817' ) ;
      qcmdexec( 'cpyf a b': 8 ) ;
      select ;
      when     MonMsgCb.SignalMsgid = 'CPF2817' ;
        fSndInfoMsg( 'monitored a CPF2817 message': 1 ) ;
      endsl ;
      MonMsg_EndMon( MonMsgCb ) ;

      CeeHdlu( pHandlerProc: *Omit ) ;

MonMsg_Init is a proc that clears the data struct passed to the exception
handler proc.

CeeHdlr is an ile proc that registers the exception handler of the calling
proc.

MonMsg_BgnMon is a proc that fills the MonMsgCb data struct with up to 10
message identifiers to be monitored for.

MonMsg_EndMon clears the MonMsgCb data struct of its msgids to monitor for.

CeeHdlu is an ile proc that unregisters the exception handling proc.

The MonMsg_Handle proc is called directly by ile. It is the proc that was
registered by the CeeHdlr call.  It basically retrieves the msgid of the
exception that was signaled ( thrown ), checks the MonMsgCb data struct for
the list of msgids being monitored for and proceeds from there.  The proc
returns codes that have meaning to ILE to either PERCOLATE the exception (
unmonitored ) or RESUME ( monitored ).

 ** -------------------- MonMsg_Handle ----------------------------
 pMonMsg_Handle    b
 dMonMsg_Handle    pi
 d InCond                              likeds(CondInfo)
 d pInMonMsgCb                     *   const
 d OutResult                     10i 0
 d OutNewCond                          likeds(CondInfo)

 d MonMsgCb        ds                  likeds(MonMsgCommBlock)
 d                                     based(pInMonMsgCb)

---------------------------------------------------------------------------

Is this not an acceptable way to handle exceptions in proc level rpg code?
The problems I have with it are:
 - a potential performance hit running the setup and take down code.
 - it is cumbersome to code procs this way.

The performance is something the programmer can decide.  The cumbersome
problem can be solved by enabling the MONITOR opcode to implement similar
CEE based code.

Steve Richter