cancel
Showing results for 
Search instead for 
Did you mean: 

GENERATE_SUBPOOL_DIR_FULL issue - also in 6.40?

maximilian_schaufler
Active Contributor
0 Kudos

Hi fellows,

after implementing some dynamic table creation in my MVC application I came across this GENERATE_SUBPOOL_DIR_FULL error, and found this topic in ABAP forum:

I read that for the WebAS 6.40 approach removes some of theses issues, this might be one of them.

Does anybody know of similar problems that occur or occur not when using 6.40?

*) As the 6.40 kernel can also be used for 6.20 installations ... will upgrading the kernel affect or even solve this problem in any way? (or make the 6.40 approach possible?)

Thanks for reading (and answering),

Max

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Background

After using CL_ALV_TABLE_CREATE=>CREATE_DYNAMIC_TABLE, I suddenly ran into severe error's in production and lot of dump's with the message 'GENERATE_SUBPOOL_DIR_FULL'. The system is 6.20 with IS-U. I looked through many of the solutions provided in SDN but did not found a useful solution. Here I will provide a solution. My use of dynamic tables are done as I have a super class with methods that needs to deal with different subsystems own configuration tables. My need of dynamic tables was VERTICAL (dynamic table names) where you maybe need HORISONTAL (dynamic field names). This solution provided are only for those of you with the need of vertical dynamic table names (80% of the problems about this subject) and where the structure name is registered in data dictionary.

Symptom:

In a system where you need to work with a number of dynamic tables, and are used to use CL_ALV_TABLE_CREATE=>CREATE_DYNAMIC_TABLE you get an abap shortdump with the error message u201CGENERATE_SUBPOOL_DIR_FULLu201D. You are working on a 6.20 system.

Reason:

SAP has the restriction of max Up to 36 temporary subroutine pools can currently be managed for each roll area. The use of subroutine pools is done behind the scene when using this standard class. Often you call other functions or classes that also uses generate subroutine pools and might therefore have fewer possible number of dynamic tables.

Posible solution:

If you can live with the restriction of only using dynamic tables where the structure exists in the datadictionary you can create the internal table like this. The example is only for standard tables, but you can create other types af tables as well.

" Create internal table and return a ref to data

CREATE DATA y_dy_table TYPE STANDARD TABLE OF (x_structure).

" Create buffer/header for the created table

CREATE DATA y_dy_line TYPE (x_structure).

Where :

y_dy_table TYPE REF TO DATA u201CThe internal table

y_dy_line TYPE REF TO DATA u201CThe buffer/header

x_structure TYPE STRUKNAME u201CThe datadic strukture

as result you have the dynamic internal table and the buffer/header as TYPE REF TO DATA.

thomas_jung
Developer Advocate
Developer Advocate
0 Kudos

1. This is happening because the CREATE_DYNAMIC_TABLE is acutally generating code on the fly. That is really the core of the problem with this solution. This is what makes the functionality in 640 so nice. Instead of dynamically generating code, the language itself opens constructs to dynamically generate internal tables (actually memory constructs of any type).

2. The 640 approach does NOT have this limitation. That is one of the primary reason for the introduction of this new functionality. (It is also a much more effecient way of acomplishing this).

3. Sorry but the 640 kernel alone doesn't cut it. You have to have a full 640 system, not just a 640 kernel on top of a 620 system. Although the functionality is there in the Kernel, the ABAP Classes that interact with the Kernel and expose this functionality haven't been updated yet.

maximilian_schaufler
Active Contributor
0 Kudos

Ok, move to 640 is not possible before going live with this application (though it is planned) ... so back to my problem:

Trying to implement the workaround together with the creation of dynamic tables (links in previous post) I ran into several problems, which I'm currently trying to solve - but no success so far.

You think maybe you could complete the code for this?

- call of the program from within the model method, which would replace my current call:

CALL METHOD cl_alv_table_create=>create_dynamic_table
  EXPORTING
    it_fieldcatalog = lt_fieldcatalog
  IMPORTING
    ep_table        = lt_data.

- whole code for the program that is going to be called

My limited ABAP experience makes me struggle, as I don't think I understand all of this and how to customize it:

<b>Main Program</b>

  ...
  EXPORT <whatever is needed> TO MEMORY ID 'ABC'.
* Execute the code generation logic in new internal mode
  SUBMIT <Sub Program> AND RETURN.

<b>Sub Program</b>

  ...
  IMPORT <whatever is needed> FROM MEMORY ID 'ABC'.
* Logic to generate the internal table of ABAP code
  ...
  GENERATE SUBROUTINE POOL <codetab> NAME gv_program.
  IF SY-SUBRC EQ 0.
    PERFORM <generated form> IN PROGRAM (gv_program).
  ENDIF.

thomas_jung
Developer Advocate
Developer Advocate
0 Kudos

I'm afraid that the work around you found may not function for you. You see the method create_dynamic_table is what is generated in the subroutine pool. The work around really doesn't expect you to use the generated code to create an internal data table that you then pass back to the calling program. Therein lies the problem. If we do the submit program, how do we get our internal table back?

I'm going to have to try a few things. You might be able to do an extra export to a different memory id after the dynamic generate. Then you could do another import from the calling program after the submit and return to get the data table back. I need to test that idea first though.

Former Member
0 Kudos

Max,

One thing would be to try and post this question ALSO in ABAP forum, as there are many more stalwarts, many more brains, someone or the other could give a better solution.(Even Horst Keller, the ABAP guru posts in ABAP forum. So getting the problem solved, just has a higher probability).

How about posting the problem you have at hand i.e. the need to generate a dynamic internal table ?

CREATE_DYNAMIC_TABLE is one way, probably there are a few other ways, by which we can tackle the problem at hand.

Regards,

Subramanian V.

maximilian_schaufler
Active Contributor
0 Kudos

Thx for the reminder, Subramanian, I have done so now ()

maximilian_schaufler
Active Contributor
0 Kudos

Just to let you know, my need to find a solution for this problem is not that urgent anymore, as I think I found another way to handle my algorithmic logic, which does not need dynamically created tables.

So unless you're very close to a solution or want to keep working on it anyway, you don't have to pursue working on this special problem.

Thx for any help,

Max