also if the variables are part of a ds using overlay they can use the same
memory location. question is...is it really using the same memory
location? how did you determine this? by using %ADDR()? or just a guess
based on the data?

Thanks,
Tommy Holden



From:
Jerry Adams <Jerry@xxxxxxxxxxxxxxx>
To:
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
Date:
08/04/2008 12:23 PM
Subject:
RE: Two variables...one memory location



I have seen memory get "stepped on" or corrupted because of
mis-definitions of the parameters between caller and callee, but this
doesn't ring a bell.

I'm not sure if by procedure you mean an internal subprocedure, a separate
program (CL or RPG), or perhaps a service program. Perhaps code examples,
especially the prototypes, if any, and the interfaces might help
understanding.

The only way that I've been able to envision the result described is for
the two parameters to have the same definition and, then, for the callee
to use the same field name for both parameters.

Jerry C. Adams
IBM System i Programmer/Analyst
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Chandra Krieg
Sent: Monday, August 04, 2008 11:08 AM
To: 'rpg400-l@xxxxxxxxxxxx'
Subject: Two variables...one memory location


I am calling a procedure that passes in 12 parameters. Two of these parms
are populated within the procedure and the new values are passed back to
the calling pgm. These two variables, when testing, are using the same
memory address in the system. As soon as one is assigned a new value they
both are updated with the new value.

I have changed the order of the parameters, re-compiled, logged off and
other various means of trying to resolve the address issue. Can anyone
tell me why the system might be assigning these two variables the same
memory location or a way to avoid this?


Chandra Krieg
i5 Programmer/Analyst
RateWatch
(P) 1.800.348.1831 ext 311
(F) 1.920.568.1403
www.rate-watch.com

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 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].