Re: QsnddtaQ API

Vern,

The book uses a length of 65535 for input parameters of variable size for the
reason Scott gives. And by convention a length of 1 for output parameters as
these parameters will be passed by reference (no concern with copies as there is
with const) and so the length is not relevant. This convention is mentioned at
the top of page 8.

As for page 10 and QUSROBJD, you have the honor of reporting the first bug in
the book! ASP should indeed be 65535 rather than 1. Fortunately it appears
that all of the "real" examples (once you get past the page 10 example that I
clearly didn't pay sufficient attention to -- I was sick of that chapter by the
time I got the book finished lol) in the remainder of the book are correct.
QUSROBJD is prototyped with ASP as 65535 for instance on page 36, 38, 151, 157,
etc. I owe you a cold one when next we meet :)

Bruce
http://www.brucevining.com/
Providing integrated solutions for the System i user community


Vernon Hamberg wrote:
Joep

This is interesting, as I've just started reading Bruce Vining's
rewrite of APIs at Work, the book from MC Press. I'm reading his
discussion of creating prototypes. For "retrieve" type APIs like
QUSROBJD, he says, basically, to always use CONST for 'input'
parameters, which makes sense. It lets you pass literals and
expressions. And for parameters described as char(*) - not the C/C++
char * - he says to use the largest size (currently 65535) for input
parameters. Likely for the reasons Scott gave. Bruce also uses
*VARSIZE for these input parameters. And you can't use CONST for
output parameters, first, you always need a variable for those, and
they WILL be changed.

Bruce, however, says to use length of 1 for output parameters. He
also has *varsize on these, which makes sense. And does not use
CONST, since it is expected that these will be changed. This would
probably not be a case of using an intermediate result - the called
program is responsible for filling it to the length usually passed in
the second variable - receiver variable length. This is similar, I
think, to a technique I was shown and used in C, at a former
employer, for the varying length portion at the end of structs - pass
a pointer to a single character, as I recall. I would use the various
structs as defined for that region - again, the called program was
responsible for allocation the memory and building up that area - all
I needed was the pointer.

I do wonder about Bruce's example on page 10 - the QUSROBJD API - the
last parameter, for ASP control, is described in the documentation as
input char(*) in optional parameter group 2 - seems that would be
65535 const options(*varsize : *nopass) - instead, it is declared
with length 1 - there may be another principle at work here, have to
read further. And maybe Bruce can respond - I hope.

Vern

At 04:57 AM 4/9/2008, you wrote:

Scott,

You're right (of course; silly me). I missed the combination of CONST and
*VARSIZE.

(BTW: Don't you ever sleep? What time is it over there?)

Joep Beckeringh


rpg400-l-bounces@xxxxxxxxxxxx wrote on 09-04-2008 11:39:57:

J.Beckeringh@xxxxxxxxxxxxxxxxxxxxxxxxxx wrote:

I agree that input paramaters SHOULD use CONST, but not specifying it
won't cause errors.

Yes, that's why I said stated 'The CONST part isn't strictly necessary'
in my message. Thank you for agreeing with me.

As for the 2500 character limit: 'options (*varsize)' pretty much

makes

the length of the parameter meaningless (in the prootype). Whether you

specify 2500, 65535 or 1 makes no difference (I prefer 1).

That's not true. When you code something as CONST, the compiler will
sometimes create an intermediate result in memory, and pass the address
of that intermediate result.

For example, if you define the prototype as 1A options(*VARSIZE), and
then try to pass a VARYING character string to it, the compiler will
copy only 1 byte from the VARYING string to an intermediate result, and
then it'll only pass that one byte string to the procedure.

So the difference is NOT meaningless in all situations. It's only
meaningless if the compiler doesn't have to use an intermediate result.

Also, if you're going to code 1A, then the options(*varsize) is totally
meaningless. *varsize only lets you pass variables that are SHORTER
than the prototype. You are ALWAYS allowed to pass variables that are
longer than the prototype -- you don't need *VARSIZE for that.

But, again, the problem with coding 1A is that if you use an expression,

or use a data type that requires conversion, it'll store the result of
the expression (or output of the conversion) into a 1A field, and pass
that, and you won't get all of the data you were expecting. Always make

the parameter the MAXIMUM size, never the minimum size, and you'll avoid

that problem.
--

--
This is the RPG programming on the AS400 / 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.

--
This is the RPG programming on the AS400 / 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.




Bruce
Bruce Vining Services
507-206-4178
--
This is the RPG programming on the AS400 / 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.