|
<snip> One reason I asked for references is, so that I can convince others if they question me. </snip> Just have them subscribe to the list ;-) Thanks, Tommy Holden -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of praveen gunda Sent: Wednesday, April 19, 2006 2:38 PM To: RPG programming on the AS400 / iSeries Subject: Re: How can I Improve this procedure... Scott, "However, if the problem is that you don't believe me, you can wait until an IBMer on the list replies." I always like the explanations you give. It thows a lot of light on the subject. You give excellent replies. That is one reason I dare to ask questions in this forum. I get excellent replies from very experianced people here. One reason I asked for references is, so that I can convince others if they question me. On 4/19/06, Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx> wrote: > > > > can you elaborate on this? I keep hearing it very often but did not find > > much explantation as to why? > > Because a return value copies the data from one place to another. So if > you return 3000 bytes, the system has to copy all 3000 bytes from one > place in memory to another place in memory. > > By contrast, when you pass a parameter (unless you use the VALUE keyword) > the system references the existing copy of the data in memory. It doesn't > have to copy it from one place to another, it just uses the original spot. > > > Is this the case with procedures too? Also is it any different if the > > procedure is in a service program? > > Since programs can't return a value, this discussion ONLY applies to > procedures, and that's what we've been talking about all along. Unless I'm > misinterpreting the question? > > No, it doesn't matter if the procedure is in a service program. (or > anywhere else) This has to do with how parameters and return values work. > It doesn't matter where the procedures are located. > > > Is it not just a pointer that is returned? Any pointers to books/IBM > > resources on this topic will be helpful too. > > No, it is not a pointer that's returned. I'm sure that there are IBM > resources that explain this, but I don't know what they are off the top of > my head. I learned this stuff years and years and years ago, and I'm > afraid that I can no longer remember where I originally learned it. > > However, if the problem is that you don't believe me, you can wait until > an IBMer on the list replies. > > >> D DS > >> D ReasonDS dim(200) > >> D @RsnCode 2A overlay(ReasonDS:1) > >> D @Charge 9P 2 overlay(ReasonDS:*NEXT) > >> D @Weight 9P 0 overlay(ReasonDS:*NEXT) > >> D @Units 7P 0 overlay(ReasonDS:*NEXT) > [SNIP] > > > > In this case does RPG allow %lookup('XX': @RsnCode) ? I guess not as > > @RsnCode is not an array. > > Sorry, @RsnCode *is* an array, and yes you can use %lookup() on it. > That's the reason I suggested this technique. The reason that it's an > array is because it's overlaying ReasonDS which is an array. > > [SNIP] > >> D ReasonDS ds qualified dim(200) > >> D @RsnCode 2A > >> D @Charge 9P 2 > >> D @Weight 9P 0 > >> D @Units 7P 0 > [SNIP] > > This is exactly what I meant to do, but for the lack of %lookup support. > > Would it be possible to write a generic procedure, you can pass an array > > (could be an array of datastructure) that could look up this array... I > am > > just thinking loud here. > > You could write a subprocedure that loops through it and compares the > elements. That way, you can call that subprocedure to do a lookup. > > Alternately, you could use the qsort() and bsearch() routines from the ILE > C runtime. This has been discussed many times before, so searching the > archives should yield some examples. > > Of course, the overlay approach allows you to use %LOOKUP so you might not > even want to use the qualified DIM DS approach. I'm just telling you what > your options are. > > -- > 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. > >
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.