Denis Tonn wrote in a message to Mike Bilow:

MB> Again, if you issue a DosKillProcess() against the Rexx 
MB> program, you actually kill CMD.EXE.  If there is a parent 
MB> batch which calls the Rexx program, then this kills the 
MB> parent batch also.  I suppose I can get around this by 
MB> running a second copy of CMD.EXE or something, but this is 
MB> not the key problem.
MB> 
MB> What I am thinking about implementing with the DLL is a 
MB> Rexx function such as RxtSetTimeout(), which would return 
MB> immediately.  This would start some sort of asynchronous 
MB> timer that, upon expiration, would cause the Rexx program 
MB> to be killed.  The Rexx program could make periodic 
MB> checkpoint calls into the DLL to notify the timeout routine 
MB> that everything was fine, and this would reset the timeout 
MB> timer.  If, however, the DLL did not hear from the Rexx 
MB> program periodically, the DLL would assume that the Rexx 
MB> program was hung and kill it.

 DT>  What you are describing would actually require another
 DT> thread of execution (the "watching/waiting" thread). The
 DT> default REXX library  does not support multiple thread
 DT> creation. There are extensions that  support multiple
 DT> threads (and the "timer" capability).. 

I don't see any reason why a Rexx-callable DLL could not be multithreaded,
especially since there will be only two threads and the second one will
never interact directly with the Rexx program.  If you know of any
extensions which already do this, please tell about them.  I plan to write
the DLL.

 DT>  It looks like the only way to currently do what you want
 DT> (without VX  or Visi REXX) is to use the CALL CMD.EXE /C
 DT> command as you have suggested, and kill the secondary
 DT> process from outside. 

This leaves two questions.  First, why can't I kill the process from
inside, specifically by having the second thread on the Rexx-callable DLL
call DosKillProcess()?  Second, is there some way to kill just the Rexx
program wihout killing CMD.EXE, so that the "CMD.EXE /C" approach
is not needed to run the Rexx program in the first place.  Remember that I
don't care about gracefulness; this is intended to implement a fail-safe.

 DT>  But if you are going to go through the effort of writing
 DT> this DLL,  you might look into the SIGNAL ON HALT XXXX
 DT> mechanism as a way to  transfer control to "user code" at a
 DT> specific point. This point is hit if you use CTL-BREAK and
 DT> you have a set a subroutine to gain control on a the halt.

This makes good sense, and is a nice idea.  The question is, how does my
timer thread initiate the "halt" signal?  Also, can the Rexx
program receive a halt signal when its own thread of execution is in a
separate Rexx-callable DLL that I don't control, which is the most likely
case for my timeout to trigger?
 
-- Mike


---