RE: Large Return values (was Re: Variable Length Field Question)---- I'm confused

Seems most appropriate to me.  I use Varying & options(*varsize) a lot
myself works nicely. 


Thanks,
Tommy Holden


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Andy Hautamaki
Sent: Thursday, September 22, 2005 1:02 PM
To: RPG400-L@xxxxxxxxxxxx
Subject: Fw: Large Return values (was Re: Variable Length Field
Question)---- I'm confused

I've searched through the archives on how to do this and I'm not sure
what the best method (if there is one) and I apologize if an answer has
already been posted already and I can't find it.......

I always pass a  fix length as a parameter between Modules. It would be
nice when dealing with a field that has the potential to be rather large
to define it as a variable length. The method that Scott and Brad
discuss is this the best way to do this?

Thanks
Andy
----- Original Message -----
From: "Brad Stone" <brad@xxxxxxxxxxxx>
To: "RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
Sent: Thursday, May 20, 2004 2:35 PM
Subject: Re: Large Return values (was Re: Variable Length Field
Question)


> On Thu, 20 May 2004 13:20:36 -0500 (CDT)
> Scott Klement <klemscot@xxxxxxxxxxxx> wrote:
>>
>> [SNIP]
>> >      D ToUpper         PR            10I 0
>> >      D  InString                  32766A   Const
>> Varying
>> >      D  OutString                 32766A
>>   OPTIONS(*VARSIZE)
>> >
>> > The second parameter now becomes the target of the
>> > conversion, and the OPTIONS(*VARSIZE) allows you to
>> pass a
>> > parameter whose length is 1 to 32766 bytes. You simply
>> use
>> > %LEN(InString) inside the subprocedure to determine how
>> > much data was actually passed to your subprocedure.
>> Then,
>> > be sure to "touch" only that many characters in the
>> > OUTSTRING parameter.
>>
>
>> > 1.  Wouldn't you need to use %len(%trimr(InString))
>> because
>> > if the input parm used in the calling program is NOT a
>> > variable length field or a literal it won't be correct.
>>
>> In Bob's example, the input parm *WAS* defined as
>> VARYING.  There's no
>> need for extra work of the %trimr().  If the user wants
>> his string
>> trimmed, let him trim it himself.
>
> That's what I was getting at here.  I wasn't talking about
> the parmeter in the proc definition, I was talking about
> the field a user uses to pass into the subprocedure.
>
> If it's declared as 1024 (non-varying) bytes and only
> contains "hello" the %len(InString) in the subprocedure
> will return 1024.  That's why I suggested maybe using
> %len(%trimr(InString)) would actually produce the "desired"
> results in all cases.
>
> Yes, the user could trimr it when calling the procedure,
> but either way you have to trimr it to get the actual
> length.  Unless parm used is of varying type.  (but that's
> not always going to be the case).
>
> And since this case is for a product he sells, I guess one
> could weigh the performance vs. consumer confusion on
> whether they need to use varying, or not, or trimx it, or
> not.
>
> _______________________________________________
> 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.
>
>