Interactive Jobs not timing out.

[Former Member]

Hi folks,

I have rdisp/max_wprun_time set to 600 seconds.

However, I keep seeing jobs running for considerably longer than this.

Right now I have a job which has been running for over 1800 seconds.

Two questions:

1. Why, when the timeout is set to 600, do jobs run for longer?
2. Is there anyway to kill this job other than SM50 > Process > Cancel with/without Core?  Because I selected this option over 15 minutes ago and it still hasn't stopped.  And it's killing the system!

Thanks in advance for any suggestions.

[Former Member]

Hello,

Thank you for your replies.

The timeout parameter is definitely set to 600 seconds, and the job was definitely running in SM50.  The job eventually ran for just under 2900 seconds before finally cancelling.

It seems the timeout parameter is pointless. 

Note 25528 states:  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.

On occasion, this isn't happening. 

[Sriram2009]

Hi Paul

Kindly refer the SAP Note 1789729 - Performance problem due to frequent accesses to DD02L

Thanks

Sriram

[ACE-SAP]

Hello

Are you sure that the job is still active, did you see it in SM50 ?

A failing job can be reported as active in SM37 but it is not... and thus can go beyond the time out.

Select your job in SM37 and in the menu select /Job/Check status

You can have a look at these OSS notes

37104 - Error analysis: Background processing system

25528 - Parameter rdisp/max_wprun_time

Best regards

Message was edited by: Yves KERVADEC I did not check the picture, this is not a batch but a dialogue process, Forget about what I've said, and try Sriram's solution... BR

[Former Member]

Please don't be offended, but are you sure your time-out is really set to 600 seconds?  It's a very common thing to be confused, if a parameter is set in both the default and instance profiles.  Which is why I always recommend to avoid doing that.  Some parameters, like the one in question here, can also be switched dynamically.  The easiest way to check the current value is in transaction RZ11.

Even if the parameter is set the way you say, a process can only be interrupted at certain stages.  For instance, a process can't be stopped while it is executing a single database statement, which can take hours to run.  Another reason can be, if the process is waiting for a response to an RFC call.  Since you can't kill the process above in SM50, it seems that the process is in one of those uninterruptable stages.  Have you checked the detail view?

Another thing is, that the processes always get an additional grace period to finish.  It used to be that a defined value of 600 seconds was a defacto timeout of 1200 seconds, but I'm not sure whether that is still the case in newer releases.