Original from  Mike Bilow  to Denis Tonn on 04-10-1996
Original Subject: Timing out a REXX progra

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

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

 The only ones I know that are multithreaded are VXREXX and VisiPro 
REXX. Either of these would do, but they are a LOT of overkill for 
just this single function. 

MB> This leaves two questions.  First, why can't I kill the 
MB> process from inside, specifically by having the second 
MB> thread on the Rexx-callable DLL call DosKillProcess()?  

 DosKillProcess will drive the exception handler code on the first 
thread of the process. I believe CMD.EXE has an exception handler that
kills all the "subcommand enviroments" running and returns to a 
command line at that point. 
 What you really want to do is to drive the REXX halt code inside the 
REXX procedure itself. If you use REXXSetHalt from your DLL, this will
do it. Even more interesting is that you can select the process and 
thread as the target. This means you can "kill" just the rexx code for
a different process.. After the halt processing in the rexx routine, 
it will just return to the parent. 

MB> Second, is there some way to kill just the Rexx program 
MB> wihout killing CMD.EXE, so that the "CMD.EXE /C" approach 

 See above.. REXXSetHalt is what you need. 

  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.
 
MB> This makes good sense, and is a nice idea.  The question 
MB> is, how does my timer thread initiate the "halt" signal?  

 rc=REXXSetHalt(processid,threadid)

MB> Also, can the Rexx program receive a halt signal when its 
MB> own thread of execution is in a separate Rexx-callable DLL 
MB> that I don't control, which is the most likely case for my 
MB> timeout to trigger?

 Hmm.. I suspect that as long as the thread is blocked *in* the other 
DLL code, that the halt will not be driven. But in most cases these 
kinds of DLL functions will have a timeout that will eventually return
to the subcommand enviroment (REXX.DLL code). Then the halt would be 
driven. On the other hand, REXX registers some exception handlers of 
it's own, and these may be what it uses to detect and drive a halt 
condition. It would take a debugging session to be sure. 


 Most of this stuff is in the OS/2 toolkit in an INF called 
REXXAPI2.INF. I'll admit it is not well organized, but it is there. 



   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