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