Removing or destroying an ABAP program from memory

[Former Member]

Hello!

Is there a command to kill, unload, remove or destroy a previously called ABAP program from memory? Let me explain what I'm trying to do:

I'm doing some WM developments and I use the function L_TO_CONFIRM to confirm transfer orders. This function belongs to function group L03B (program SAPLL03B) and eventually it makes external calls to subroutines belonging to program SAPML03T.

If my Z program calls this funcion, the SAPLL03B program is responsible for loading SAPML03T into memory and everything works fine. The loaded programs list (on the debugging menu) are like this:

No Program Group with

52 SAPLL03B

78 SAPML03T 52

This is also what I get if testing L_TO_CONFIRM from SE37, where it also works.

But I wanted to reuse some subroutines from SAPML03T on my Z program, so I call something like this:

 
PERFORM set_quit_icon(sapml03t) ...

This call happens before the function call, so SAPML03T gets loaded by my Z program first, and stays on the memory. The list of loaded programs then looks like this:

No Program Grouped with

1 ZWMO_023

27 SAPML03T 1

So after calling the external subroutine in SAPML03T, I do some more coding and finally call the function L_TO_CONFIRM. Inside this call, my list looks like:

No Program Group

1 ZWMO_023 => My Z program

27 SAPML03T 1

28 SAPLL03B

So SAPML03T is grouped with my Z program and not SAPLL03B as it would be if I hadn't called the external subroutine first.

Now, the problem:

Since SAPML03T and SAPLL03B apparently share some global data (at least global workarea/table LTAK), in a normal call (SAPML03T)LTAK gets filled by a select statement and instantly (and somewhat inexplicable from what I new until now) (SAPLL03B)LTAK also gets filled by the same data. Well, I've only seen stuff like this with field-symbols but this is not the case. I would bet this two workareas would always be in fact two different workareas, but during the straight function call they are not. They are the same (I wish I could find their pointer addresses (like C++ stuff) to prove they were the same, but I couldn't). But if I call the external subroutine first and SAPML03T gets loaded, then I do have two different LTAKs and that's where I have problems, because L_TO_CONFIRM was coded considering this single workarea thing and when I have two, it doesn't work.

[Former Member]

Now, what I would like to do:

I would like to call the external subroutine and get it's return data

SAPML03T would then be loaded

I would call some special command to kill this program from my LUW

Then I would call L_TO_CONFIRM and it would start a new, normal load of SAPML03T and SAPLL03B and everything would work just fine

Please note that this is a purely technical question. This is not a WM, functional or whatever question, and the problem is not with the WM functions or the Z program. In fact I already did a workaround on this problem by not calling the external subroutine and for this project, that's final the solution. I just would like to know if there is some way to remove this program from memory.

Thank you very much,

Sergio

[Former Member]

just a thought; u can try calling ur FM in a NEW TASK as a seperate LUW.......not sure this works!!

thanq

[Former Member]

Yes, I tought about that.

As a matter of fact, just last week we had another global memory issue in a costing user-exit and we tried solving it with a STARTING NEW TASK. This initialy solved our problem, but this command leads to the opening of a new gui session, and when running this cost calculation procedure in the background, a short dump COMMUNICATION FAILURE was raised, probably because of the lack of a SAP GUI link. We then used DESTINATION 'NONE' and this solved the problem (I think it also opens a new LUW).

Also my WM problem is on a Z application that will be running under SAP Console, and I don't think opening a new GUI session with STARTING NEW TASK under SAP Console will work. I should try it anyway. - edited: I just remebered I did this a couple years go and it works

I could use DESTINIATION 'NONE' in this case too, since the funcion module is RFC-enabled already. There are a few ways to solve the problem (which is already solved by the way). My main question still is about removing a whole program from SAP memory through ABAP commands.

Thank you very much!

[Former Member]

This all sounds very complicated... and destination NONE is a pain.

Perhaps what you are looking for is STATICS in your exit? See transaction ABAPDOCU for the statemant documentation.

Cheers,

Julius

[Former Member]

Thanks, but STATICS can't solve my problem. The problems happen inside standard function modules and I can't change the data declarations inside it. And the problem is in global data objects and not local data.

Why do you say destination NONE is a pain? Is there anything against using it?

Back to my problem, I'm guessing there is no way to remove a single program from the SAP memory. Maybe if you or one of the top guys in this forum could tell me this can't be done, I will consider this question solved (if a problem can't be solved, there is no problem, right?).

Thank you very much!

[Former Member]

My main question still is about removing a whole program from SAP memory through ABAP commands.¨

I am afraid that I don't know the answer to that, which in no way means that it cannot be done (perhaps even easily :-).

There was a related discussion once before about shared memory objects which you might find of interesting as well:

Destination NONE is a pain for me as I often do tracking and logging of RFC calls for security work. It fills up the logs with loads and loads of data, but by default the information is not needed. This leads to many misunderstandings of the object S_RFC.

Cheers,

Julius

[Former Member]

Thanks for the link. Nice discussion there!

Maybe I should post this thread on Coffe Corner too.

[Former Member]

Hi Sergio,

Did you find any command/object to unload already loaded program @ run time. We are also facing the same issue. Thanks a lot.