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.