David,

This issue came up at a client site recently. What I suggested is that I make an EG add-in (think a button with a skull on it) that would call a web service on the server and that service could kill the processes. The server would be protected and the server admins could write the scripts necessary to kill processes. I think it is feasible to go this route.

On Windows Server, use the sysinternals library to do the same thing as a kill does on Unix. Regardless, the process can be automated IMO. Care would need to be taken that the correct process is identified, that only the intended application could call the service, etc.

Alan

Alan Churchill Savian "Bridging SAS and Microsoft Technologies" www.savian.net

-----Original Message----- From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of David Sent: Wednesday, July 11, 2007 9:06 PM To: SAS-L@LISTSERV.UGA.EDU Subject: Jobs that won't die

You know the drill - kill the desktop SAS session, then really kill it from the task list, then log on to Unix, find the offending process and kill -9 it, then phone the Oracle DBA and get them to terminate the database process...

I'm using three out-of-band processes (the task manager, telnet and the good old fashioned telephone to kill the respective processes. Why can't someone invent an out of band process that goes directly from SAS or EG to the server? (This isn't the eighties, out PC's can multi-task!) How hard would it be for the client to send a kill signal to the server?

And why on earth does the Unix SAS Server process not respond promptly/ properly to SIGTERM? Why do we have to resort to kill -9?

And forget trying to kill anything on an NT server (just pray that some zombie process doesn't keep a lock on critical files). Why can't SAS play nicely and clean up after itself?

It's enough to make me want to give up and go home for the day.