Find & Kill A Process 
Author Message
 Find & Kill A Process

Win2K - Object Rexx 2.1.2

Short Version:
Need to determine if Excel is running on a system and "kill" it if it
is.

Long Version:
Have a "schedule" program that calls external Rexx scripts and handles
all known error conditions.
If one of the external scripts uses Excel (which is quite common) and
it has some "other" error, the calling script (schedule) will trap the
error and gracefully exit the routine and log the needed information.
However, a copy of Excel is left running.  In our case there would
never be any other copy of Excel running.  What would be great is a
function in the error handling of the schedule program that could
determine if Excel is running and "kill" it.

I was hoping the .OleObject~GetObject("Excel.Application") would
determine if Excel was already open, but that isn't what this does.

Of course, a .local variable could be set to the name of the Excel
object, but I'm hoping to find something better.

A routing to enumerate all processes via Rexx would be nice (hint).

Any Thoughts?

Lee Peedin
VP RexxLA www.rexxla.org
Start planning now for the 25th Anniversary of Rexx Symposium,
Spring 2004 in Boeblingen, Germany.



Tue, 08 Nov 2005 03:00:24 GMT  
 Find & Kill A Process
Lee:

Quote:
> A routing to enumerate all processes via Rexx would be nice (hint).

> Any Thoughts?

