getting around GENERATE_SUBPOOL_DIR_FULL and returning data?

[maximilian_schaufler]

Hi there,

I'm trying to get around the GENERATE_SUBPOOL_DIR_FULL error in my application, hope some of you can help me with this:

*) The problem:

I'm implementing part of an application previously written in PHP to my WebAS application designed in MVC (object-oriented). In this program logic I kind of create a matrix (variable rows and columns), which I loop over a few times, modify/alter it (not only the values, also change number of columns).

*) My approach:

Reading the the weblog about <a href="/people/subramanian.venkateswaran2/blog/2004/11/19/dynamic-internal-table">Dynamic Internal Tables</a> I thought that's the way to go, tried it, worked fine, until there are some more loop iterations, cl_alv_table_create=>create_dynamic_table is called more often, exception is thrown.

After searching the forum, I found <a href=" topic (how to get around GENERATE_SUBPOOL_DIR_FULL)</a>, but now I'm facing some questions I hope to get help with here:

First of all I'm only working with ABAP for 5 months now - object-oriented development is not the problem, but I don't have any experience in dealing with sub programs, memory management and other similar issues in ABAP. So this code here is not totally clear for me:

<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.

It comes down to something like this:

I want to be able to replace or change this call

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

with some call to another program to not run into the GENERATE_SUBPOOL_DIR_FULL exception anymore - if this is a possible way to get around it!

Getting back the reference to the created table is important, because I use it as my "matrix" in my program logic.

Any help on this is appreciated!

Best regards,

Max

[maximilian_schaufler]

Have you already tried to bypass the Subpool limitation by RFC or submits as described in:

Best Regards

Klaus

[former_member183804]

Have you already tried to bypass the Subpool limitation by RFC or submits as described in:

Best Regards

Klaus

[maximilian_schaufler]

I did try to place the call cl_alv_table_create=>create_dynamic_table in a function, but this still throws the exception.

And trying to use the submit I'm not even able to get the sub program working, because of my lack of knowledge with subroutine pools - so I don't know if that would work or not ... does anyone have a complete code sample for a sub program like this?

Also, how will I get back the reference to the created dynamic table into the main program?

Thx,

Max

[maximilian_schaufler]

Ah, should also mention that I'm running on 6.20 ...

[Former Member]

Hi Max,

I started working up an example, trying a few different approaches, but haven't finished yet.

The reason why the function didn't make a difference is because a call to a function module executes in the same internal mode (roughly memory space) as the calling program. To avoid the 36 subroutine pool generation limit (that CL_ALV_CREATE_TABLE uses), you must generate the internal table in a separate internal mode (which is easiest done with SUBMIT ... AND RETURN).

The problem is that even with this approach, you can only use that dynamically created table in the internal mode. It will not be possible pass that internal table back to the "main program".

Whether that is an acceptable restriction really depends on what your trying to do. For example, if in your case you only need the dynamic table to generate HTML (I see your question originated in the BSP forum), then you can probably generate the internal table in the separate mode, and then just pass a HTML stream back to your "main program".

However, if you really must have the dynamic internal table defined in your main program, then to avoid the generation limit, in my opinion, you will have no choice but to generate the internal table definitions in ABAP programs that are persisted in the repository. I know that will work in 4.6, not so sure about 6.20.

Bear with me for a bit and I will try to post a code sample or weblog.

Cheers,

Scott

[ChristianFi]

You wrote:

"Reading the the weblog about Dynamic Internal Tables I thought that's the way to go, tried it, worked fine, until there are some more loop iterations, cl_alv_table_create=>create_dynamic_table is called more often, exception is thrown."

Have you read the comments as well?

Depending on how dynamic your internal table must be, you could sonsider the create data statement.

Since you are on 6.20 it should work with tables, too.

Christian

[maximilian_schaufler]

Hi Scott,

thx for your effort in explaining the problem and trying to find a solution!

In the meantime I tried to simplify my basic algorithm problem, I was able to reduce to amount of different data types I need to just one, therefore I create my matrix like this:

One table to hold an index-value and another table, which represents my "column" in the matrix.

I think I can get my program running with just these few data types I created in the dictionary, no urgent need for dynamic tables anymore.

So, unless you're interested in finding a solution for this anyway (and create a weblog or so), I don't push you to keep working on it. Not finished with my new approach, but looking quite good atm.

Keep it up, thx again,

Max

[maximilian_schaufler]

Hi Christian,

thx for the reminder, I did only skip through it in the beginning and then got stuck with trying to get the main code working.

As you can read from my previous post (we wrote at the same time obviously), I don't have to continue trying to get dynamic tables working, so I will put this problem aside for a while (or even forever, as move to 640 is planned for Q1 or Q2 next year anyway).

Max

[Former Member]

This message was moderated.

[Former Member]

Alternative..

this worked for me...but not sure the requirement is the same.

instead of calling CALL FUNCTION 'LVC_FIELDCATALOG_MERGE'

and CALL METHOD cl_alv_table_create=>create_dynamic_table,

i used the following:

1. DATA: infty_tab_pointer TYPE REF TO data.

CREATE DATA infty_tab_pointer TYPE standard table of (structure).

2. ASSIGN infty_tab_pointer->* TO <infty_tab>.

FIELD-SYMBOLS: <infty_tab> TYPE TABLE.

<infty_tab> became my internal table.

Will this work?

Bill

[Former Member]

This will work, however this is available only from 4.7 (WAS 6.20), so it does not work for 4.6c.

Regards,

Ravi