RE: Max length of a VARYING field

Judging from the code you provided, performance would not change much from what
you already have, your NextCommaSeparatedValue() routine returns a big old 2000
byte value.
My own CSV routines used to use big old return values too. But it took centuries
to finish. I changed it to a parameter result and bam! runs faster than any
other convert to CSV tool I've tested on System i.

-Bob Cozzi
www.i5PodCast.com
Ask your manager to watch i5 TV



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On
Behalf Of Steve Richter
Sent: Friday, May 11, 2007 2:17 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: Max length of a VARYING field

Common use of varying(4) looks to be a performance problem. Currently
you code a common procedure to accept the largest varying input like
so:
d NextCommaSeperatedValue...
d pi 2000a varying
d InOutIx 10i 0
d InCsvString 32000a const varying options(*varsize)

callers of this procedure that pass varying strings only pass a
reference to the varying, no matter the size of the varying being
passed:
d csvString s 2000a varying
d ix s 10i 0
d csvValue s 256a varying
/free
csvString = "abc,efg,rpg,xyx" ;
ix = 0 ;
csvValue = NextCommaSeperatedValue( ix: csvString ) ;

when you change your common procedure to accept large varying, I dont
think the pass by reference will still apply to varying(2) callers. My
guess is the compiler has to copy from the 2 byte header varying(2) to
the 4 bytes header varying(4).

Large value types, in general, are a performance problem, no? Esp for
programmers who understandably want to code the obvious, like a = b,
not concerning themselves with the fact that a and b might be 16 meg
super tanker variables.

Java and C# have the advantage on this front. They both deal with
objects and references to objects. a = b means set a to refer to the
same object that b refers to. The continued integration of RPG into
the JVM ... now that would be progress.

-Steve