× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Simon,

Perfect answer. Unfortunately, it's the 'wrong' one (i.e.the one I didn't
want)... :-(

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

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

Rory.

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


On 13/01/2009, at 8:52 AM, Rory Hewitt wrote:

Probably a silly question, but I haven't managed to find an
*absolute*answer:

If I call a program passing too many parameters, what will happen? I'm
assuming the called program won't throw a fit, but will OS/400 take
note? I
know some IBM programs throw an error, but I assume (again!) that
this is
program-specific code which checks for too many parameters.

What happens depends on the program. If defined with MIN and MAX
parameters then too few or too many will cause CPD0172 followed by
CPF0001 (from the command line or CL). Calling from RPG gives MCH0802
followed by CPF9999 and RPG0202.

DSPPGM will show the expected number. First value is MIN and second
value is MAX.

Program statistics:
Number of parameters . . . . . . . . . . . . . . : 1 3

In general, OPM programs work this way. For some languages, such as
RPG, the minimum is 0 and maximum is the number actually defined. I
think COBOL behaves the same way.

ILE programs always allow between 0 and 255 regardless of how many
parameters are actually defined in the program.

Program statistics:
Number of parameters . . . . . . . . . . . . . : 0 255

I presume passing more than 255 will give an error but I'd expect it
to be a compile-time error rather than run-time.


If I define a prototype for the called program with the extra
parameter
being CONST, could there be any memory overwriting problems? I
don't think
so, but I'd like to know.

Whether this will work will depend on the program type. For OPM then
you'll get an error on the call if you try to pass more than the MAX.
For ILE it shouldn't matter. The extra parameter will passed but not
used although for C the argument count will include the extra
parameters and the argument array will also include them so they are
addressable. For RPG %PARMS should include them in the count too but
unless a receiving parameter was defined they won't be addressable
and should be ignored. I can't remember how, or if, a COBOL program
can determine the number of parameters passed.


Although this is the RPG list, if anyone can confirm the behavior
for other
languages as well, that would be nice :-)

See above but easy enough to test empirically.


Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.