× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



thanks Simon.

>>Basically I want a proc to throw an exception and the calling proc to
catch
>>it.

>You can do this using the ILE Condition Handler APIs. Conditions are a
>platform independent way of handling exceptions and mapp to AS/400
exception
>messages. You write a procedure to handle the condition then you call
>CEEHNDLR to register your interest in the condition. There are a heap of
>APIs to manage conditions. See the ILE CEE API section of the
>pseudo-information centre.

Ok, I have done the reading and I think I understand how condition handler
APIs work.  This link explains them pretty well.

http://www.midrangeserver.com/mpo/mpo081502-story05.html

Basically a condition handler proc is registered to handle ALL signaled
conditions of a call stack entry ( running of a proc ).

When the condition handler is registered ( CEEHDLR ) a pointer to error code
data struct in the registering proc is provided.

When a condition is signaled ( CEESGL ) to a call stack entry the associated
registered condition handling proc is called. The cond handler proc
interprets the error id ( token ) and either
  - sets the error code variable and returns RESUME or
  - returns PERCOLATE or PROMOTE when the exception ( condition ) is not
handled.

It looks like an *Escape message send to a call stack entry auto signals a
corresponding condition.

So putting aside the condition handler proc, the running/monitoring proc
does the following:
  RegisterHandler( pHandlerProc: %addr(ErrorData) ) ;

  DoSomethinProc( a: b: c ) ;
  select ;
  when    ErrorData.MsgId = 'ABC0010' ;
  when    ErrorData.MsgId = 'ABC0020' ;
  endsl ;

  UnRegisterHandler( ... ) ;

The missing piece is the need to register ( monitor ) for specific error
codes in the monitoring proc. Otherwise we are back where we started, where
an error return code can be ignored!

  InitErrorHandlingComplex( ErrorHandlingComplex ) ;
  RegisterHandler( pHandlerProc: %addr(ErrorHandlingComplex) ) ;

  MonitorError( ErrorHandlingComplex: 'ABC0010': %addr(ReturnCode)) ;
    DoSomethinProc( a: b: c ) ;
    select ;
    when    ReturnCode = 'ABC0010' ;
    other ;
    endsl ;
  UnMonitorError( ErrorHandlingComplex ) ;

  DestroyErrorHandlingComplex( ... ) ;
  UnRegisterHandler( ... ) ;

The "ErrorHandlerComplex" is a data struct passed to the condition hander
proc that contains the error code info and also a list of errors being
"monitored" for. If the error is not in the monitor list, then the handler
will PROMOTE/PERCOLATE the signaled condition up the call stack. Otherwise
it sets the error code and returns RESUME.

The bottom line is that a lot of code is needed to properly call a proc that
uses CEESGL ( signal condition ) to signal its exceptions.

But if IBM and the RPG team would provide some openness to the RPG compiler,
all the messyness described above could be avoided. What is needed are three
new opcodes:
  - UserMonitor
  - EndUserMonitor
  - On-UserError

UserMonitor is a macro like instruction.  It is replaced with
  InitErrorHandlingComplex( ... )
  RegisterHandler( ... )
described above.

EndUserMonitor is replaced in the code with the condition cleanup code:
  UnMonitorError( ErrorHandlingComplex ) ;
  DestroyErrorHandlingComplex( ... ) ;
  UnRegisterHandler( ... ) ;

On-UserError is a little more tricky in that the
  MonitorError( ... )
stmt has to be massaged and inserted up with the UserMonitor code
and the "On-UserError" part has to be replaced with a "when" stmt.

The end result being:
  UserMonitor ;
    DoSomething( ... ) ;
    On-UserError  'ABC0010' ;
      HandlerError( ) ;
  EndUserMonitor ;

which properly handles exceptions in an as400 and ile way.

Steve Richter
AutoCoder, LLC



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.