Using WATCHPOINT to determine when MEMORY ID value is being reset

[loyd_enochs3]

Greetings:

I am debugging a custom transaction which uses the syntax EXPORT... MEMORY ID to pass the value of a Selection-Screen PARAMETER to standard SAP customer exit EXIT_SAPLFMDT_001 and its include program ZFMMDTU01.  This is used for Manual Cost Allocations and its' FMDERIVE functionality.

The custom transaction is used to parse and edit an input file of spreadsheet data and pass that data to BAPI_ACC_MANUAL_ALLOC_POST.  It sets the value of EXPORT value once for all records of an input file to pass the overall processing option selected by the user to the customer exit logic.  Once the BAPI is called, it calls the logic of the customer exit in a loop and uses IMPORT for each record in the input file to determine the processing option and act accordinly.

Problem: On the first pass of the loop, the logic in ZFMMDTU01 uses IMPORT and gets the value set on the screen and exported to the MEMORY ID location, but on the second and all subsequent loop passes, the IMPORT value returned is blank.  I have looked at all the other code in the customer exit and did not discover any code changing the value.

I can find the memory management option in Classic Debugger/System Areas that tells me the MEMORY ID exists, but not the current value.  That precludes me from following the debugger through the entire BAPI looping process to find what is overwriting the MEMORY ID value.  I have looked in the New and Classic Debugger trying to find a way to set a WATCHPOINT for the MEMORY ID and have failed. 

Question: How is a WATCHPOINT set on a MEMORY ID in the Debugger so that I can find the offending statement that is clearing out that MEMORY ID?

Thanks in advance for your expertise,

Loyd Enochs

[Former Member]

Hi,

I'm not sure if there is a standard way of doing such thing , but I'm sure you can achieve this using debugger scripting (check the MEMORY ID in each debugger step and stop when use see it has been changed)

[loyd_enochs3]

I marked this assumed answered.  I no longer work at the site where the problem was encountered and cannot test any potential solution.

[Sandra_Rossi]

I know you just closed the thread, but in case someone else finds your question, here is my 2 cents: you may add a breakpoint at statement (F9 in the debugger) "FREE MEMORY", to stop at all ABAP memory emptying (DELETE FROM MEMORY and FREE MEMORY). In the custom code, be careful of not using FREE MEMORY without any addition (which is obsolete) because it clears the whole ABAP memory. In case there's an EXPORT which clears the memory, you may also add a breakpoint at statement "EXPORT TO MEMORY". Of course it will stop at every memory ID, so it may be more useful to trace all statements using transaction SAT (with mode "no aggregation"), and there will be one line for every EXPORT TO MEMORY, DELETE FROM MEMORY, ..., along with the memory ID.