|
Barbara, May I take this opportunity to quiz you? Although this is not the same issue from which this thread arose, it does relate to calling conventions, specifically return values. The returned value is normally a variable that the calling program has allocated storage for, either dynamically or at compile time. However, if the returned variable is a pointer that has been assigned by the called procedure then I would expect that it should point to storage that has been allocated as global somehow and therefore always accesible by the calling program. For instance, if a called service procedure reads from a file that is defined only to the service program then returning the address of a field in that file seems work. But exactly what happens if you return the address of a variable that is local to the called procedure since I would expect that these exist in automatic storage and therefore the data at the address pointed to after returning is unpredictable. Debug shows the first 16 bytes at that address are destroyed. Another related question. Once the called procedure has been entered, where are the passed parameters stored? Are they stored in the heap? The reason I ask is that I have a situation where a procedure in a service program has a parameter specified as *nopass. It seems that if the parameter is passed on the first call but not on the second call then the second call still appears to be able to access the parameter whose value remains from the first call. The really strange thing is that this is still the case even when I reclaim the activation group in which the service program runs before the second call. How can this be? Are they stored in the heap or registers that persist despite reclaiming the activation group. Peter ----Original Message----- From: Barbara Morris [mailto:bmorris@xxxxxxxxxx] Sent: Tuesday, June 24, 2003 7:33 AM To: rpg400-l@xxxxxxxxxxxx Subject: Re: parameters - const, value, reference Richard B Baird wrote: > ... > > if you have a rather large string that you might want to change locally, > does it matter whether you pass by value and change in-line, or > const/reference and move it to a locally defined variable for manipulation > - 6 of one, .5doz of another. you are still moving the data. > ... Passing large parameters by value isn't something that the iSeries is optimized for. (I think this probably applies to any system.) If you have procedures dealing with strings, defining the parameters as CONST VARYING will probably get you the best performance. If your procedure has to make a local copy, it will only have to copy the current length. _______________________________________________ This is the RPG programming on the AS400 / iSeries (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. This correspondence is for the named person's use only. It may contain confidential or legally privileged information, or both. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this correspondence in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or rely on any part of this correspondence if you are not the intended recipient. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of Baycorp Advantage.If you need assistance, please contact Baycorp Advantage on either :- Australia 133124 or New Zealand +64 9 356 5800
As an Amazon Associate we earn from qualifying purchases.
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.