2011 Apr 22 4:50 AM
I got a DUMP GETWA_NOT_ASSIGNED, which is triggered by the ASSIGN statement. I once raised this problem. The code is as:
data: name3(21) value '(SAPLMBWL)IMSEG-ABLAD'.
assign (name3) to <f>.
here, IMSEG seems to be a interface of some FM. At last time, I was suggested to transfer the name3 to upper case. It works. But in some condition, it will also raise a DUMP. So I am thinking about there should be some other problem.
In the DUMP text, I found this in ERROR analysis:
You address a global function interface, although the
respective function module is not active - that is, is
not in the list of active calls. The list of active calls
can be taken from this short dump.
I checked the loaded program in debug mode, the program SAPLMBWL is not in the loaded list. But the program can run 2 times for the ASSIGN statement, At the first time, it works fine without any problem. But at the 2nd time, it raise the DUMP.
I think it has sth to do with the memory or objects in runtime. Is there any way to check (SAPLMBWL)IMSEG-ABLAD before the ASSIGN statement?
How to check the active calls list mentioned in the ERROR analysis and what can be done for it? Any check?
thanks for help.
2011 Apr 22 6:49 AM
Hi Yichao,
You can use the FM "SYSTEM_CALLSTACK" and look for "SAPLMBWL" under column PROGNAME.
But here is the catch, i see that the above program is a function group and IMSEG is not a global variable in that function group, and most probably is a local variable/global interface of a FM in that function group.
My point is there are many other FMs in "SAPLMBWL" and you will still have " "SAPLMBWL" in the call stack, but the call to where you are assigning the field symbol might not be originating from the FM it is expected.
So, you need to be 100% sure that the call originates from the FM where IMSEG is available.
Alternatively, i would suggest you look for an implicit enhancement(If you are on ECC 6.0) or look for a Userexit/customer exit to export this value and import it later where you are assigning the FS.
Regards,
Chen
2011 Apr 22 6:41 AM
2011 Apr 22 6:49 AM
Hi Yichao,
You can use the FM "SYSTEM_CALLSTACK" and look for "SAPLMBWL" under column PROGNAME.
But here is the catch, i see that the above program is a function group and IMSEG is not a global variable in that function group, and most probably is a local variable/global interface of a FM in that function group.
My point is there are many other FMs in "SAPLMBWL" and you will still have " "SAPLMBWL" in the call stack, but the call to where you are assigning the field symbol might not be originating from the FM it is expected.
So, you need to be 100% sure that the call originates from the FM where IMSEG is available.
Alternatively, i would suggest you look for an implicit enhancement(If you are on ECC 6.0) or look for a Userexit/customer exit to export this value and import it later where you are assigning the FS.
Regards,
Chen
2011 Apr 22 8:59 AM
Thanks both.
Hi KV Chen, yes you are right, IMESG looks like a TABLE interface. I guess the issue is like what you said, sometimes, the FM is called and the ASSIGN statement is executed, but sometimes the FM is not called and the ASSIGN statement will raise the DUMP.
That is, IMESG can not be addressed all the time.
so is it possible to add any check before the ASSIGN action?
FM "SYSTEM_CALLSTACK" is FM which will show the loaded program? Just like loaded program tool in the new debugger?
I used loaded program in debugger and found SAPLMBWL seems not to be loaded.
2011 Apr 22 12:16 PM
Hi Yichao,
so is it possible to add any check before the ASSIGN action?
You can try something as shown below,
DATA: li_callstack TYPE ABAP_CALLSTACK,
lw_callstack TYPE ABAP_CALLSTACK_LINE.
CALL FUNCTION 'SYSTEM_CALLSTACK'
EXPORTING
MAX_LEVEL = 0
IMPORTING
CALLSTACK = li_callstack
ET_CALLSTACK =
.
READ TABLE li_callstack INTO lw_callstack
WITH KEY progname = 'SAPLMBWL'.
IF sy-subrc eq 0.
ASSIGN the Field Symbol.
ELSE.
ENDIF.
Regards,
Chen
2011 Apr 22 8:39 PM
It may also be possible to enclose the ASSIGN statement in a TRY ... CATCH ... ENDTRY or CATCH SYSTEM-EXCEPTIONS block. I'm not sure if the GETWA_NOT_ASSIGNED exception will work with these statements.
2011 Apr 25 4:30 AM
2011 Apr 24 2:27 AM
I had a similar problem and the SYSTEM_CALLSTACK fm seems to work perfectly. The "TRY ... CATCH ... ENDTRY or CATCH SYSTEM-EXCEPTIONS " option dosen't seem to work because GETWA_NOT_ASSIGNED doesn't seem to be a catchable runtime error.
Here is the code:
IF komk-vbtyp = 'M'.
IF ( preisfindungsart = 'A' OR preisfindungsart = 'C' ) AND (
komk-kappl EQ 'V').
CALL FUNCTION 'SYSTEM_CALLSTACK'
IMPORTING
CALLSTACK = lt_callstack
ET_CALLSTACK = lt_sys_callstack.
loop at lt_callstack assigning <ls_sys_callstack>
where MAINPROGRAM = 'SAPLV60A'
and BLOCKTYPE = 'FUNCTION'.
"See if this function calls the XVBFS global parameter and field-symbol
select single * from FUPARAREF into ls_FUPARAREF
where FUNCNAME = <ls_sys_callstack>-BLOCKNAME
and R3STATE = 'A' "Active
and PARAMETER = 'XVBFS' "Global parameter / field symbol
and PARAMTYPE = 'T'. "Table
if sy-subrc = 0.
lv_can_add_to_log = abap_true.
exit.
endif.
endloop.
if lv_can_add_to_log = abap_true.
PERFORM vbfs_hinzufuegen_allg(saplv60a) USING
komk-belnr komp-kposn 'ZVSD' 'E' '002'
lo_rfc_result-tran_id sy-datum sy-uzeit space .
komp-prsok = space.
ELSE.
MESSAGE ID 'ZVSD' TYPE 'E' NUMBER '002' WITH
lo_rfc_result-tran_id sy-datum sy-uzeit.
endif.
endif.
endif.
Edited by: Jake Taber on Apr 24, 2011 4:34 AM
Edited by: Jake Taber on Apr 24, 2011 4:35 AM
2011 Apr 24 10:31 PM
yicchao,
the assign does bot raise a dump. just check sy-subrc = 0 after assign.
check the source code section of the dump to see that the dump occurs when you try to use the unassigned field symbol.
regards,
clemens