memory id cleared unexpectedly

[Former Member]

All,

To begin with this logic has been in our production systems working fine for at least 2 years; it works in 4.5B and continued to work after we upgraded to 6.0. Some changes to the system has made this program work differently and I need some guidance to determine the root cause.

We have a user exit that calls a subroutine and just after that subroutine we export to a memory id. This memory id is then later used in a different user exit.

So the code is like this:

Perform XYZ

Export ABC to memory id "ABC"

We found in debug that ABC was being cleared before we were able to export it to the memory id.

==============

To fix this issue we moved the EXPORT statement within the subroutine.

Any ideas what might cause this to happen?

Regards,

Sandra

[former_member194669]

Try this way

Perform XYZ using ABC. " Pass back the ABC in the subroutine Instead of using export inside a subrouine

Export ABC to memory id "ABC"

a®s

Edited by: a®s on Jan 15, 2009 11:00 AM

[Former Member]

Hi Sandra,

Usually Exporting to a memory ID would persist during the current work process. Hence if you havent mentioned explicitly to execute perform in a new task it should be available.

Also look if in some modification someone might have explicitly FREE the ID.

In addition you could make use of ABAP shared memory where data would persist even after the execution is over and hence may prove useful to you.

Revert if u need anything more.

[Former Member]

Ankesh,

How might I find if someone explicitly FREE the ID.

Recall no changes have been made to our code so this FREE ID would have to be somewhere else.

Sandra

[Former Member]

I guess if someone has put it in the code then it must be there in any of the objects that are getting executed.

Like your current set of programs.

You could do a global search in each of it.

Or you could set a break point on command FREE ID... during debugging.

[Former Member]

Hi,

What is the scope of the variable ABC ? I'm assuming it is global to the program.

Do a where used on that variable in the ABAP editor and see if any statement is clearing this variable before subroutine XYZ is called.

regards,

Advait

[Former Member]

Advait

Yes it is global to that program and doing the where used on the variable there is a clear statement at the beginning of the subroutine that eventually finds the value for ABC.

Sandra

[Former Member]

Well, that is strange then. So there could be 2 possible reasons :

1. The value is not getting exported to the memory id at all :

In this case,you should try to debug the program and check the value of the memory id 'ABC', in the ABAP Memory area, in the debugger's menu option Goto>System Areas>ABAP memory after the export statement and just before the import.

2. The memory id is being cleared somewhere after the export and before the corresponding import :

Since import/export is ABAP memory only and can be referenced within only one internal session, you can further debug the program until you reach the point where the memory id 'ABC' is imported . Remember to put a breakpoint on the statements 'FREE' and 'IMPORT' when the debugger starts.

regards,

Advait

[Former Member]

All,

My apologies for not explaining the situation better. It was my not being an abap developer and just not thinking through the problem correctly. I'll try this again.

SAMPLE code:

PERFORM XYZ

EXPORT TAXCODE to memory-id

FORM XYZ

TAXCODE = "ABC"

ENDFORM

Some how the TAXCODE variable is cleared from the time it is returned from the FORM XYZ and the time the EXPORT statement is performed. There is NO other code between the PERFORM and the EXPORT statements.

It works fine like this in at least one production system (that is the TAXCODE is not cleared). In a different system we have had to move the EXPORT statement to just before the ENDFORM.

So again my apologies it has nothing to do with the memory id.

Regards,

Sandra

[Former Member]

Hi Sandra,

Never mind.

So in that case is your query resolved?

Also tracking just the variable should not be much of a problem. Just ensure the variable is not defined again within the perform or somewhere in between. This could be a reason for it getting cleared.

To check it u can temporarily transfer the content to another variable TAXCODE1 which is global in nature...if this variable persists then there is some problem in declaration of TAXCODE.

All the Best !

[Former Member]

Ankesh,

Excellent suggestion. Since I'm not the one making the code changes, I'll need to wait until next week to see what the result is.

Thank you,

Sandra

[Former Member]

I'm sure none of you will be surprised about our findings. We found that a different group had modified a user exit and redeclared the global variable in their user exit. Even though our process does not branch to that user exit, the redeclaring of that globally declared variable is what caused the issue.

Thanks all for your help with this.

Sandra