Skip to Content
Technical Articles


TL;DR If you have a short dump GENERATE_SUBPOOL_DIR_FULL due to CL_ALV_TABLE_CREATE=>CREATE_DYNAMIC_TABLE, here is a method which replaces it and avoids the short dump. It has exactly the same parameters.

Before RTTC (release 6.40 in 2004), the solution to create a variable of a type known only at run time was possible by using the dynamic generation of ABAP code with GENERATE SUBROUTINE POOL.

Instead of building the ABAP code line by line, it was more convenient to call the static method CL_ALV_TABLE_CREATE=>CREATE_DYNAMIC_TABLE, which uses internally GENERATE SUBROUTINE POOL, to which you pass an ALV field catalog, and it returns the internal table corresponding to the catalog. It was used even if no ALV was displayed, for instance for storing the result of a dynamic SELECT (with columns or table only known at run time).

The big issue of GENERATE SUBROUTINE POOL is that it raises the short dump GENERATE_SUBPOOL_DIR_FULL if it’s called more than 36 times in a given internal session.

If you are using CL_ALV_TABLE_CREATE=>CREATE_DYNAMIC_TABLE and you experienced such a short dump, then you may solve this problem by replacing the standard static method with the static method ZCL_ALV_TABLE_CREATE_RTTC=>CREATE_DYNAMIC_TABLE at github, which has exactly the same parameters but avoids the short dump because it creates the internal table with RTTC.


          it_fieldcatalog           = lt_fieldcat_lvc
          ep_table                  = grt_std
          generate_subpool_dir_full = 1
          OTHERS                    = 2 ).


          it_fieldcatalog           = lt_fieldcat_lvc
          ep_table                  = grt_std
          generate_subpool_dir_full = 1
          OTHERS                    = 2

Note that the exception GENERATE_SUBPOOL_DIR_FULL is still there for keeping the compatibility with the standard method, but it cannot happen anymore.

Note that there are also 3 standard function modules which call the static methods of CL_ALV_TABLE_CREATE (REUSE_ALV_CREATE_TABLE, ALV_CREATE_TABLE, LVC_CREATE_TABLE), so you might replace their calls with the corresponding static methods of ZCL_ALV_TABLE_CREATE_RTTC.


You must be Logged on to comment or reply to a post.
  • One problem I found with using this call recently was that the user wanted me to add colors to the dynamic ALV and I found it impossible to specify¬† a "LVC_T_SCOL" table in the fieldcatalog.

    I then switched over to using CL_ABAP_STRUCTDESCR to define the ALV layout via a combination of static structure and dynamic types and then used CREATE DATA to instantiate my dynamic table.

    • CL_ALV_TABLE_CREATE=>CREATE_DYNAMIC_TABLE only handles the creation of a column XYZSTYLEZYX of type LVC_T_STYL by setting the parameter I_STYLE_TABLE = 'X'. Feel free to propose a pull request to extend ZCL_ALV_TABLE_CREATE_RTTC (with a new parameter I_COLOR_TABLE for instance) or to raise an issue.

  • Hi Sandra

    Hope you are doing well.

    This class/approach is exactly what we are looking for to overcome the generate_subpool_dir_full  36 instance limit. I created the PUBLIC class today and called it from a copy of CL_FDT_XL_SPREADSHEET in method GET_RANGE_ITAB_FROM_XMLDOC.

    Sadly I am getting a short dump in method FB_TABLE_CREATE_STRING because the logic does not pick up the INTTYPE 'g' and therefore the field catalog is not fully constructed.

    I could be missing the point somewhere (it has happened before) and I am fairly new to GitHub, could you kindly offer some help in this matter?

    Have a great day, Derek (Shaun)

    • Hi Derek (Shaun)

      Thank you. I have seen a big bug in the code (ELSE missing), and I have uploaded the corrected code.


  • /
    • I guess you are using an old ABAP version.

      Try this workaround and tell me whether it works:

      DATA type_name TYPE string.
      type_name = ls_fieldcat-ref_tabname && '-' && ls_fieldcat-ref_fieldname.
      ls_comp_type ?= cl_abap_typedescr=>describe_by_name( type_name ).