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

 >> While I haven't changed our programs to use em yet, doesnt protoyping
allow for *OMIT exactly for this reason? So wouldn't it be better to
prototype and use the *OMIT method?

Hi Ron,

The problem you describe sounds like a design issue to me to be honest.  I
wouldn't expect to be passing through values that I don't need personally
(if you see what I mean).  Maybe I just don't understand exactly what
you're trying to do here though.

Anyway, you are correct in that *OMIT can certainly be used for this
purpose but it does not remove the need for testing if the parm was
received since a *OMIT simply passes a null pointer and any attempt at
touching the field will still blow up.  Wouldn't you just be swapping an If
%Parms for an IF %Addr(...) <> *Null ?

The other thing of course is to use defaults within any proc that has
optional parms and make sure that it is the default that is passed on in
any subsequent calls.  This also has the benefit of allowing you to put all
optional parm handling up-front and then to process as normal subsequently
(or to set more meaningful switches within the initial logic).

I must admit that I'm delighted to hear that someone can find a use for
*OMIT <grin>



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