How about using WMI (see Object Rexx examples and also Florian Helmecke's work)?

Hope that helps,

---rony



Tue, 08 Nov 2005 05:35:32 GMT  
 Find & Kill A Process
Thanks Rony,
Very soon after making the original post, I remember the 1287 page
book (borrowed from David) titled "Windows 2000 Scripting Guide".  Had
to leave the office a bit early so I brought it home.  After about 5
minutes of reading and a bit of trial & error I have the following
code: (watch for line wraps).

WMIObject =
.OLEObject~GetObject("winmgmts:{impersonationLevel=impersonate}")

Excel_List = WMIObject~ExecQuery("SELECT * FROM Win32_Process WHERE
Name = 'excel.exe'")
do Excel_Process over Excel_List
    Excel_Process~Terminate()
end

It will find and kill 15 copies of Excel faster than you can blink
your eyes.  

See you in Germany

On Thu, 22 May 2003 23:35:32 +0200, rony

Quote:

>Lee:

>> A routing to enumerate all processes via Rexx would be nice (hint).

>> Any Thoughts?

>How about using WMI (see Object Rexx examples and also Florian Helmecke's work)?

>Hope that helps,

>---rony



Tue, 08 Nov 2005 07:25:12 GMT  
 Find & Kill A Process
To prevent the leak in the first place, enhance your error hander so that it
sets the Excel.Application's DisplayAlerts property to False, and then calls
the Excel.Application's Quit method. Setting the DisplayAlerts property to
false will suppress the "you haven't saved the workbook X" prompts. If you
wish to save the workbooks despite the error, loop over the
Excel.Application's WorkBooks collections, calling the Save method on each
WorkBook in that collection before calling the Quit method.

(You've already posted the answer to your "how do I enumerate processes"
question)


Quote:
> Win2K - Object Rexx 2.1.2

> Short Version:
> Need to determine if Excel is running on a system and "kill" it if it
> is.

> Long Version:
> Have a "schedule" program that calls external Rexx scripts and handles
> all known error conditions.
> If one of the external scripts uses Excel (which is quite common) and
> it has some "other" error, the calling script (schedule) will trap the
> error and gracefully exit the routine and log the needed information.
> However, a copy of Excel is left running.  In our case there would
> never be any other copy of Excel running.  What would be great is a
> function in the error handling of the schedule program that could
> determine if Excel is running and "kill" it.

> I was hoping the .OleObject~GetObject("Excel.Application") would
> determine if Excel was already open, but that isn't what this does.

> Of course, a .local variable could be set to the name of the Excel
> object, but I'm hoping to find something better.

> A routing to enumerate all processes via Rexx would be nice (hint).

> Any Thoughts?

> Lee Peedin
> VP RexxLA www.rexxla.org
> Start planning now for the 25th Anniversary of Rexx Symposium,
> Spring 2004 in Boeblingen, Germany.



Tue, 08 Nov 2005 15:22:28 GMT  
 Find & Kill A Process
Thanks Mark,
Actually what has been developed is a "template" for all external Rexx
scripts that will be called by our schedule program.  The template was
designed to ensure that all 6 of our Rexx programmers used the same
format when developing scripts to be scheduled.  In fact our schedule
program verifiys the CRC of the first 62 lines and the last 12 lines
of any program it attempts to execute.  If the CRC fails, the schedule
program will report that the template has been changed and refuse to
call the script.
Not all "called" scripts create an Excel object AND those that do may
have a different variable name for the object (My_Excel, MyXL, etc.)
so unless a .local variable was set to the name of the object, it
would not be possible to pass the Quit method to an unknown object
name.  All applications that use Excel have the DisplayAlerts property
set to .False already.
The routine I posted last night using WMI appears to work fine - will
perform some more tests today to be sure.
Lee

On Fri, 23 May 2003 09:22:28 +0200, "Mark Yudkin"

Quote:

>To prevent the leak in the first place, enhance your error hander so that it
>sets the Excel.Application's DisplayAlerts property to False, and then calls
>the Excel.Application's Quit method. Setting the DisplayAlerts property to
>false will suppress the "you haven't saved the workbook X" prompts. If you
>wish to save the workbooks despite the error, loop over the
>Excel.Application's WorkBooks collections, calling the Save method on each
>WorkBook in that collection before calling the Quit method.

>(You've already posted the answer to your "how do I enumerate processes"
>question)



>> Win2K - Object Rexx 2.1.2

>> Short Version:
>> Need to determine if Excel is running on a system and "kill" it if it
>> is.

>> Long Version:
>> Have a "schedule" program that calls external Rexx scripts and handles
>> all known error conditions.
>> If one of the external scripts uses Excel (which is quite common) and
>> it has some "other" error, the calling script (schedule) will trap the
>> error and gracefully exit the routine and log the needed information.
>> However, a copy of Excel is left running.  In our case there would
>> never be any other copy of Excel running.  What would be great is a
>> function in the error handling of the schedule program that could
>> determine if Excel is running and "kill" it.

>> I was hoping the .OleObject~GetObject("Excel.Application") would
>> determine if Excel was already open, but that isn't what this does.

>> Of course, a .local variable could be set to the name of the Excel
>> object, but I'm hoping to find something better.

>> A routing to enumerate all processes via Rexx would be nice (hint).

>> Any Thoughts?

>> Lee Peedin
>> VP RexxLA www.rexxla.org
>> Start planning now for the 25th Anniversary of Rexx Symposium,
>> Spring 2004 in Boeblingen, Germany.

Lee Peedin
VP RexxLA www.rexxla.org
Start planning now for the 25th Anniversary of Rexx Symposium,
Spring 2004 in Boeblingen, Germany.


Tue, 08 Nov 2005 19:59:50 GMT  
 Find & Kill A Process
The problem with your routine in the real world is that it will kill any and
all Excel.exe instances, not necessarily the one leaked by your REXX script.
If you're running multiple Excel instances on a system (e.g. multiple users,
multi-tasking user, terminal services, batch), this may be considered
somewhat antisocial.

Hence my post recommending not leaking the handles in the first place. I
think you should enhance your template with a means of permitting the
template user (your 6 REXX coders) to stash away the Application handle of
any Excel it creates.


Quote:
> Thanks Mark,
> Actually what has been developed is a "template" for all external Rexx
> scripts that will be called by our schedule program.  The template was
> designed to ensure that all 6 of our Rexx programmers used the same
> format when developing scripts to be scheduled.  In fact our schedule
> program verifiys the CRC of the first 62 lines and the last 12 lines
> of any program it attempts to execute.  If the CRC fails, the schedule
> program will report that the template has been changed and refuse to
> call the script.
> Not all "called" scripts create an Excel object AND those that do may
> have a different variable name for the object (My_Excel, MyXL, etc.)
> so unless a .local variable was set to the name of the object, it
> would not be possible to pass the Quit method to an unknown object
> name.  All applications that use Excel have the DisplayAlerts property
> set to .False already.
> The routine I posted last night using WMI appears to work fine - will
> perform some more tests today to be sure.
> Lee

> On Fri, 23 May 2003 09:22:28 +0200, "Mark Yudkin"

> >To prevent the leak in the first place, enhance your error hander so that
it
> >sets the Excel.Application's DisplayAlerts property to False, and then
calls
> >the Excel.Application's Quit method. Setting the DisplayAlerts property
to
> >false will suppress the "you haven't saved the workbook X" prompts. If
you
> >wish to save the workbooks despite the error, loop over the
> >Excel.Application's WorkBooks collections, calling the Save method on
each
> >WorkBook in that collection before calling the Quit method.

> >(You've already posted the answer to your "how do I enumerate processes"
> >question)



> >> Win2K - Object Rexx 2.1.2

> >> Short Version:
> >> Need to determine if Excel is running on a system and "kill" it if it
> >> is.

> >> Long Version:
> >> Have a "schedule" program that calls external Rexx scripts and handles
> >> all known error conditions.
> >> If one of the external scripts uses Excel (which is quite common) and
> >> it has some "other" error, the calling script (schedule) will trap the
> >> error and gracefully exit the routine and log the needed information.
> >> However, a copy of Excel is left running.  In our case there would
> >> never be any other copy of Excel running.  What would be great is a
> >> function in the error handling of the schedule program that could
> >> determine if Excel is running and "kill" it.

> >> I was hoping the .OleObject~GetObject("Excel.Application") would
> >> determine if Excel was already open, but that isn't what this does.

> >> Of course, a .local variable could be set to the name of the Excel
> >> object, but I'm hoping to find something better.

> >> A routing to enumerate all processes via Rexx would be nice (hint).

> >> Any Thoughts?

> >> Lee Peedin
> >> VP RexxLA www.rexxla.org
> >> Start planning now for the 25th Anniversary of Rexx Symposium,
> >> Spring 2004 in Boeblingen, Germany.

> Lee Peedin
> VP RexxLA www.rexxla.org
> Start planning now for the 25th Anniversary of Rexx Symposium,
> Spring 2004 in Boeblingen, Germany.



Thu, 10 Nov 2005 16:35:25 GMT  
 Find & Kill A Process
Good point.  At this time there is only the possibility of one
instance of Excel to be running on the "schedule" system.  Have
considered either a .local variable name of the Excel object or
storing it in the registry, or possibly pulling out the "old" ini
style files and storing it there.

On Sun, 25 May 2003 10:35:25 +0200, "Mark Yudkin"

Quote:

>The problem with your routine in the real world is that it will kill any and
>all Excel.exe instances, not necessarily the one leaked by your REXX script.
>If you're running multiple Excel instances on a system (e.g. multiple users,
>multi-tasking user, terminal services, batch), this may be considered
>somewhat antisocial.

>Hence my post recommending not leaking the handles in the first place. I
>think you should enhance your template with a means of permitting the
>template user (your 6 REXX coders) to stash away the Application handle of
>any Excel it creates.



>> Thanks Mark,
>> Actually what has been developed is a "template" for all external Rexx
>> scripts that will be called by our schedule program.  The template was
>> designed to ensure that all 6 of our Rexx programmers used the same
>> format when developing scripts to be scheduled.  In fact our schedule
>> program verifiys the CRC of the first 62 lines and the last 12 lines
>> of any program it attempts to execute.  If the CRC fails, the schedule
>> program will report that the template has been changed and refuse to
>> call the script.
>> Not all "called" scripts create an Excel object AND those that do may
>> have a different variable name for the object (My_Excel, MyXL, etc.)
>> so unless a .local variable was set to the name of the object, it
>> would not be possible to pass the Quit method to an unknown object
>> name.  All applications that use Excel have the DisplayAlerts property
>> set to .False already.
>> The routine I posted last night using WMI appears to work fine - will
>> perform some more tests today to be sure.
>> Lee

>> On Fri, 23 May 2003 09:22:28 +0200, "Mark Yudkin"

>> >To prevent the leak in the first place, enhance your error hander so that
>it
>> >sets the Excel.Application's DisplayAlerts property to False, and then
>calls
>> >the Excel.Application's Quit method. Setting the DisplayAlerts property
>to
>> >false will suppress the "you haven't saved the workbook X" prompts. If
>you
>> >wish to save the workbooks despite the error, loop over the
>> >Excel.Application's WorkBooks collections, calling the Save method on
>each
>> >WorkBook in that collection before calling the Quit method.

>> >(You've already posted the answer to your "how do I enumerate processes"
>> >question)



>> >> Win2K - Object Rexx 2.1.2

>> >> Short Version:
>> >> Need to determine if Excel is running on a system and "kill" it if it
>> >> is.

>> >> Long Version:
>> >> Have a "schedule" program that calls external Rexx scripts and handles
>> >> all known error conditions.
>> >> If one of the external scripts uses Excel (which is quite common) and
>> >> it has some "other" error, the calling script (schedule) will trap the
>> >> error and gracefully exit the routine and log the needed information.
>> >> However, a copy of Excel is left running.  In our case there would
>> >> never be any other copy of Excel running.  What would be great is a
>> >> function in the error handling of the schedule program that could
>> >> determine if Excel is running and "kill" it.

>> >> I was hoping the .OleObject~GetObject("Excel.Application") would
>> >> determine if Excel was already open, but that isn't what this does.

>> >> Of course, a .local variable could be set to the name of the Excel
>> >> object, but I'm hoping to find something better.

>> >> A routing to enumerate all processes via Rexx would be nice (hint).

>> >> Any Thoughts?

>> >> Lee Peedin
>> >> VP RexxLA www.rexxla.org
>> >> Start planning now for the 25th Anniversary of Rexx Symposium,
>> >> Spring 2004 in Boeblingen, Germany.

>> Lee Peedin
>> VP RexxLA www.rexxla.org
>> Start planning now for the 25th Anniversary of Rexx Symposium,
>> Spring 2004 in Boeblingen, Germany.



Fri, 11 Nov 2005 19:41:27 GMT  
 Find & Kill A Process
Programs have the tendency to end up in environments that the original
author says won't happen. When it does, and the program blows up, everybody
gets frustrated.

The particular issue here is one of my pet annoyances - programmers that do
not realize that Windows (NT +) is a multi-user operating system, which just
happens to be used by many users as if it were a single user system.
Application servers, in particular, are often used as multi-user systems.


Quote:
> Good point.  At this time there is only the possibility of one
> instance of Excel to be running on the "schedule" system.  Have
> considered either a .local variable name of the Excel object or
> storing it in the registry, or possibly pulling out the "old" ini
> style files and storing it there.

> On Sun, 25 May 2003 10:35:25 +0200, "Mark Yudkin"

> >The problem with your routine in the real world is that it will kill any
and
> >all Excel.exe instances, not necessarily the one leaked by your REXX
script.
> >If you're running multiple Excel instances on a system (e.g. multiple
users,
> >multi-tasking user, terminal services, batch), this may be considered
> >somewhat antisocial.

