Re: How to use *OMIT and or *NOPASS

[Rory Hewitt <roryhewitt@xxxxxxxxx>]

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.