Skip to Content

ABAP: I get an undesirable warning. How can I disable it?

Hello everyone,

please look at the following code extract:

FORM LOHNARTEN_ERMITTELN USING CS_0008 TYPE PA0008
                      CHANGING CT_WAGEGROUPS TYPE STANDARD TABLE.
DATA: LGA LIKE PA0008-LGA01,BET LIKE PA0008-BET01,
OPK LIKE PA0008-OPK01,
CS_WAGEGROUPS TYPE BAPIP0008P. " effektiv: LIKE LINE OF CT_WAGEGROUPS.

REFRESH CT_WAGEGROUPS.

DO 40 TIMES
  VARYING LGA FROM CS_0008-LGA01 NEXT CS_0008-LGA02 RANGE CS_0008
  VARYING BET FROM CS_0008-BET01 NEXT CS_0008-BET02 RANGE CS_0008
  VARYING OPK FROM CS_0008-OPK01 NEXT CS_0008-OPK02 RANGE CS_0008.

  CS_WAGEGROUPS-WAGETYPE = LGA.
  CS_WAGEGROUPS-AMOUNT = BET.
  CS_WAGEGROUPS-OPERINDIC = OPK.
  APPEND CS_WAGEGROUPS TO CT_WAGEGROUPS.
ENDDO.

For the above code, I get a warning

Do not modify a USING reference parameter. Instead, define the parameter as a USING VALUE(...) or CHANGING parameter.

Obviously, the criticism is unwarranted, because I am only using CS_0008 in the VARYING part of the DO-clause, where it is not being changed. (I know "VARYING" is deprecated, but that does not mean that it should cause warnings to malfunction.)

I am aware that that SAP will probably not care to change this behavior. Is there a pragma to disable this warning?

Thank you in advance!

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

5 Answers

  • Nov 29, 2016 at 12:28 PM

    Then use some ASSIGN component in place of VARYING option.

     FORM lohnarten_ermitteln USING cs_0008 TYPE pa0008
                           CHANGING ct_wagegroups TYPE STANDARD TABLE.
       DATA: lga LIKE pa0008-lga01,bet LIKE pa0008-bet01,
             opk LIKE pa0008-opk01,
             cs_wagegroups TYPE bapip0008p. " effektiv: LIKE LINE OF CT_WAGEGROUPS.
       DATA: fieldname TYPE fieldname,
             suffix TYPE n LENGTH 2.
       FIELD-SYMBOLS: <lga> TYPE pa0008-lga01,
                      <bet> TYPE pa0008-bet01,
                      <opk> TYPE pa0008-opk01.
       REFRESH ct_wagegroups.
       DO 40 TIMES.
         suffix = sy-index.
         CONCATENATE 'LGA' suffix INTO fieldname.
         ASSIGN COMPONENT fieldname OF STRUCTURE cs_0008 TO <lga>.
         CONCATENATE 'BET' suffix INTO fieldname.
         ASSIGN COMPONENT fieldname OF STRUCTURE cs_0008 TO <bet>.
         CONCATENATE 'OPK' suffix INTO fieldname.
         ASSIGN COMPONENT fieldname OF STRUCTURE cs_0008 TO <opk>.
         cs_wagegroups-wagetype = <lga>.
         cs_wagegroups-amount = <bet>.
         cs_wagegroups-operindic = <opk>.
         APPEND cs_wagegroups TO ct_wagegroups.
       ENDDO.
       " etc.
     ENDFORM.      
    

    Doesn't raise any warning in Abap Editor. (sample fast written, i let you enhance it...)

    Regards,
    Raymond

    Add comment
    10|10000 characters needed characters exceeded

  • Nov 29, 2016 at 09:45 AM

    You could use the 'pass by' VALUE option, Abap dislike this syntax even if you actually don't change the lga, bet or opk field as some kind of local variable (assumed changeable) refer to a protected area (assumed unchangeable). You could also move the received PA0008 structure to a local variable before using it.

    Also try to use an ASSIGN with INCREMENT option as DO VARYING is nowadays an obsolete statement.

    Regards,

    Raymond

    Add comment
    10|10000 characters needed characters exceeded

  • Nov 29, 2016 at 09:46 AM

    I don't think there's a pragma (as will probably be stated when running trx. "SLIN" for you report) for this.

    Add comment
    10|10000 characters needed characters exceeded

  • Nov 29, 2016 at 09:59 AM

    there is a function module RP_FILL_WAGE_TYPE_TABLE so you could avoid DO VARYING

    Add comment
    10|10000 characters needed characters exceeded

  • Nov 29, 2016 at 10:57 AM

    Thanks for all the replies.

    "You could use the 'pass by' VALUE option"

    True, but that would impact performance due to pointless copying of values, whilst cluttering up the code.

    "there is a function module RP_FILL_WAGE_TYPE_TABLE so you could avoid DO VARYING"

    Yes, but using that instead of this simple DO-clause is horrible in terms of performance. Getting rid of this silly warning is not enough incentive to do that.

    A pragma sure would be best if it exists.

    Add comment
    10|10000 characters needed characters exceeded