Maximum number of sessions reached

[former_member656551]

Hello everybody,

I have the problem that one program throws the dump "message_type_x" with the description "Maximum number of sessions reached". The reason for this is that a user has the maximum number of sessions open and than uses the custom program, wich executes

submit x using selection-set y
with a In b ...
and return.

this opens a additional session which leads to the error.

Atleast this is what I think.

Is there a way to execute this in background?

[Gourab_Dey]

User doesn't get the error if he has 5 sessions?

[former_member656551]

Good question. He never works with less than 6 sessions. But we can't raise the maximum number of sessions at once.

[FredericGirod]

transaction ABAPDOCU, search keyword "submit" there is the job option to run in background.

[Gourab_Dey]

Hi Frederic, I have a doubt. So, whenever we submit the program, it uses a different workprocess?

[matt]

gdey.sapabap This is correct. As I found out when I tried to buffer some data in a static attribute of a class, and the buffer was empty when I submitted a program.

[matt]

Refactor your program X, so that all the actual work is done in a class. I.e. X only has select-options and parameters and validity checks and other screeny type things. If you invoke the class like this:

START-OF-SELECTION.
  NEW zcl_x_model( i_plant_range = s_werks[] ).

then in your other program, where you currently have submit, use

DATA(range_of_plants) = VALUE ty_range_of_plants( SIGN = 'I' OPTION = 'EQ' LOW = '1000' ).
NEW zcl_x_model( i_plant_range = range_of_plants ).

This means a) you don't have a session limit and b) you've taken a step toward decoupling your code and make it better and rather more modern.

[Sandra_Rossi]

Did you post this answer to the right question?

[matt]

sandra.rossi Oh yes. The idea is to get rid of the SUBMIT entirely. Of course, you can only do this is the submitted program isn't standard.

[Sandra_Rossi]

SUBMIT is definitely unrelated to the number of user sessions.

Instead, probably that your program X opens a new user session via RFC but doesn't catch the exceptions of type "communication failure".

[tom_wan]

I think the first point is: the session you mentioned, is internal session or external session.

SUBMIT...AND RETURN will open a internal session, not external session. (see ABAPHELP)

If the error is "Maximum number of internal sessions reached", then the issue has nothing to do with how many GUI windows your users opened. You need to check why your program opens so many internal sessions.

You can take a look at SAP Note:

2382232 - [Basis] Maximum number of internal sessions reached

If the error is caused by external session, as sandra.rossi mentioned, inside your program x you must doing something that opens a external session.