EXPORTING LIST TO MEMORY and its dangers

From time to time there is a need to run another report from our own code and in such situation we have to access its output in some trick way.

There is a nice solution for this – we can call report in such a way from our code:

SUBMIT report EXPORTING LIST TO MEMORY 
              AND RETURN. 

And later in our code we can read its output this way:

CALL FUNCTION 'LIST_FROM_MEMORY' 
  TABLES 
    listobject = list_tab 
  EXCEPTIONS 
    not_found  = 1 
    OTHERS     = 2. 

But how does it work? The output from report is available throughout ABAP memory. Every time we call another report SAP automatically exports basic list to memory for our future use.

This is really handy but there is small trick here. Let’s consider the following code from SAP documentation:

DATA list_tab TYPE TABLE OF abaplist. 

SUBMIT report EXPORTING LIST TO MEMORY 
              AND RETURN. 

CALL FUNCTION 'LIST_FROM_MEMORY' 
  TABLES 
    listobject = list_tab 
  EXCEPTIONS 
    not_found  = 1 
    OTHERS     = 2. 

IF sy-subrc = 0. 
  CALL FUNCTION 'WRITE_LIST' 
    TABLES 
      listobject = list_tab. 
ENDIF.

Have you ever wonder what is inside LIST_FROM_MEMORY module? There is a short code:

import LISTOBJECT from memory id '%_LIST'.

So every time we use “exporting list to memory” sap fills %_LIST variable in memory for us. But what happen if there is no output from our report? Well it is possible that there will be there some output anyway from previous call to submit!

Not possible? Let’s give it a try:

1. Report that writes it’s name.

report  z_test_1 no standard page heading.

write sy-cprog.

2. Report that is giving no output at all.

report z_test_2.

3. The final report that calls 1 & 2.

report  z_test_3.

data list_tab type table of abaplist.

submit z_test_1 and return exporting list to memory.
submit z_test_2 and return exporting list to memory.

call function 'LIST_FROM_MEMORY'
  tables
    listobject = list_tab
  exceptions
    not_found  = 1
    others     = 2.

call function 'WRITE_LIST'
  tables
    listobject = list_tab
  exceptions
    empty_list = 1
    others     = 2.

And our result is:

Z_TEST_1

So summarizing we have to release %_LIST variable each time before we will make a submit call in this way:

call function 'LIST_FREE_MEMORY'.

Let’s now imagine that we are calling credential report with single employee ID in a loop and from time to time there is a bug in this report that causes no output to the screen – that’s a real disaster! 😉

Hope you enjoyed this article. See you next time!