Re: SQLRPGLE issue with CONST and %addr()

[Hans Boldt <boldt@xxxxxxxxxx>]

Basically, coding CONST on a parameter indicates that you will not
modify the parameter within the procedure.  By taking the address of
the parameter, there is the possibility that you could change the
parameter using a BASED variable based on that pointer.

On the other hand, diagnosing %ADDR(CONSTPARM) is a bit too strict
when all you want to do is test the address and not assign the
address to a pointer variable.  And so, the V5R1 compiler allows
this usage of %ADDR(CONSTPARM).  In V5R1, you can take the address
of a CONST parameter and do what you want with it, as long as you
don't assign it to anything.

Cheers!  Hans

Tyler, Matt wrote:
> Hello,
>
> I have module I am going to create into a *SRVPGM.  In that is a
> sub-procedure to return the condition of whether the date passed is in a
> leap year or not.  When I compile this module as an SQLRPGLE (because there
> is code that uses embedded SQL), it compiles just fine.  If I remove the
> embedded SQL code and change the type to RPGLE and compile the module I get
> the error message RNF0341 in every sub-procedure where I use the %ADDR()
> BIF.
>
> My question is why does SQLRPGLE act differently that RPGLE in this case?
>
> My reason for using %ADDR() was to find out by field name that the field was
> not passed when calling the sub-procedure so that I can default in the
> current date.  I wanted to write a piece of code that did not require the
> field be in a certain parameter position in case I use this code in another
> procedure without the complexity of calling the operational descriptor API.
>
> ERROR MESSAGE: RNF0341:
> Message . . . . :   The parameter for %ADDR is not valid; %ADDR is ignored.
>
> Cause . . . . . :   The parameter for built-in function %ADDR must be a
> field
>   name. If the field name is an indexed array, an array index may also be
>
>   specified. The following fields cannot have their address taken because
> the
>   fields cannot be modified:
>
>   -- Lookahead fields
>
>   -- User-Date fields UDATE, UDAY, UMONTH, UYEAR, *DATE, *DAY, *MONTH, *YEAR
>
>   -- Input-only parameters (CONST keyword specified on the parameter
>
>     definition)
>
>   -- *IN1P and *INMR
>
> Recovery  . . . :   Correct the parameter for built-in function %ADDR.
> Compile
>   again.
>
>
> PROTOTYPE:
>      D isleapyr        pr              N
>      D  inpdate                        d   const
>      D                                     options(*omit)
>
> PROCEDURE:
>      Pisleapyr         b                   EXPORT
>      D isleapyr        pi              N
>      D  inpdate                        d   const
>      D                                     options(*omit)
>
>      D leapyearsts     s               N   static
>      D workdate        s               d   static
>      D x               s             10U 0
>      D year            s              4s 0
>
>      C                   IF        %addr(inpdate) = *NULL
>      C                   IF        workdate <> CurrDate
>      C                   EVAL      workdate = CurrDate
>      C                   ELSE
>      C                   RETURN    leapyearsts
>      C                   ENDIF
>      C                   ELSE
>      C                   IF        workdate <> inpdate
>      C                   EVAL      workdate = inpdate
>      C                   ELSE
>      C                   RETURN    leapyearsts
>      C                   ENDIF
>      C                   ENDIF
>
>      C                   EXTRCT    workdate:*Y   Year
>      C                   IF        %rem(YEAR: 4) = 0
>      C                   EVAL      leapyearsts =  *on
>      C                   ELSE
>      C                   IF        %rem(YEAR: 400) = 0
>      C                   EVAL      leapyearsts =  *on
>      C                   ELSE
>      C                   EVAL      leapyearsts =  *off
>      C                   ENDIF
>      C                   ENDIF
>
>      C                   RETURN    leapyearsts
>
>      P                 E