Re: Another ILE question : CONST vs VALUE

Armbruster, Tom wrote:

Thanks. I see. A global variable like system time, system date, or
some random global environment variable used by the overall application
by reference could change during the call. That makes the question more
sensible. Although memory is at a premium on some systems ...

While passing by reference will conserve memory, the time efficiency is also much better than passing by value for large parameters. To me, this is the much more important difference between passing by value and passing by reference.

... I've always
found that a constant SHOULD be a temporary variable that can not be
altered.

Short version:
If you really want to be absolutely sure that this happening, use VALUE instead of CONST. There will be an adverse effect on performance for large parameters. As Jon Paris mentioned, there is currently no way to do this in RPG when making a program call.

Long version:
Adding 'CONST' to a prototype is really just a convenience to those who might call your program/procedure. You're saying 'you can pass me pointers into your programs memory, and I promise I won't mess with your memory'. The idea being that the calling program can take advantage of the efficiencies gained by passing by reference without being concerned about what might happen to the variable in question. Having the compiler stop you from messing with the CONST parameter is just a convenience to help you not to accidentally break the promise. As usual, if you do something really wacky like directly using a global variable in a subprocedure, you can trick the compiler enough that it can't help you anymore.

There is also a handy extra benefit promising the caller that you won't change a parameter passed by reference. It allows the compiler to do some fancy tricks to make things more convenient for the calling programmer, like converting your 3,0 packed to a 5,2 zoned before making the call so that the programmer doesn't have to worry about it. The only reason the compiler can do this is because it knows that the calling program isn't expecting to receive a result from the called procedure in that variable.

Hope this helps,
Adam