Re: QsnddtaQ API

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.