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

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