× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.