RE: Programmatically determine number of parms inprocedureprototype?

> 'NEVER' might be better said as 'Typically.'

No, I disagree.  NEVER is the appropriate way to say it! :)  If you
really, really need to add parameters in the middle, create a new
procedure, that way you won't break existing code.


> Maybe assumptions are being made, but I interpreted the person's post as
> such:
> D TestProc        PR
> D  Parm1                         1A
> D  Parm2                         1A    Options( *NoPass )
>
> Some modules call this procedure as "TestProc( fld1 : fld2 )"
> Others may call it as "TestProc( fld1 )"

Yes, and you can easily distinguish those by doing this:

         if %parms >= 2;
            // do something with parm2
         endif;

You don't need to know the maximum number of parms passed... you only need
to know whether it's two or more.  When you add a 3rd parm, you can add
another if group like this:

         if %parms >= 3;
            // do something
         endif;


> Now there is a change in the requirements for the program, and a new
> parameter (parm3) is needed by the procedure. (which seems to be the
> case in the original post)
>
> Parm3 can't just go at the end, unless it meets the criteria of only
> ever being needed if and only if parm2 is received.

I'm a little puzzled by this.  You want to add a new parameter that's
REQUIRED?!  If it's required, why didn't you need it before?  That makes
no sense.

Instead, as Barbara said, add the parm at the end of the list and make it
optional.  If you really, really need it to be required, create a new
subprocedure so that you don't break existing code.

> If Parm3 does go at the end, and doesn't meet the criteria above, then
> Parm2 must have Options( *NoPass ) removed

No!  If you remove options(*nopass), you break compatibility.  Don't
remove it.  If you want parm2 to remain optional when you add parm3, then
make it options(*nopass: *omit) so that you can do it either way.  That
way, you don't break compatibility.

Then change the code to look like this:

        if %parms >= 2 and %addr(parm2) <> *NULL;
            internalParm2 = parm2;
        else;
            internalParm2 = default value;
        endif;

Once you've done that, existing calls will work without changing the
calling programs.  New programs that need parm3 can now do:

        testProc( parm1: *omit: parm3);

You simply make life easier if you don't break compatiblity.  If you have
a srvpgm that's distributed to people all over the world, then this is an
absolute must.  If it's something only used on your machine then it just
saves you time since you don't have to re-code things.

> I suppose if you strongly believe in using *Omit over *NoPass, then
> yeah, you wouldn't want to change the order.  I enjoy the versatility of
> *NoPass however.

It's not an either-or thing.  You can have both *nopass and *omit.

Another alternative to *omit (which might not be as good, but
sometimes it easier on the eyes) is to put a named constant with a default
value in the /copy member where the prototypes are.

Then, you could do the following:

           TestProc(parm1 : PARM2_DEFAULT : parm3);

>
> Though I'm willing to learn.  Is there a reason (other than
> circumstantial) for me to be using *Omit instead of *NoPass?
>

When you've got 2000 programs that call a service program, and the
alternatives are *OMIT or changing the code of every one of them,
re-testing them, etc.  then believe me, the advantages of *OMIT will be
very clear! :)