Re: Vendor call returns up to 200 varying parms back, looking for easy way to scan it all.

[Jon Paris <jon.paris@xxxxxxxxxxxxxx>]

I guess the length must be expanded to at least 1 and that would pad it with a blank - I honestly don't know. 

Regardless I don't like it as a test - it is misleading as to the content of the field.


On 2014-07-02, at 11:56 AM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx> wrote:

> Yeah, I know - although *blanks seems to be valid for an empty string comparison. I ran a quick test -
>
>     Demptystr         s             10a   varying
>
>      /free
>       // emptystr is all x'00's
>       if emptystr = *blanks;
>         dsply 'all x''00'' empty string can be compared to *BLANKS';
>       endif;
>       // Set to ''
>       emptystr = '';
>       if emptystr = *blanks;
>         dsply 'empty string set to '''' can be compared to *BLANKS';
>       endif;
>       *inlr = *on;
>      /end-free
>
> You know this, of course - varying is initialized to length of 0 - EVAL emptystr:x showed all x'00', which is likely just what is in memory - first 2 bytes were 0000.
>
> Setting emptystr deliberately to an empty string actually made no difference, as expected. I didn't initialize to a real blank value in between.
>
> What I'm seeing is that a varying-length with length of 0 tests correctly for being *BLANKS.
>
> Am I missing something?
>
> Cheers
> Vern
>
> On 7/2/2014 9:09 AM, Jon Paris wrote:
> > *Blanks my not work Vern - if they are really VarChar then '' (null) or %Len = 0 would be the way to go.
> >
> >
> > On 2014-07-02, at 9:33 AM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx> wrote:
> >
> > > Chris, DO take a look at what Charles suggested - use the %parms BIF to find out how many WERE passed, then, as he does, use the value from that as the limiting value of the FOR loop.
> > >
> > > Use a test for *BLANKS against each element of array if you want to know if ANYTHING has been sent with a non-blank value. IIRC, you wanted to know this - perhaps I missed something.
> > >
> > > Later
> > > Vern
> > >
> > > On 7/2/2014 8:25 AM, Chris wrote:
> > > > I did not mean to imply they would skip parameters in their reply, what comes back is simply empty. Hence the problem, 1-100 could contain data, 101-199 might not, and 200 does. Right now the programmer who has it did 200 if/then construct, though to me passing through a select/when might be easier on the eyes. Would be nice if I could map just over the length portion of those varying fields, perhaps tricks with pointers.
> > > >
> > > >
> > > > -----Original Message-----
> > > > > From: Charles Wilt <charles.wilt@xxxxxxxxx>
> > > > > Sent: Jul 2, 2014 8:47 AM
> > > > > To: "RPG programming on the IBM i (AS/400 and iSeries)" <rpg400-l@xxxxxxxxxxxx>
> > > > > Subject: Re: Vendor call returns up to 200 varying parms back, looking for	easy way to scan it all.
> > > > >
> > > > > With a definition of 999a VARYING, the allocated size is fixed at 1001
> > > > > bytes (assuming a SBCS)
> > > > >
> > > > > There's a fixed 2 byte length followed 999 bytes.
> > > > >
> > > > > If it was OPTIONS(*VARSIZE), then the allocated size would be variable.  In
> > > > > which case they would have needed to pass you the size of each.
> > > > >
> > > > > If you didn't have the *NOPASS, you could do
> > > > > D parmData       DS
> > > > > D  parm1
> > > > > D  parm2
> > > > > D  parm3
> > > > > D  parm4
> > > > > <...>
> > > > > D  parm                               Overlay(parmData)
> > > > > D                                     Like(parm1) Dim(200)
> > > > >
> > > > > But I'm not sure it will work with *NOPASS
> > > > >
> > > > > You could try it Just make sure you loop
> > > > >
> > > > > dow x < nbrpParms;
> > > > >  somefield = parm(x)
> > > > > enddo;
> > > > >
> > > > > Note that with *NOPASS, you can't be "missing" any parms in the middle as
> > > > > you seem to imply in your original post. If the results of the %parms() BIF
> > > > > is 20, the you'd have parms1 - 20.  Not 1-10 and 20-30.
> > > > >
> > > > > HTH,
> > > > > Charles
> > > -- 
> > > This is the RPG programming on the IBM i (AS/400 and 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.
> > Jon Paris
> >
> > www.partner400.com
> > www.SystemiDeveloper.com
>
> -- 
> This is the RPG programming on the IBM i (AS/400 and 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.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com