Re: Passing unwanted parameters

Simon,

Good advice.

However, since the extra parameter would be a simple string, I think I *
might* simply define a UDS (data-area data-structure) in the caller, set it
to my required value and then use OUT to update it prior to calling the
programs. Those called programs that need the value can simply define the
same UDS and it's immediately available to them. The caller will
automatically create it in QTEMP and lock it, so it's effectively a CONST
parameter. Same system for RPG/400 or CL programs, I'd guess.

I'm trying to think of drawbacks to this approach... any thoughts.

Rory

On Mon, Jan 12, 2009 at 5:08 PM, Simon Coulter <shc@xxxxxxxxxxxxxxxxx>wrote:

On 13/01/2009, at 9:53 AM, Rory Hewitt wrote:

Basically we have a backwards compatibility issue, where we have a
'router'
program, which calls certain (user-specified) programs. We now want to
change the parameters to pass to those programs (just adding an
extra one).
However, since the program being called is only known at run-time,
there's a
problem. Plus there might be hundreds of programs to call, and our
users may
decide to change them piecemeal...

Externally define the parameter behaviour (*DTAARA, control file,
etc.). Your router program checks this and only if set passes the new
parameter.

Users modify their exit programs (piecemeal or wholesale) and test
for the extra parameter. If present use it, if not behave the old way.

Once all user programs are modified they can set the control flag to
pass the new parameter.

I guess I could retrieve the MAX parameters value for the called
program
(one of the API's must do this) and see whether it's an ILE program
(in
which case I can pass the new parameter) or it's an OPM program
that's been
changed to define the new parameter...

QCLRPGMI format PGMI0100 will give you the type of program and MIN
and MAX number of parameters.


Regards,
Simon Coulter.