Re: How can I Improve this procedure...

["praveen gunda" <praveen.gunda@xxxxxxxxx>]

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