Unable to kill a session in SM50 or SM66

[Former Member]

One of our developer was working on a program and there was a network failure. When we got the network back the system shows the process is till running since 3 days. Tried to kill it from SM50 and SM66.

While logging in it is giving 3 options and even after selecting "Continue with this logon and end any other logons in system" its not ending that session.

After we logon the program is running good.

How to kill this session??

Details of the session is given below

No Ty. PID Status Reasn Start Err Sem CPU Time Cl. User

3 DIA 6584 Running No 296:36 168191 130 BYARLAGADDA

Report / Spool action

CL_ABAP_TABLEDESCR============CP

Main Program

SAPLCV110

Action Table

Waiting f. since

Database Number Time (usec) Recs.

Direct Read 14,681 519,103 524

Sequential Read 18,146 595171 83

Insert 0 0 0

Update 0 0 0

Delete 0 0 0

[Former Member · Accepted solution]

Check the process in OS level and kill it from there

Thanks

Prince Jose

[Former Member · Accepted solution]

Process id shows as 6584, but how to do this from OS level? How to find it out at OS level?

[Former Member · Accepted solution]

Whats your OS ? In Unix

kill -9 <process id >

In windows you can do this from Task manager

Thanks

Prince

Edited by: Prince Jose on Mar 20, 2008 9:12 AM

[Former Member · Accepted solution]

Its windows and DB is MS SQL.

[Former Member · Accepted solution]

Thanks Buddy,

It helped in solving my problem.

[Former Member · Accepted solution]

Why does no-one understand SAP Architecture well enough anymore, I blame bad trainers.

Its like seeing a car driving badly all over the road and blowing up the car rather than shooting the driver.

The WP is not the problem, it is the task in the WP that is.

Killing a user in SM04 or a job in SM37 often works. Then I would try cancelling the program in SM50, not the work process.

If that fails then normally it is waiting on something - often RFC. If RFC a simple removal of the connection in SMGW removes the task from the WP. In this case it looks like a rogue DB process, in this case the WP is just waiting for a response from the DB... killing the WP just gets rid of the visibility in SM50, it does not remove the problem... in fact it then would make my job of identifying why the system is running slow a lot worse.