RE: PI to replaced *Entry PLIST (was Because it's there... )

>Date: Fri, 4 May 2001 13:12:09 -0700
>From: "ron hawkins" <hwarangron@home.com>
>
>Jon,
>
>Ultimately, it is a design issue, but the problem is that functions get
>added to existing programs. When I designed the program, it accepted a set
>number of parameters. Every program that called that program passed that
>number of parameters. But then, a new function gets added to that program
>thats activated by passing in a new parameter. The %parms testing is used
so
>that all other programs that call this program dont have to be changed.
>Let's say the new parameter is parameter 3. So far, no problem.
>
>Now, another new fucntion is added to the program, again activated by a
>parameter being passed to it (now parameter 4). Any existing programs that
>are going to be changed to be able to access the new function have to pass
>in 4 parameters. This means they have to pass in parameter 3 even tho they
>don't want to activate that function.
>...

Ron, maybe you shouldn't be loading so much into one program.  It sounds
like your program should instead be several separate procedures.  If the
procedures have some common parameters (and common function associated
with the parameters), they could all call some internal procedure(s) to
handle the common code, and then each do its own specific function.

Using *OMIT would be cleaner than passing and identifying dummy parameters,
but it would lead to horritude like
   callp  proc(p1:p2:*omit:*omit:*omit:*omit:x:*omit:*omit)
which would be as awful as the OCL
   // DOSOMETHING p1,,,,p2,,,,,,,p3

(You can't use *OMIT with program calls anyway ...)

Barbara Morris


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