Re: How to use *OMIT and or *NOPASS

John,

How is this not using prototypes as they were intended? Do you really think
this is more confusing than passing a bunch of omittable parameters?

I'm not sure the numeric -> character issue is relevant here either. No
numeric values were mentioned in the example...

Passing the 'unnecessary fields as blank *might* be better, but this method
is far more easily extendable than passing one parameter per possible
variable. With this method, you can easily add new values to the IDType
field, rather than have to add new parameters. Yes, it requires a SELECT
statement in the caller to pass the correct parameter, but that would be
needed anyway if passing omitted parms. No extra code, just different code.

Horses for course, I guess...

Rory

On Tue, May 12, 2009 at 12:27 PM, Voris, John <john.voris@xxxxxxxxxxxxx>wrote:

I would debate with Rory Hewitt on using a "variant" for the third parm.

This is a common trap for expediency, but by not calling what something
really is - You are not encapsulating logic, but confounding it - you
are not using prototypes as they were intended - and you are leaving
confusion behind for the next maintenance programmer to understand.

If you end up cramming a numeric into an alpha field, is it left
justified, right justified ?
Within our programs, we are trying to write re-usable code, so are you
going to put the SELECT statement inside a /COPYBOOK - or inside another
procedure? You may even end up with a SELECT to load the field into the
interface, and then a SELECT to strip it out of the interface in the
receiving program.

It would just be better to just pass 4 blank fields and the one defined
field with a value and forget about using *OMIT than to confuse the
interface logic with a variant.