Mysterious function module DYNP_VALUES_UPDATE?

[Former Member]

Hi ABAP Gurus/Experts,

I'm very confused about function module DYNP_VALUES_UPDATE in function group SHL2. It'll be nice if you could answer my question below.

I tried to call the function module with space passed to both parameter DYNAME and DYNUMB, such as the following, and it successfully updated the selection screen of the calling report. I wonder how it got program/screen information of the calling report.

    CALL FUNCTION 'DYNP_VALUES_UPDATE'
      EXPORTING
        dyname     = space
        dynumb     = space
      TABLES
        dynpfields = lt_dynp_fld[]
      EXCEPTIONS
        OTHERS     = 0.

The source code of the function module is shown below. It merely calls a subroutine and simply ignores parameters DYNAME and DYNUMB.

FUNCTION dynp_values_update.
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*"       IMPORTING
*"             VALUE(DYNAME) LIKE  D020S-PROG
*"             VALUE(DYNUMB) LIKE  D020S-DNUM
*"       TABLES
*"              DYNPFIELDS STRUCTURE  DYNPREAD
*"----------------------------------------------------------------------
  PERFORM fill_dpovtab_upd TABLES dynpfields.
ENDFUNCTION.

The form is shown below. Did the C function DYNP_GET_STATUS link function group SHL2 to the calling report in the background? I guess that field symbol <dpovtab> (linked to global variable dpovtab610 in my test) in the form was mapped to the calling report by the ABAP runtime environment...

FORM fill_dpovtab_upd TABLES dynpfields STRUCTURE dynpread.

  DATA: hf TYPE i, dp TYPE dpov610, hstepl(3) TYPE n,
        flduseoffs TYPE i, flduselen TYPE i,
        fldnameoffs TYPE i, fldnamelen TYPE i,
        fldinhoffs TYPE i, fldinhlen TYPE i,
        fldinpoffs TYPE i, fldinplen TYPE i.

  FIELD-SYMBOLS: <dpovline> TYPE ANY, <dpovtab> TYPE table,
                 <dfline> TYPE dynpread.


  CALL 'DYNP_GET_STATUS' ID 'FUNCTION' FIELD 16 "kennt der Kern DPOV610?
                         ID 'VALUE' FIELD hf.             "#EC CI_CCALL
  IF sy-subrc NE 0 OR hf EQ 0.                  "sieht wohl nicht so aus
    ASSIGN: dpovtab TO <dpovline>,
            dpovtab[] TO <dpovtab>.
    flduseoffs = 0. flduselen = 1.
    fldnameoffs = 1. fldnamelen = 132.
    fldinhoffs = 133. fldinhlen = 132.
    fldinpoffs = 265. fldinplen = 1.
  ELSE.                                         "DPOV610 ist bekannt
    ASSIGN: dpovtab610 TO <dpovtab>,
            dp TO <dpovline>.
    flduseoffs = 0. flduselen = 1.
    fldnameoffs = 1. fldnamelen = 140.
    fldinpoffs = 141. fldinplen = 1.
    fldinhoffs = 142. fldinhlen = 255.
  ENDIF.

* dynpfields nach dpovtab schaufeln

  CLEAR: <dpovtab>, <dpovline>.

  LOOP AT dynpfields ASSIGNING <dfline>.
    IF <dfline>-stepl GT 0.
      hstepl = <dfline>-stepl.
      CONCATENATE <dfline>-fieldname '(' hstepl ')'
           INTO <dpovline>+fldnameoffs(fldnamelen).
    ELSE.
      <dpovline>+fldnameoffs(fldnamelen) = <dfline>-fieldname.
    ENDIF.
    <dpovline>+flduseoffs(flduselen) = 'E'.
    <dpovline>+fldinhoffs(fldinhlen) = <dfline>-fieldvalue.
    APPEND <dpovline> TO <dpovtab>.
  ENDLOOP.

ENDFORM.                    "fill_dpovtab_upd

[Former Member]

Hi,

Really DYNP_VALUES_UPDATE do not need dyname and dynumb parameters.

The tip is that dpovtab[] is a "global" internal table with is recgnized internally by the system and influences in the field values.

The information refers every time to the current screen.

Best regards,

Leandro Mengue

[Former Member]

Hi Leandro,

Thanks a lot for your quick response.

I guess your are right. When the called program is done and the program flow returns to the calling report, the ABAP runtime environment may internally check the global fields of the called program.

To test your theory, as a copy, I created function group ZSHL2, function module ZDYNP_VALUES_UPDATE and global fields DPOVTAB and DPOVTAB610, but my version didn't work. Shall I assume that the ABAP runtime environment only checks the global fields of certain programs such as function group SHL2?

Best regards,

Bo

[Former Member]

Hi Bo,

In some place, some where, ..., SAP links the dpov table of this function group with your kernel. See:

call 'DYNP_GET_STATUS' id 'FUNCTION' field 16 "kennt der Kern DPOV610?
                       id 'VALUE' field hf.   "#EC CI_CCALL
if sy-subrc ne 0 or hf eq 0.                  "sieht wohl nicht so aus

This call is a internal function that verify the table in the kernel.

With sure another point of system is linking it.

Best regards,

Leandro Mengue