Assign field symbol statement give runime error

[Former Member]

This code gives runtime error:

ASSIGN (c_accit) TO <fs_accit>.

where ASSIGN c_accit has value => '(SAPLRWCL)T_ACCIT[]',

declaration

c_accit TYPE char20 VALUE '(SAPLRWCL)T_ACCIT[]',

The ASSIGN statement gives short dump. It does not give dump initially. This code is inside an exit and the exit gets called

a couple of time before we have this dump. Each time when the exit is called..it works perfectly...untill suddenly at one call this ASSIGN statement gives runtime error.

[sitakant_tripathy2]

Hi,

could you please let know the type behind the field symbol...

Regards,

Sitakant....

[sitakant_tripathy2]

Hi,

could you please let know the type behind the field symbol...

Regards,

Sitakant....

[Former Member]

FIELD-SYMBOLS: <fs_accit> TYPE STANDARD TABLE,

Edited by: Pratik Mallick on Sep 10, 2010 8:42 PM

[sitakant_tripathy2]

Hi,

can u try and type the field symbol to TYPE ANY rather than type casting it to TYPE STANDARD TABLE...

Regards,

Sitakant....

[Former Member]

no it did not work.....

[sitakant_tripathy2]

Hi Pratik...

would like to know a bit of background...

You are using this code in the user-exit....I hope the data object (SAPLRWCL)T_ACCIT[] would be visible in the user exit...

First question is why are you not referencing to the data object directly as in just the T_ACCIT[] ....

Furthermore, instead of directly assigning it you can try the folowing:

DATA: lr_data type ref to data.

FIELD_SYMBOLS: <fs_accit> type any

CREATE DATA lr_data type (c_accit).

ASSIGN lr_data->* to <fs_accit>.

<fs_accit> = (SAPLRWCL)T_ACCIT[].

But frankly speaking, I am not able to comprehend the statement (SAPLRWCL)T_ACCIT[] as in what it is exactly doing...how is it possible to access this data object with this kinda a statement ...would like to know this...

Regards,

Sitakant

[Former Member]

SitaKant,

thanks for queries...

basically this code is referencing the ABAP Stack, if you are familiar with that.

It is user exit and this internal table is not visible in the FM.

[Former Member]

Hi Pratik.

For this Assign to work SAPLRWCL has to be in the call stack of Programs, because that is where T_ACCIT[] exists. In the first executions of the Exit, SAPLRWCL is in the stack. But in your dump iteration, the Exit is called from a different place and SAPLRWCL is not in the stack.

I don't think the ASSIGN statement itself is dumping. It's likely another statement after the ASSIGN that trys to use <fs_accit>. After the ASSIGN statement you could add a test on SY-SUBRC -- if it's not 0 then you know your ASSIGN didn't work and you shouldn't use <fs_accit>. Hope this helps.. Keith

[Former Member]

Keith, thanks for your reply....

I don't think its necessary to have the said program name and variable in the Stack. if its not there it should just fail and the field symbol remains unassigned. In fact this statement works ok....its just that when I am saving at the transaction level.....this code is dumping at the 3rd ..sometimes 4 th attempt.....actually this user exit is called multiple times ......

I have this chk--- IF <fs_accit> IS ASSIGNED.

[Former Member]

BASIS developer view internal notes:

Internal notes

The termination was triggered in function "getwa_abswa"

of the SAP kernel, in line 1161 of the module

"//bas/701_REL/src/krn/runt/abgetwa.c#1".

The internal operation just processed is "ASSI".

Internal mode was started at 20100910123556.

[Former Member]

Have you UNASSIGNed the field symbol at the end of the FM? If the field symbol is local to the FM, unassignment may not be needed, but probably worth trying.

[Former Member]

Hi Sudhi,

yes I have unassigned it. anyway it does not matter right...I am having dump at the ASSIGN statement....

[Former Member]

BASIS developer view internal notes:

Internal notes
The termination was triggered in function "getwa_abswa"
of the SAP kernel, in line 1161 of the module
"//bas/701_REL/src/krn/runt/abgetwa.c#1".
The internal operation just processed is "ASSI".
Internal mode was started at 20100910123556.

Is this the short dump text? If not, what does the short dump say?

Online help says:

After an unsuccessful dynamic assignment, the field symbol keeps its previous state. 

So, if ASSIGN fails, and if the field symbol was in assigned state previously, and the previous position is now pointing to junk or empty space, then it might fail when accessing the field symbol. It still doesn't answer why it would fail when assigning itself.

