Locking a work process for exclusive access

[Former Member]

Hi Gurus,

I have a special need for a an ABAP program, to run on the very same dialog work process during all the steps of its execution. The program normally has multiple dialog steps. Additionally, I need that work process to be dedicated to my program exclusively so no other programs will use it until my program terminates - it should be idle between my program dialog steps and not serve other programs.

I had one idea of implementing it, which will probably work - intentionally consume large bulks of memory as the program starts and then the work process will switch to private mode (PRIV) and will be exclusive until my program terminates.

Apart from being very inelegant, this approach has major drawbacks:

1. It is not exactly clear how much memory should I consume

2. It is not healthy for the application server

3. Consuming large amounts of memory takes a long time

So I'm searching for alternatives.

One possibility is to use LOCK: according to SM50 one of the work process reasons for waiting is called 'LOCK' and its documentation is "Work process assigned exclusivel to one user for system analysis".

I figured it might be useful to use this LOCK status but I don't know how it is done, probably some kernel call - if anyone knows how to accomplish this it would be fantastic.

Other alternatives you guys suggest would be also very welcome.

Thanks in advance,

Dror

[Former Member]

>

> One possibility is to use LOCK: according to SM50 one of the work process reasons for waiting is called 'LOCK' and its documentation is "Work process assigned exclusivel to one user for system analysis".
> I figured it might be useful to use this LOCK status but I don't know how it is done, probably some kernel call - if anyone knows 

The status is not 'lock', it's 'hold' with the reason 'lock'. You can accomplish the same effect, if you force the process into debug-mode. Have a look at the taskhandler functions. There might be something you can use. SE37, TH_*.

[HermannGahm]

Hi Dror,

yes, there is a possibilty to lock a workprocess but one normally don't need this option.

Why do you want your program to stick to one workprocess only?

The dispatcher will assign the program (user context) to the same

workprocess once it is rolled in again after the roll out whenever this is possible.

In high load situations this might not be possible and the user context might be assigned

to a different workprocess or even might have to wait until a workprocess becomes free.

But then we are in performance trouble any way... the whole system. Such situations should

be fixed by other means.

So:

Normally your program should use the same workprocess between the steps. In high load

situations it might use a different one. In overload situations it might have to wait.

The overlaod has to be fixed by other means.

So why do wou want to lock a workprocess exclusively to your program? What is the

reason? This should not be necessary....

Kind regards,

Hermann

[Former Member]

Hi Hermann,

Thank you for your help.

The reason I want my program to stick to the same work process is that I need to inspect some of the developer traces for the program execution. I want my program to activate the trace, carry out its logic, deactivate the trace and then to analyze it. Since the traces are at work process level, this requires that a) my program runs on the same process and b) no other program uses this process.

In any case this program is intended to run only in QA environments and never in production.

I hope this clarifies why I want to lock the work process.

Could you elaborate on how this can be done?

Thanks for your kind help.

Dror

[HermannGahm]

Hi Dror,

hm, as I sad, if your QA is not overloaded your program should stay on the same workprocess, however:

In order to make the program run exclusively on a workprocess you have to do the following manual steps:

- in SE38, start pogram RSTRC000

- mark "Keep Work porcess with "X"

- click "save"

- confirm "Work process <nn> locked"

- start your program in the same mode:

-- /nse38 - your program execute

--/nyourta - for your transaction

--/o... will not work (opens a new mode)

- if your program is finished go to se38 agan in the same mode (/nse38)

- start RSTRC000 again

- remove the "X" and click "save"

While the process is locked you can see status LOCKED in SM50 (you can doublecheck from

a second mode /osm50 once you clicked save in RSTRC000.

While locked the workprocess is bound to your user mode (not only the program as you can see above but to your mode where you locked the process), therefore, don't do this in a productive system... .

But i guess with or without this procedure the result should be the same since your progream should use only one

workprocess anyway.

Kind regards,

Hermann

[Former Member]

Hi Hermann,

This seems to work perfectly! Many thanks for your prompt assistance.

Best Regards,

Dror