Original from  Mike Bilow  to Phil Crown on 04-07-1996
Original Subject: Timing out a REXX program

                         ---------------------------------------

 
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.

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

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

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


   Denis       

 Certified OS/2 Engineer, Certified OS/2 Instructor, Certifiable....
 All opinions are my very own, IBM has no claim upon them
 
.
--- Maximus/2 3.01