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
(P) 1.800.348.1831 ext 311
(F) 1.920.568.1403

This thread ...


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].