[Former Member]

This is what the dump says:

You attempted to access an unassigned field symbol

(data segment 17).

This error may occur if

- You address a typed field symbol before it has been set with

ASSIGN

- You address a field symbol that pointed to the line of an

internal table that was deleted

- You address a field symbol that was previously reset using

UNASSIGN or that pointed to a local field that no

longer exists

- 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.

How can it be generated for an ASSIGN statement..thats the question?

Here is the scenario:

This ASSIGN statement is inside an exit.

The exit is called from multiple codes.

The logic inside the exit has two parts. Each part is for different enhancement which gets triggered only once

at a time. Now, both of the logic parts access stack variables which is required for some data processing.

So at any time only one part accesses the stack. In my case the logic should fail(not dump) since the concerned

stack variable is not there....and the logic flows to the else part (2nd part).

The exit is triggered multiple times and each time it goes through this logic. Everything works fine when I enter the transaction (FB70) and fill in the input fields...and exit gets triggered and the ASSIGN statement works fine...no issues....

Now, the moment I save this exit triggers again and goes through the logic..it gets triggered a couple of times before, on the 4th call to be exact, the ASSIGN statement give short dumps...even though all through the lifetime of the transaction it did not.

Initially I thought the stack variable is causing the problem..but thats not the case...it remains unavailable all through the tcode lifetime ......

So my question is why did it dump in the first place.........and why at the time of saving......

[Clemenss]

Hi Pratik,

so that means that the dump does not occur at the ASSIGN statement but when the (unassigned) field-symbol is used.

You should always check the success of a dynamic ASSIGN:

ASSIGN (c_accit) TO <fs_accit>.
IF SY-SUBRC <> 0.
* BREAK to see the call stack - called from SAPLRWCL with existing T_ACCIT?
  EXIT.
ENDIF.

Probably function group RWCL is not in the calling hierarchy, could be swapped out.

Regards,

Clemens

[Former Member]

Hi Li,

The dump occurs at the ASSIGN statement :

ASSIGN (c_accit) TO <fs_accit>. ---> THE DUMP OCCURS AT THIS STATEMENT

IF SY-SUBRC 0.

• BREAK to see the call stack - called from SAPLRWCL with existing T_ACCIT?

EXIT.

ENDIF.

[PeterJonker]

Pratik,

If the dump is created at the assign statement then the table t_accit is NOT present in memory, exactly what the short dump suggests.. Please follow the suggestions made earlier and place a breakpioint so you can check every assignement including the one that fails to see if the stack value is present at time of assignement.

The shortdump also contains the call stack. Is the program SAPLRWCL present in the stack from the short dump ?

These suggestons have been made earlier but you didn't make it clear if you followed them already.

Good luck

[Clemenss]

Sorry,

you are right. The assign fails because T_ACCIT is simply unknown if exit is not called from AC_DOCUMENT_CREATE

or AC_DOCUMENT_GENERATE.

But the rest is true. Note: It is possible (though obsolete) to 'globalize' the interface of a function module. T_ACCIT is a tables parameter that exists for the functions AC_DOCUMENT_CREATE and AC_DOCUMENT_GENERATE. If the ASSIGN statement is processed in a (form) routine or exit function called from these functions, T_ACCIT is known. Othwerwise it is unknown.

Regards,

Clemens

[Clemenss]

Hi Peter,

not only SAPLRWCL must be in the call stack but also one of the functions AC_DOCUMENT_CREATE

or AC_DOCUMENT_GENERATE - as I tried to explain.

But probably the context is not fully understood. I did'nt know about globalized and localized interfaces quite a long time.

Regards,

Clemens

[Former Member]

Pseudo code of the program execution

BEGIN OF PROGRAM

.....SOME CODE

.....CALLS EXIT

.........ASSIGN STATEMENT ->IS OK (Even though Stack variable does not exists)

......END EXIT

......PROGRAM CONTINUES EXECUTING

.....CALLS EXIT

.........ASSIGN STATEMENT ->IS OK (Even though Stack variable does not exists)

......END EXIT

......PROGRAM CONTINUES EXECUTING

......PROGRAM CONTINUES EXECUTING on SAVE Action

.....CALLS EXIT

.........ASSIGN STATEMENT ->IS OK (Even though Stack variable does not exists)

......END EXIT

.....CALLS EXIT

.........ASSIGN STATEMENT ->IS OK (Even though Stack variable does not exists)

......END EXIT

......PROGRAM CONTINUES EXECUTING

.....CALLS EXIT

