Alternative to CL_ALV_TABLE_CREATE=>CREATE_DYNAMIC_TABLE
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.
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.
cl_alv_table_create=>create_dynamic_table( EXPORTING it_fieldcatalog = lt_fieldcat_lvc IMPORTING ep_table = grt_std EXCEPTIONS generate_subpool_dir_full = 1 OTHERS = 2 ).
zcl_alv_table_create_rttc=>create_dynamic_table( EXPORTING it_fieldcatalog = lt_fieldcat_lvc IMPORTING ep_table = grt_std EXCEPTIONS 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.