> >Hence my post recommending not leaking the handles in the first place. I
> >think you should enhance your template with a means of permitting the
> >template user (your 6 REXX coders) to stash away the Application handle
of
> >any Excel it creates.



> >> Thanks Mark,
> >> Actually what has been developed is a "template" for all external Rexx
> >> scripts that will be called by our schedule program.  The template was
> >> designed to ensure that all 6 of our Rexx programmers used the same
> >> format when developing scripts to be scheduled.  In fact our schedule
> >> program verifiys the CRC of the first 62 lines and the last 12 lines
> >> of any program it attempts to execute.  If the CRC fails, the schedule
> >> program will report that the template has been changed and refuse to
> >> call the script.
> >> Not all "called" scripts create an Excel object AND those that do may
> >> have a different variable name for the object (My_Excel, MyXL, etc.)
> >> so unless a .local variable was set to the name of the object, it
> >> would not be possible to pass the Quit method to an unknown object
> >> name.  All applications that use Excel have the DisplayAlerts property
> >> set to .False already.
> >> The routine I posted last night using WMI appears to work fine - will
> >> perform some more tests today to be sure.
> >> Lee

> >> On Fri, 23 May 2003 09:22:28 +0200, "Mark Yudkin"

> >> >To prevent the leak in the first place, enhance your error hander so
that
> >it
> >> >sets the Excel.Application's DisplayAlerts property to False, and then
> >calls
> >> >the Excel.Application's Quit method. Setting the DisplayAlerts
property
> >to
> >> >false will suppress the "you haven't saved the workbook X" prompts. If
> >you
> >> >wish to save the workbooks despite the error, loop over the
> >> >Excel.Application's WorkBooks collections, calling the Save method on
> >each
> >> >WorkBook in that collection before calling the Quit method.

