Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

DUMP GETWA_NOT_ASSIGNED by ASSIGN FS dynamically

Former Member
0 Kudos

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.

1 ACCEPTED SOLUTION

Former Member
0 Kudos

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

8 REPLIES 8

Former Member
0 Kudos

Hi,

Can you please provide your complete code ?

Regards

HM

Former Member
0 Kudos

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

0 Kudos

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.

0 Kudos

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

0 Kudos

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.

0 Kudos

I think the solution of Chen K V is good.

jake_taber3
Discoverer
0 Kudos

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

Clemenss
Active Contributor
0 Kudos

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