RE: How can I Improve this procedure... -- RPG400-L

I believe it wasn't implemented right, but it was implemented, period.
They can "fix" it (i.e., change the way they did it) but I don't think there's
enough complaining about it today for them to be working on it.
Late last year, I rewrote my "Convert to CSV" format routines from using lengthy
return values to only using parameters. The results we, well very surprising.
The new stuff runs several 10's of times faster. No longer changes, just parms
instead of return values. 

Java? Well I think Java is a specific tool, for a specific job that many people
have fallen in love with. Like someone here recently said of RPG when your only
tool is a hammer then every problem looks like a nail. That can be said of Java
too. 

PHP, Perle, Python, RPGIV, Java, JavaScript--no one tool is right for every
task, but today, just about every tool can be used for every task. And if you
only have to do something once or twice, then it probably doesn't matter if you
using Java or RPG IV. Use what you want.
Likewise, if you are only returning a long value once or twice per transaction,
then go ahead. In my Convert to CSV routine, however, I have customer with
hundreds of millions of records that they are sending to a third party for
integration into an Oracle database. That third party requested the data in CSV
format. Multiple 150,000,000 records by 18 (the number of fields in the file)
and you can see how many times a lengthy return value would contribute to the
overall processing of the task. 

-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 Brad Stone
Sent: Wednesday, April 19, 2006 5:13 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: How can I Improve this procedure...

This begs the questions:

1.  Is 1k, 32k or 64k considered a LOT of memory these
days?
2.  When is this temp memory reclaimed?  I assume at the
completion of the call to the subproc
3.  How much memory, compared to this, would a Java app (or
something like Websphere alone, without even considering
the apps) use?  When this is thought about, is it really "a
lot" or "too slow?" to use large string return variables?
4.  Was the return parm implemeted wrong at the machine
level?  Are we programming around that by returning a
pointer or using a parm return value instead of a return
value?

I'm sure there are more.  :)

Brad

On Wed, 19 Apr 2006 16:00:42 -0500
 "Bob Cozzi" <cozzi@xxxxxxxxx> wrote:
> Not really.
> With a parameter, a temporary/work variable is created,
> but data is copied into
> it once. Nothing is returned, so there isn't that
> subsequent copying going on
> upon return.
> Passing by VALUE also prohibits access to the changed
> data of the parameter.
> This is a different situation than the return value of a
> subprocedure.
> 
> 
> 
> -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 3:40 PM
> To: RPG programming on the AS400 / iSeries
> Subject: Re: How can I Improve this procedure...
> 
> 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.
> >
> >
> -- 
> 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.
> 

Bradley V. Stone
BVS.Tools
www.bvstools.com