× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

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

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.