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

To me it harkens back to how we tested initialized character fields - whether for good or ill, it lets us use the same kind of test as we would use for a fixed-length variable.

I see you point about being misleading - but for civilians, it may have been done this way, since we don't necessarily think of the gory details.

Vern

On 7/2/2014 11:00 AM, Jon Paris wrote:

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