Re: CONST and VALUE revisited

Absolutely. I tend to think of by Reference, Const, and Value as a
contract between the programmer and the compiler.

If you use pass by reference, the compiler is saying nothing is protected.

If you press by Const the compiler is say I will do my best but no guarantees.

If you pass by Value, the compiler is saying I guarantee this value
will not be changed.

On Wed, Jan 28, 2009 at 8:31 AM, David FOXWELL <David.FOXWELL@xxxxxxxxx> wrote:

Hi list,

I have an unenviable task of converting a 16yr old RPG to ILE. It calls a lot of other smaller RPG or modules as we called them before we had ILE. Each one copy booked in from QCPYSRC.

I have to make it 100% ILE as it is intended to run in a named activation group.

At the beginning of the program, it reads in a data area. As I'm not that experienced with data areas, I've already done a little debugging. I noticed that the data area gets modified when LR is on, without coding OUT.
I only found out because the zone I read the data area into got modified somewhere.

I thought I would read in the data area in my main procedure and then directly call a subprocedure with CONST on the parameter to protect my data area. However, from experience I've noticed that it is still possible to modify the parameter inadvertently, and we have already discussed this. Someone said that CONST in reality only means that the parameter is not INTENDED to be changed.

So, I just thought it was a bit ironic : normally, I use CONST on all parameters used for input. But now that I REALLY don't want my parameter to be changed, I shall code VALUE instead.

Unless someone else has a better idea!


--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.