.........ASSIGN STATEMENT ->SHORT DUMPS WHY???

......END EXIT

......PROGRAM EXECUTION TERMINATED.

As per my knowledge this should not dump.....is it because we are trying to ASSIGN a stack variable that does not exists too many times??

[Former Member]

>

> Pseudo code of the program execution
> BEGIN OF PROGRAM
> 
> .....SOME CODE
> 
> .....CALLS EXIT
> .........ASSIGN STATEMENT ->IS OK (Even though Stack variable does not exists)
> ......END EXIT
> 
> ......PROGRAM CONTINUES EXECUTING
> 
> 
> .....CALLS EXIT
> .........ASSIGN STATEMENT ->IS OK (Even though Stack variable does not exists)-->here sy-subrc ne '0'
> ......END EXIT
> 
> ......PROGRAM CONTINUES EXECUTING
> 
> ......PROGRAM CONTINUES EXECUTING on SAVE Action
> 
> .....CALLS EXIT
> .........ASSIGN STATEMENT ->IS OK (Even though Stack variable does not exists)-->here sy-subrc ne '0'
> ......END EXIT
> 
> .....CALLS EXIT
> .........ASSIGN STATEMENT ->IS OK (Even though Stack variable does not exists)-->here sy-subrc ne '0'
> ......END EXIT
> 
> ......PROGRAM CONTINUES EXECUTING
> 
> .....CALLS EXIT
> .........ASSIGN STATEMENT ->SHORT DUMPS  WHY???-->here sy-subrc eq '0'
> ......END EXIT
> 
> ......PROGRAM EXECUTION TERMINATED.
> 
> As per my knowledge this should not dump.....is it because we are trying to ASSIGN a stack variable that does not exists too many times??

try like this :

data c_field(30) type c value '(SAPXXXXX)IT_ACCIT[]'.

field-symbol: <fs> type any.

assign (c_field) to <fs>.

if <fs> is assigned.

do something --->dont use Exit Command at this Point ,bcos this FM may be in Update Task mode.

endif.

[Clemenss]

Hi,

please post the full call stack on dump.

Regards,

Clemens

[Former Member]

Hi Prabhu,

I have already tried this..id di not work...the issue is not with any field symbols...but with the ASSIGN statement which works most of the times...but dumps at the end...

[Former Member]

Moderator message - Please respect the 2,500 character maximum when posting. Post only the relevant portions of the dump

Edited by: Rob Burbank on Sep 20, 2010 10:35 AM

[Former Member]

Pratik,

Do you want to put your assign statement between TRY and ENDTRY and see if that will avoid short dump?

[Clemenss]

Hi,

please post the full call stack .

You find it in debugger or in the 'programs loaded' section of the dump.

Regards,

Clemens

[Former Member]

Active Calls/Events

No. Ty. Program Include

Name

21 FUNCTION SAPLZF_COPA_CH_EXIT LZF_COPA_CH_EXITU06

Z_F_COPA_FILL_WWVEN_KEDR

20 FUNCTION SAPLXKKE ZXKKEU11

EXIT_SAPLKEDRCOPA_001

19 FUNCTION SAPLKEDRCOPA LKEDRCOPAU08

KEDR_COPA_CALL_CUSTOMER_EXIT

18 FORM RKEDRCOPA RKEDRCOPA

EXIT CUSTOMER_EXIT

17 FORM SAPLKEDR LKEDRF01

STEP METHOD_EXIT

16 FORM SAPLKEDR LKEDRF01

STEP PROCESS

15 FORM SAPLKEDR LKEDRF01

STRATEGY STEP PROCESS

14 FORM SAPLKEDR LKEDRF01

STRATEGY PROCESS

13 FUNCTION SAPLKEDR LKEDRU01

KEDR_DERIVE_CHARACTERISTICS

12 FUNCTION SAPLKEDR LKEDRU04

KEDR_COPA_DERIVE

11 FORM RK2RABC1 RKEVRK2R_FIX

DERIVATION_ITEM

10 FORM RK2RABC1 RKEVRK2R_FIX

DO_DERIVATION

9 FORM SAPLKEII LKEIIF05

DOCUMENT_FI

8 FUNCTION SAPLKEII LKEIIU05

COPA_DOCUMENT_PROJECT

7 FUNCTION SAPLKEII_00 LKEII_00U03

COPA_DOCUMENT_PROJECT_START

6 FORM SAPLFACG LFACGU03

PROCESS_TCOMP

5 FORM SAPLFACG LFACGU03