> >> >(You've already posted the answer to your "how do I enumerate
processes"
> >> >question)



> >> >> Win2K - Object Rexx 2.1.2

> >> >> Short Version:
> >> >> Need to determine if Excel is running on a system and "kill" it if
it
> >> >> is.

> >> >> Long Version:
> >> >> Have a "schedule" program that calls external Rexx scripts and
handles
> >> >> all known error conditions.
> >> >> If one of the external scripts uses Excel (which is quite common)
and
> >> >> it has some "other" error, the calling script (schedule) will trap
the
> >> >> error and gracefully exit the routine and log the needed
information.
> >> >> However, a copy of Excel is left running.  In our case there would
> >> >> never be any other copy of Excel running.  What would be great is a
> >> >> function in the error handling of the schedule program that could
> >> >> determine if Excel is running and "kill" it.

> >> >> I was hoping the .OleObject~GetObject("Excel.Application") would
> >> >> determine if Excel was already open, but that isn't what this does.

> >> >> Of course, a .local variable could be set to the name of the Excel
> >> >> object, but I'm hoping to find something better.

> >> >> A routing to enumerate all processes via Rexx would be nice (hint).

> >> >> Any Thoughts?

> >> >> Lee Peedin
> >> >> VP RexxLA www.rexxla.org
> >> >> Start planning now for the 25th Anniversary of Rexx Symposium,
> >> >> Spring 2004 in Boeblingen, Germany.

> >> Lee Peedin
> >> VP RexxLA www.rexxla.org
> >> Start planning now for the 25th Anniversary of Rexx Symposium,
> >> Spring 2004 in Boeblingen, Germany.



Sat, 12 Nov 2005 13:51:36 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. Thread#kill doesn't kill processes inside a thread

2. Killing processes without using 'kill'

3. Child process on crashing kills it parent process

4. How can kill all child processes without killing parent process ?

5. Finding PID & killing processes that run for too long

6. Any Improvements to this process killing script?

7. killing processes

8. Kill a Process before Open Files

9. killing a Rexx process in OS/2

10. Help with killing OS2 Process

11. kill a process or application within rexx

12. Process.kill for Win32

 

 
Powered by phpBB® Forum Software