Re: CLLE and date type parameter in RPGLE subprocedure

["Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>]

Hello Lloyd,

You wrote:
>IIRC, you must use 16-byte char fields in the RTNVAL() parameter in
>the CALLPRC command:

That's simply not true.  RTNVAL supports decimal and character data
types of all sizes.  Passing binary data (Integers) can be handled
using an appropriately sized character field and must be wrapped in
%BIN to properly convert.  However CL stuffs up 1-byte values (i.e.,
logical types) due to flawed reasoning and an unholy association with
C.

>This is a documented condition of the CALLPRC command that its return
>values must be defined in intervals of 16. I think it has to do with
>passing the variable by reference.

That's not true either.  The statement you recall from the
documentation is:
        "Variables used as return variables will be aligned on a
         16-byte boundary."

The operative word is 'will' meaning the CL compiler will take care of
alignment rather than 'must' meaning the programmer has to take care of
it.  Since CL provides no way to specify alignment and forcing
alignment is problematic (see my previous appends on this subject) it
is silly to make such a statement in the documentation.  CL (and CL
programers) doesn't care about alignment.  The only reason I can think
of for aligning return values on 16-bytes is to allow a pointer to be
stored in character field and since CL doesn't support pointers the
ability is moot.  It might be useful to return a pointer from some
function that is then passed into another function but most CL
programmers wouldn't be doing any such thing.

Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists

   http://www.flybynight.com.au/
   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------