PROCESS_PROJECT

4 FUNCTION SAPLFACG LFACGU03

FI_DOCUMENT_PROCESS

3 FORM SAPMF05A MF05AFF0_FCODE_BEARBEITUNG

FCODE_BEARBEITUNG

2 FORM SAPMF05A MF05AFF0_FUSSZEILE_VERARBEITEN

FUSSZEILE_VERARBEITEN

1 MODULE (PAI) SAPMF05A MF05AIENJ

USER_COMMAND_1100

Internal notes

The termination was triggered in function "getwa_abswa"

of the SAP kernel, in line 1161 of the module

"//bas/701_REL/src/krn/runt/abgetwa.c#1".

The internal operation just processed is "ASSI".

Internal mode was started at 20100909193528.

Active Calls in SAP Kernel

Lines of C Stack in Kernel (Structure Differs on Each Platform)

(CTrcStack2+0x82)[0x6c8992]

(_Z16rabax_CStackSavev+0xe2)[0xb7bdd2]

(ab_rabax+0x4485)[0xb844f5]

(_Z11getwa_abswajjj+0x2c8)[0xb4bbe8]

(_Z17ab_DataToAttaDsegPK7AB_DATAP8BaseAttaP10AB_DATASEGj+0x183b)[0x8b5e2b]

