dialog work processes keep on running even after their maximum runtime specified by the parameter rdisp/max_wprun_time has expired

Let us first understand what does parameter rdisp/max_wprun_time does:

The parameter rdisp/max_wprun_time sets a flag in shared memory, which is checked regularly by the ABAP/4 interpreter. When the time in seconds defined by the value of the rdisp/max_wprun_time parameter is exceeded, all dialog transactions are terminated when the next ABAP/4 command is submitted.

It means, if the current command is waiting for something, it will keep on doing so and will not terminate. For example, When a ABAP/4 command is waiting for a very long SQL request to finish, next command will not be issued and hence work process will keep on going.

Also, in following cases, the dialog work process can continue to run:

·        Every program that calls up a "COMMIT WORK." at regular intervals resets its clock to 0 and can have longer run times than defined by the parameter rdisp/max_wprun_time.

·       You cannot check the runtime for a transaction that is waiting at a database lock or semaphore. You can use transaction SM50 to observe this behavior by choosing "CPU" to display the CPU time. The CPU time does not increase in this case because the work process is actively waiting.

·    When you function module TH_REDISPATCH, the clock is reset, but a COMMIT is forced. The function module only resets the clock if the process is somewhere near the runtime limit.


I have seen work processes running more than "rdisp/max_wprun_time" 
only if work process was started to use heap memory ( dialog process was switched to PRIV). 

I observed when the work process is started using Heap memory, it does not care about the parameter rdisp/max_wprun_time.