RE: Multiple parms to procedures -- MIDRANGE-L

OK, I'll bite, why do you want the CONST parms protected "as if they had
a debug WATCH ensuring they are not changed rather than having the
compiler evaluate source statements"? 

It sounds to me like you are saying you want the checking done at
runtime, not at compile time. Why? Compile time checking will find all
errors when I have the code available to edit, runtime will only find it
when the program blows up (hopefully in testing). 

Also, compiler based checking also allows some optimizations that may
not be possible if the compiler can't assume the const-ness of the
parameters.

-Walden

-----Original Message-----
From: David Morris [mailto:dmorris@plumcreek.com]
Sent: Friday, July 17, 1998 10:22 AM
To: MIDRANGE-L@midrange.com
Subject: Re: Multiple parms to procedures


Hans,

I agree with %parms.  I forgot to mention it.  You ask "why complicate
things?"  You cannot use %ADDR for CONST/VALUE parameters.  I use CONST
wherever possible because of the ability to pass an expression LIKE
%SUBST.  If %ADDR worked for CONST/VALUE parms I would use it.  Could
you allow IF %ADDR(Parm1) = *NULL for CONST parms?  You know that Parm1
is not a procedure and *NULL is totally innocuous.  Ideally I would like
to see CONST/VALUE parms protected as if they had a debug WATCH ensuring
thay are not changed rather than having the compiler evaluate source
statements.

Here is a sample for some CONST OPTIONS(*OMIT: *NOPASS)  input parms:

C                   IF        %PARMS     >= 3
C                   CALLP     CEETSTA(ArgPas:3:*OMIT)
Dummy1 passed?
C                   IF        ArgPas      = 1
Yes.
C                   EVAL      Dummy1      = OptDummy1
Value passed.
C                   END
PrmPas=1
C                   IF        %PARMS     >= 4
C                   CALLP     CEETSTA(ArgPas:4:*OMIT)
Dummy2 passed?
C                   IF        ArgPas      = 1
Yes.
C                   EVAL      Dummy2      = OptDummy2
Value passed.
C                   END
PrmPas=1
C                   END
%PARMS>=4
C                   END
%PARMS>=3

Swap the Dummy with OptDummy for output parms.  In this case you could
use %ADDR.

Thanks,

David Morris

>>> Hans Boldt <boldt@ca.ibm.com> 07/17 7:00 AM >>>
>
>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.)


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
+---
+---
| 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
+---