Mike Tripp wrote in a message to Mike Bilow:

 MB> Again, if you issue a DosKillProcess() against the Rexx program, you
 MB> actually kill CMD.EXE.  If there is a parent batch which calls the
 MB> Rexx program, then this kills the parent batch also.  I suppose I can
 MB> get around this by running a second copy of CMD.EXE or something, but
 MB> this is not the key problem.

 MT> "START CHILD" will get you your second copy, but killing
 MT> CHILD.CMD's PID will get you a CMD.EXE with the same PID,
 MT> requiring an additional kill.  "START /C" will give you a
 MT> secondary CMD.EXE that dies accordingly when CHILD.CMD's PID
 MT> is killed.  At least that's what's been required here when
 MT> using PROCMAN (PM interactive) and KILLPID (commandline
 MT> batch).

No, I can handle that part of it.  The question is whether the monitor runs
above the Rexx program, in which case we have only very coarse timeout for
the whole program, or below the Rexx program as a DLL, in which case we can
have the Rexx program meet periodic checkpoints to assure the monitor that
it is still running and healthy.  I obviously prefer the DLL below the Rexx
program.

Now, from inside a DLL called by Rexx, how does the DLL kill the Rexx
program? Remember that the DLL will be multithreaded, so that the monitor
runs as a separate thread.  The Rexx program starts the monitor by calling
into the DLL, and the DLL will then spawn the monitor thread and return
immediately.  I want to have the monitor thread be able to kill the Rexx
program, but not the parent CMD.EXE.  It may require starting the Rexx
program itself with "CMD /C" or something like that, but this is
a minor restriction.  It seems to me that the DLL monitor thread will have
to call DosKillProcess() against a PID, but against exactly which PID?

 MT> If you'd rather write a DLL, you might be interested in a
 MT> peek this DLL distributed in FWREXX as RXSET211.*:

I'm familiar with how to write a Rexx-callable DLL.  I have never actually
written one that is internally multithreaded, but that does not seem
difficult.  Where I get worried is in how to kill the Rexx program from the
second thread in the DLL.

 MT> As for the timer idea, it seems you'd be more interested in
 MT> whether or not any FTP-type activity is actually going on,
 MT> rather than whether or not x amount of real time has passed.
 MT>  The way the bandwidth over the Internet varies, it would
 MT> seem that your timeout could be exceeded even while
 MT> meaningful work is still being accomplished by the FTP API
 MT> code, even though it isn't hung.  You may want to explore
 MT> the Rexx Sockets API to see if you can monitor the FTP
 MT> socket for some meaningful sign of healthy activity.

There may be a way to monitor a socket owned by another process using
either the C API or RXSOCK, but I don't see much future in that.  In any
case, it is not part of the requirements of what I want to do.  I am
talking about imposing time limits on the order of an hour, as a last ditch
effort to keep the system from hanging.  If a file can't arrive in that
time interval, than I don't really care what happens to it, and I'll settle
for ungraceful abort.

If I can use a DLL and scatter checkpoint calls throughout the Rexx code,
then the timeout would only trigger if the Rexx program was totally dead,
usually because it has made a call into FtpGet() or something that is never
going to return.  As I said originally, I would prefer to have the timeout
capability added directly into RXFTP, but I don't have the source for it
and I don't see much hope of ever getting the source for it.  Besides, a
general purpose timeout monitor for Rexx would be a useful DLL to have.
 
-- Mike


---