× 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.


  • Subject: Re: Multiple parms to procedures
  • From: Hans Boldt <boldt@xxxxxxxxxx>
  • Date: Fri, 17 Jul 1998 09:00:19 -0400

David Morris wrote:
>You can only return a single value from a procedure.  However, that value
>can be a data structure.  I would recommend against using a data structure
>for this purpose because it is not as flexible as multiple parameters.  If
>a routine can receive an error I reserve the return variable for an error
>flag, unless a single value is returned which can be evaluated to determine
>if an error has occurred.  IE:  If a product ID cannot be blank then I
>would return product number directly in a GetProductID procedure.
>
>I code input parms with CONST or VALUE where possible which is about 98% of
>the time.  The exceptions being variable sized fields that are likely to be
>passed as data structures.  In this case I might consider passing a
>pointer.  I try to code input parms first where possible because at least
>one will be required.

Good advice.

>
>I code I/O parms without the CONST/VALUE.  One per variable.  I use *OMIT
>or *NOPASS if it might be useful to retrieve a subset of the values.  I
>always test using CEETSTA API and not %ADDR because of the restrictions on
>CONST/VALUE parms.

Why complicate things by using an API?  A couple of comments:

1) When using *OMIT, I don't see any reason to avoid using %ADDR to
test if the parameter is omitted.  After all, OPTIONS(*OMIT) applies
only to reference parameters where there is no problem using %ADDR.

2) When using OPTIONS(*NOPASS), the better way to check what parms
are missing is to use BIF %PARMS.  Note that if a parm is omitted
using *OMIT, it is still considered a passed parameter by %PARMS.

(BTW, these are the techniques shown in the RPG Reference Manual.)

>
>Beyond that I would recommend one prototype member per module.  I would
>bring that in with /copy.  Anyway, that is how I do it.  Most important is
>to document what you are doing and then be consistent.

This is certainly the technique we recommend. In fact, the whole
design of prototypes in the RPG language was based on the
expectation that that technique would be used.  So I hope you're
not the only one using it!

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.