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




On 03/12/2009, at 7:46 AM, Neill Harper wrote:

This is all really interesting stuff, I have only been an RPG developer for
2 and a half years, and still have a lot to learn.

I wasn't aware that programs could have optional parameters, I thought that
this was only procedures?

Nope. Depends on the language implementation so RPG, MI Assembler, and C can have optional parameters although they provide different mechanisms for determining how many parameters were passed. CL cannot although CLLE can but there is no direct language support for determining the number of parameters passed. COBOL can accept optional parameters but provides no way to determine how many were passed.

If the caller passes an operational descriptor then the CEE APIs can be used to determine whether a parameter was passed or not.

MI programs set the range between a user-defined minimum and the maximum specified.

HLL OPM programs set the number of parameters to either the maximum specified or to a range between 0 and the maximum if optional parameters are supported.

ILE programs (except COBOL) always set the number of parameters to a range between 0 and 255. COBOL sets a range between 0 and the maximum specified.


Also I always thought (and this may have been tainted by my c# programming
days...) that references to parameters were placed on the stack by the
caller and scooped up off the stack by the callee. If it wasn't on the stack
then the callee would assume it was null?

That's a push-pop sort of thing but really there's no pop on OS/400. The parameters on the stack are simply addressed not removed. Thus when a new call is made it will overlay parameters already on the stack. If the receiving program has no method to determine how many parameters were actually passed then it can inadvertently address stuff left on the stack from a previous call. For example, a PGM-A calls PGM-B with 4 parameters then PGM-A calls PGM-C with 2 parameters. In this case it is possible, but not always, that PGM-C could address the 3rd and 4th parameters from the call the PGM-B.

I don't know how C# handles unpassed arguments and since it doesn't run under OS/400 I don't care either. However, I doubt it assumes null--I suspect you'll get "undefined behaviour".

The caveat in all this is that both the caller and the callee must agree on the number and types of parameters being passed and optional parameters can only be used if they both agree on how to indicate the number actually passed.


Based on the below, the above is obviously all rubbish. So it leads me to
ask what does actually happen when one program calls another as far as
parameters are concerned?

All HLL external programs pass and receive parameters by reference. That is a pointer to the parameter is passed. MI can pass and receive by value to a *PGM object but no HLL exposes this for *PGM calls. COBOL also supports passing by content for *PGM objects.



Or when one procedure calls another.


These can be passed by reference, by value, or (in the case of COBOL) by content.

Reference causes a pointer to the parameter to be passed and is the default parameter passing mechanism. Value causes the parameter value to be placed in the parameter list. Content causes the value to be copied to a temporary location and a pointer to this new location is passed--this method can of course be faked by any programming language but COBOL provides direct support for it.

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.