Re: Passing unwanted parameters

["Rory Hewitt" <roryhewitt@xxxxxxxxx>]

Simon,

I agree it's not great, but my options are limited - I need to make a change
to my caller that will work with all possible user-written called programs.
If I just change the prototype to include the new parameter, it will crash
with some called programs. If I have a flag in a data area to say whether to
pass the parameter or not, then the user still needs to change all their
programs before they can set the flag to pass the new parameter. Some users
may have hundreds (maybe even thousands) of such programs... Given assorted
testing/auditing/SOX requirements, they may not want to change all their
programs and re-test them (even if  they don't plan on actually making
*use*of the extra parameter).

Another option might be to fork the code path earlier in the process where I
might be able to take separate paths given other conditions, but I can't
guarantee this (plus I'll have to deal with more code).

The sure-fire way (to use an API to check the parameters of the called
program) is probably the best, but it adds a performance hit...

That's why I'm thinking of the data area method. It's simple and there is
little or no runtime overhead. The called program can't change it (because
it's still locked by the caller). But as you say, it's a hidden interface.
Mind you, that's what documentation is for, isn't it :-)

Rock, meet hard place.

Crapola.

Rory

On Tue, Jan 13, 2009 at 11:13 AM, Simon Coulter <shc@xxxxxxxxxxxxxxxxx>wrote:

> Your interface is now split between parameters and a data area. A
> parameter block tends to be what is known as a "hardened interface".
> Stuff coming from a data area, or other source, tends to just be
> stuff. You'll think it's under your control because it's in QTEMP and
> it's set just before the call and it's used immediately by the
> caller, etc. etc. but it's just not a good idea. Sure, it solves the
> problem but not in a good way.
>
> Fundamental problems are:
>        1) The dichotomy between sources of input
>        2) The size limit of a data area is considerably less than a
> parameter
>        3) Future requirements: additional values, different data types,
> etc.
>
> My opinion is that while this approach will solve your immediate need
> it is likely to bite you in the arse in the future.