Re: How to create my own built-in functions

> Scott,
> 
> Just a question, not a critique ....
> 
> IBM uses return values and return reasons.  How much different code
> would be required for a boolean return value and of not x, investigate
> the reason code?
> 
> My purpose in asking is that I am working on some procedures that will
> result in a return code (0/1 no/yes not/successful fail/pass) that I
> want to have the boolean response evoke the process of a 4 char reason
> code that just coincidentally becomes the 4 digits of the message
> identifier to display to the user.
> 

First of all, I consider using activation group imports/exports to be
sloppy programming.  (Thats just my opinion, but I'm sure someone on 
this list will tell me how wrong I am...)  So, I wouldn't want to code
something like the "errno" fiasco commonly used in C.

The next option would be to pass an error code structure to every
procedure in every service program.  Similar (or the same as) the
"QUSEC" structure used in APIs.   Personally, I find this method
workable, but awkward.  To me, the more parameters passed to a 
subprocedure, the more difficult the code is to follow.

The third scenario would be to have a subprocedure within each service
program that you can call to retrieve the error number that occurs.  And
maybe even have an optional parameter to retrieve a "human readable"
description of the error.  I like this method, and have used it in the
past...  though I'm usually too lazy to implement it :)  

(I realize that you'd probably use a MSGF to store the human readable
text, which works great for an AS/400, but I also do some UNIX and Windows
programming, where no such animal exists...  But this doesn't really
change the design of the procedure, you'd just retrieve the message
description from the message file, and put it into the optional variable)

> IMHO, a boolean response is a simple branch.  One value, one if/or.  
> I understand your test IFLE/ELSE is a single test, but you've embedded
> reason within response. It appears that you've applied dual usage to a
> single value.

I don't think I've applied "dual usage to a single value."  It tells you
the return status of the procedure...   
 
The problem with boolean return values, as I've said before, is that there
is often more than one "successful" return value.  If you return
"True/*On" when there were no errors, and "False/*Off" when there were
errors, what happens when there is another possibility?

The example I used before was fetching an order (or perhaps even simpler,
fetching a record from a file) You can have 3 return values, "Record
Found", "Record Not Found" and "Error".  Thats without listing the
specific error messages! 

What about a procedure that gets I/O from a user.    
I like to set up my screen I/O so that I could simply replace the
procedure with another one to make it do something other than a display
file for user interaction.  Allowing me to change it to be program driven
or client/server or whatever at the drop of a hat.

Would you have seperate variables for "success/fail" (boolean), "exit
status" (F3=Exit, F12=Cancel, etc), "error code" (error reason code) 
as well as the data returned?  That'd be a lot of parameters to the 
procedure!

I'd rather just check the exit status.   I could have 3=User wants to
exit, 2=User wants to back up a screen, 1=User entered data and pressed
enter/continue, 0=User didnt enter data and pressed enter/continue plus
negative values for errors.   Then I can define constants in my /COPY
header file that describes the return values.  Something like RC_EXIT,
RC_BACKUP, RC_DATA, RC_NODATA, RC_ERROR and make the values seem more
meaningful in the mainline.

> Is there some restriction that you are operating under that prevents dual
> feedback?
> 

Not a restriction.  A preference.  I've done it other ways as well, and
your "dual return value" method also works (if implemented properly) but
it requires a bit more work, and then you have to make things like "record
not found" and "Exit key pressed" be error codes, which it always seemed
to me that they shouldnt be...


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---