(_Z17SymbFieldFindDatajt15SymbDataEnvKindPt13FINDSYMB_KIND16FindFieldResTypeP9FieldDesc+0xd6)[0xb3

(_Z9SymbFieldPt6HeadIdS0_PK7AB_TYPEtjt13FINDSYMB_KIND10FIELD_TYPEh16FindFieldResTypeP9FieldDesc+0x

(_Z9FindFieldPKtjj10FIELD_TYPEP9FieldDesch+0x16a)[0xb3fdca]

(_Z7AssiDynh+0x183)[0xa009a3]

(_Z8ab_jassiv+0x3dc)[0xa06dcc]

(_Z8ab_extriv+0xd51)[0x8acfb1]

(_Z9ab_xeventPKt+0x2b5)[0xa149e5]

(ab_dstep+0x1be)[0xb9a06e]

(dynpmcal+0x799)[0x72ce09]

(dynppai0+0x209)[0x72de79]

(dynprctl+0x476)[0x72f326]

(dynpen00+0x60c)[0x7210dc]

(TskhLoop+0x11cb)[0x54e96b]

(ThStart+0x1b1)[0x55ba61]

(DpMain+0x228)[0x4becf8]

/lib64/libc.so.6(__libc_start_main+0xf4)[0x2b70b5d69304]

[Former Member]

Hi Sudhi,

Thanks for your reply. But my question is WHY not HOW. So I know how to avoid the dump. What i am not sure is why it gave dump.

Thanks

[Clemenss]

Hi Pratik,

I really do not love to repeat myself, so I try to explain in more detail:

Earlier in this thread I wrote

T_ACCIT is a tables interface in function modules

AC_DOCUMENT_CREATE

AC_DOCUMENT_GENERATE

These function modules have so-called 'globalized interface'. That means that the parameters and tables passed with the function call are available as global variables in the whole function group including all subroutines.

If one of the two mentioned functions AC_DOCUMENT_CREATE or AC_DOCUMENT_GENERATE is called, and then, in a FORM routine a user exit is called, the ASSIGN of globalized parameter T_ACCIT is successful, because the data object (internal table) has been passed by the calling program as, i.e. T_ACCIT = t_accit

If the user exit call is not coming from AC_DOCUMENT_CREATE or AC_DOCUMENT_GENERATE, then T_ACCIT does not have any reference at run time.

Your call stack does not show AC_DOCUMENT_CREATE or AC_DOCUMENT_GENERATE, not even frame program SAPLRWCL.

So T_ACCIT just does not exist here as a data object.

The dump is only possible with and a result of the obsolete interface globalization technique: Field T_ACCIT technically exists, but is not assigned to any data object because this only happens when tables parameter T_ACCIT is passed by the calling program of AC_DOCUMENT_CREATE or AC_DOCUMENT_GENERATE.

The same will happen if you

ASSIGN <fs1> TO <fs2>.

if <fs1> is not assigned.

Regards,

Clemens

[Former Member]

Li,

Sorry I did not get your point initially...yes tables parameter in function module interface is called by reference.

Though i really did not understand why it did not dump in the first place. Probably the reference variable was loaded then!!

i tried to simulate the scenario..and it did gave dump consistently.

FIELD-SYMBOLS: <lf_updt_evtlog> TYPE zxs_updt_evtlog,

<lf_updt_evtlog1> TYPE zxs_updt_evtlog .

CONSTANTS: c_reference TYPE char30 VALUE '<LF_UPDT_EVTLOG1>'.

ASSIGN (c_reference) TO <lf_updt_evtlog>.

This always gave dump GETWA_NOT_ASSIGNED.

Many thanks to you.

Pratik.

[Former Member]

Hi,

One additional thought - do you ever change the contents of the c_accit field? I don't want to assume it's a constant by the prefix...

c_accit TYPE char20 VALUE '(SAPLRWCL)T_ACCIT[]',

If you never change the contents of this variable then, then this shouldn't help make a difference but where you assign the field symbol, maybe it's worth trying a hard-coded (not pretty) value, ie.

ASSIGN ('(SAPLRWCL)T_ACCIT[]') TO <fs_accit>.

Like I said, if this really is a constant, shouldn't make a difference but since c_accit is only 20 characters, if you change the value then 20 characters might not be enough.

Also, could you please provide the code section from the short dump, indicating the line where the error is occurring? Just wanted to confirm it's showing the ASSIGN command as the point of failure. Also, if you could check that C_ACCIT is populated as you think when the ASSIGN command is executed, when it fails...

Thanks, Andy

[former_member183990]

is this is a global variable T_ACCIT[]?

check for its value at the time when you are getting this dump, it could be a data issue

and in ST22 analyse the cause for the error, why the field symbol ends up in dump, check this..

Thanks

S.Janagar

Edited by: Janagar Sundaramoorthy Nadar on Sep 11, 2010 3:40 PM

[Clemenss]

Hi Janagar and Pratik,

T_ACCIT is a tables interface in function modules

AC_DOCUMENT_CREATE

AC_DOCUMENT_GENERATE

Both functions are in function group RWCL and have globalized interface (obsolete technique, says SAP) so the field T_ACCIT is known in all subroutines called from there.

That means, that T_ACCIT is available only if the exit function gets called (indirectly) from those functions. If the exit is called from one of the other functions in the group, i.e.

AC_DOCUMENT_COMPRESS_CHECK
AC_DOCUMENT_CVTYP_GET
AC_DOCUMENT_DELETE
AC_DOCUMENT_DISPLAY_INTERNAL
AC_DOCUMENT_GETAPPLLINKS
AC_DOCUMENT_MM_NO_UPDATE
AC_DOCUMENT_MM_UPDATE
AC_DOCUMENT_POST
AC_DOCUMENT_QUANTITY_GET
AC_DOCUMENT_RECORD
AC_DOCUMENT_REVERSE
AC_DOCUMENT_SENDER
AC_DOCUMENT_SENDER_FSBA
AC_DOCUMENT_SENDER_HRPAY
AC_DOCUMENT_SENDER_TRAVL
AC_DOCUMENT_SENDER_VBAK
AC_DOCUMENT_SENDER_VBRK
AC_DOCUMENT_SHKZG_CORRECT
AC_PAYMENTBLOCK_CHECK
AC_PAYMENTBLOCK_UPDATE
AC_VALUATION_PRESENT
BAPI_ACC_DOCUMENT_DISPLAY
BAPI_ACC_DOCUMENT_RECORD
FKK_AC_DOCUMENT_FICA,

the T_ACCIT is not available and the dynamic assignment will result in a SY-SUBRC <> 0.

If you use the field-symbol in this case, then it is not assigned (the more if the unnecessary UNASSIGN has been used) and you will get the dump.

I'd assume that if T_ACCIT is not available you just do not need it.

Please read your dump again to see that the dump does not occur with ASSIGN statement

Regards,

Clemens

[Former Member]

Hi,

Is T_ACCIT[] defined as a global field in the function group or is it a passed internal table into the function module on the call stack?

If the latter, then you may need to consider looking further up the call stack to get the global internal table from the routine which calls the FM (or even higher in the call stack).

Regards, Andy

[Former Member]

Probably the original variable with the table disappears from the memory.

[Clemenss]

Please see my complete analysis Posted: Sep 11, 2010 6:40 PM .

Regards,

Clemens

[Former Member]

data: c_accit(30) VALUE '(SAPLRWCL)T_ACCIT[]'.


ASSIGN (c_accit) TO <fs_accit>.

if sy-subrc eq 0.
Normal program flow.
else.
Exception Handling/Exit Logic
endif.