Re: Another ILE question

The original poster's problem was a failure to realize that even
though the parm was CONST it was a global variable belonging to a
Wfile - therefore the minute he read the file its value changed. In
other words his problem was a failure to understand how the storage
for files worked. It had nothing to do with the behavior of CONST.

But if he had used the VALUE keyword instead of CONST, SRefNo would not
have been changed with the - second - read.

Kurt Anderson pointed out, the value of a const parameter can be changed
by directly referencing a global variable.
Which is a behaviour of CONST, pass by reference....

Or am I mistaken?

Have a Nice Day
Wim



Jon Paris <Jon.Paris@xxxxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
11/15/2007 11:50 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
rpg400-l@xxxxxxxxxxxx
cc

Subject
Re: Another ILE question







On 15-Nov-07, at 4:20 PM, rpg400-l-request@xxxxxxxxxxxx wrote:

Can someone provide an example as to
when a constant value provided to a program would be altered during
the
called procedure and what effect it might have?

The warning in the manual concerns the use of prototyping a program/
procedure which does not use the same prototype as the caller. For
example the parm is specified as CONST but the called program uses
the old *ENTRY PLIST approach. The CONST keyword in this case will
not protect the parameter from being changed. What CONST will do is
simply to allow a variable which does not match the definition
exactly to be passed. Of course under these circumstances it doesn't
matter what the called program does - because any change it makes
only affects the working copy, which the caller will never see. On
the other hand, if the variable _does_ match the definition exactly,
then any change made by the called program will affect the caller.
This is the behavior that the manual warns against. i.e. CONST only
copies when it has to, so sometimes the real variable is passed and
therefore can be changed. It is partly for this reason that I really
wish we could get a COPY option i.e. a pass by reference but what is
passed is always a copy. COBOL has this and it is a useful defense.

The original poster's problem was a failure to realize that even
though the parm was CONST it was a global variable belonging to a
file - therefore the minute he read the file its value changed. In
other words his problem was a failure to understand how the storage
for files worked. It had nothing to do with the behavior of CONST.

In oder for CONST to truly mean read-only it is essential that the
called routine uses the exact same prototype (which is why they
should always be /COPY'd) that ensure that the PI matches (since it
is validated against the PR) and it is actually that PI that ensures
that the called routine cannot change the value of the parm.

Jon Paris

www.Partner400.com
www.SystemiDeveloper.com