|
Is this the same with the parameters passed to a procedure by Value. Eg: myProc('hello') D myProc PI D parm1 10 a Value In the above example, is 'Hello' copied twice? 1. once from 'hello' --> 1024A work field 2. from 1024A (work field) --> parm1 Thanks Praveen On 4/19/06, Bob Cozzi <cozzi@xxxxxxxxx> wrote: > > A return value that is not an Integer or a Pointer is specified on the > RETURN > opcode. > The system copies that to a work field that is the size and shape of the > definition of the return value itself. So if you return a 10a field to a > return > value that is 1024a that 10A value is copied to a work field that is > 1024A. > Then that 1024a workfield is copied to the expression in which is it used. > This > is a second copy for which you have no control over. > So now you've got data being copied twice, at minimum. > If you do something like > > mycharVar = myProc('hello') > > and myProc returns that 1024a value, it now has to copy the second > work/temp > variable's value to the mycharVar field. So that's 3 copies. > > Why are long return parameters slow? Because they are copied (typically) > at > least 3 times and no fewer than twice. > > -Bob Cozzi > www.RPGxTools.com > RPG xTools - Enjoy programming again. > > > -----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. > > > > > -- > 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 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.