RE: Call Back information

Concerning the errors, I envisioned using a little of both.  If I was
calling a module's sub proc that had the ability to "throw" a programmer
defined error, then I would initially pass a "handler" or pointer to the sub
proc in my program that I would want it to report errors to.  Here is what I
am thinking:

     QRPGLESrc/PgmA
     CallP   myProcSetHandler('Error':%PAddr(error_handler))
. . .
     CallP   myProc(blah: blah)  //If this errors out it will write the
errors to the proc I specified above.

     for     i = 1 to totErrors by 1

       select
       when    getError(i) = 'Connection Lost'
             ...exit for loop and dsp msg to user
       when    getError(i) = 'Customer Not Found'
             ...exit for loop and dsp msg to user
       when    getError(i) = 'Successful'       
         . . . process completed successfully
       endsl

     endfor




    QModSrc/Error.SrvPgm

     p error_handler B
     D error_handler PI
     D  msg                  50A   value
       . . . fill array with error messages encoutered
             and populate a global variable with total errors
     P               E

     p getError      B
     D getError      PI      50A
     D  index                 5  0 value
       . . . return the next error message
     P               E

     p totErrors     B
     D totErrors     PI       5  0
       . . . return the global variable that holds the total amount of
errors
     P               E

Depending on how myProc implements errors it may only pass back one error,
and in that case you could just do a select statement without the For loop.
What do you think about this approach?  From what I gather this is similar
to how the XML parser for RPG works and I am interested in this approach.

Aaron Bartell

-----Original Message-----
From: Scott Klement [mailto:klemscot@xxxxxxxxxxxx]
Sent: Thursday, February 20, 2003 2:56 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: Call Back information




On Thu, 20 Feb 2003, Bartell, Aaron L. (TC) wrote:
>
> Through your example I am thinking that call backs are directly related to
> procedure pointers and the dynamic routing of procedure calls(it seems
that
> way anyway), correct?

That's correct.

That's all callbacks are... you provide a procedure at runtime to be
called.   This is just a way to allow an API/service program to return
many results... it just calls your procedure for each result that it
finds.

You use a procedure pointer to do this because, at runtime, that's all a
procedure is...  executable machine code that's been loaded into memory at
an address...  and, of course, pointers are the type of variable used to
store addresses.

> We build a lot of external service programs that are then bound to
> calling programs and used as needed.  We are looking for ways to utilize
> the call back concept to talk back and forth between sub procedures in
> the service program and in the main calling program.  We have looked at
> using them for error handling, returning data structures to fill
> subfiles, and other uses that follow the same premise.
>
> Does anybody have opinions on when to use call backs and/or anything to
> watch out for?
>

Well, I wouldn't use a callback for error handling...    Usually when you
call a routine in a service program, you want the next line of code to be
able to detect an error.   You don't want some external procedure being
called...

i.e. this is what you want:

     eval rc = myproc(blah: blah)
     if   rc = ERROR
       . . . handle error here
     endif

not this:

     callp    myproc(blah: blah)

     (and then somewhere else in the code)

     p error_handler B
     D error_handler PI
       . . . handle error here
     P               E


The first example ("the good one") is very similar in concept to using
MONITOR or %error, the second example (the "not this" example) is similar
to using *PSSR.


For other things...  maybe.   I use callbacks in both FTPAPI and HTTPAPI
to allow the user to provide his own procedure that handles writing the
received data to disk, or reading the outgoing data from disk.   This
adds flexibility.

http://www.scottklement.com/ftpapi/
http://www.scottklement.com/ftpapi/

On the other hand, most people don't want to understand callbacks, or even
how to read/write stream files.   So, I provide my own callbacks that do
the most common methods of file reading/writing, and a wrapper routine so
that the user doesn't have to supply any.  (This is the difference between
FTP_get() and FTP_getraw() for example... FTP_get simply calls FTP_getraw
and supplies the appropriate callback)

So, complexity of coding is a big factor in when I use or don't use
callbacks.

Another big factor is the "how will this be used" factor.   If a program
is just going to use the callback to load the results into an array, it
would
be much easier if you just returned an array to begin with.    Likewise,
if a program is going to just set a flag, and it's going to check that
flag right after calling the procedure...  it makes more sense to just use
a parameter or return value.

On the other hand, if you're filling a subfile, a callback might be nice.
You don't need to waste a lot of memory on an array, etc, just call back
a routine that writes the data directly to the subfile.   If the end of
the subfile is reached, a parameter or return value from the callback
can easily be used to signal the service program that it's out of space
and it should stop calling you back.

That's all I can think of to say right now :)

_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.