Nelson,

The command being monitored and returning a response is PHANTOM and not the command that PHANTOM happens to run shich is one step at least removed from the EXECUTE.

I recommend either using a control record which is deleted before the PHANTOM command and then recreated by the program or alternatively making use of the BASIC 'LOCK' statement to set a  process lock which the launching program can then loop on wth a SLEEP for a set number of iterations to check on the program;s successful launch.

Regards

JJ

Hi Nelson, 

You could execute the LISTUSER command with the PID option. It would return information on the process if it was active or not return anything if the PID wasn't active. You have to parse the output and either check for the PID or that Searched lines returned was not 0.

>PHANTOM SLEEP 300
Phantom process started with process ID 22478880.
>LISTUSER PID 22478880
UsrNo Pid...... UID.. UserName Type Acct.............. LogonTime...............
   -1  22478880     0 root     Phan /disk1/morrisn     Sat Feb 18 08:09:12 2023

Search lines returned: 1 (of 2)
>LISTUSER PID 22478889
UsrNo Pid...... UID.. UserName Type Acct.............. LogonTime...............

Search lines returned: 0 (of 2)

Neil

JJ,

The idea of a log record written that lets you know the launch occurred works well.

A variant I have used is a set of programs that work on the premise that each program works with a "well known" status record ID. When it runs the program establishes a READU on its record. The advantage is that should the program abort, UniVerse will clean up its record lock. The presence of the lock confirms the program is still running. 

The status record can contain internal and external (avoiding conversions on a client) values for last status time and date, next expected time and date (due time), and long and short versions of a message field. Each time it wakes, it updates the values in the record. The client can be one of the UO interfaces, or another BASIC program. You can monitor the last updated time, highlight in yellow if the program is late (due time is in the past), and highlight in red if the record READU lock is absent, meaning it crashed. The monitor can issue an alert by email, SMS, or other.

If the program awaits an input, such as reading from a socket, it is difficult to know when it it can report. However, if a program SLEEP/NAP for 60 seconds, it can update the status record during its awake interval.

One way to handle the timing of a blocked read on a socket uses an additional program to write a "wake" message at an interval, just short of the next wakeup time. When the wake program times out and awakens, it can check to see if the next wake time in the status record has changed, and adjust its next sleep interval appropriately for  minimizing workload.

Mark,

A good call - though I would caution about breaking an application in a socket read as under heavy load it is possible to burn the available TCP ports if not properly closed and destroyed  (though not a likely scenario I have seen it happen to no good result)..

From my perspective socket interfaces are worth every penny invested for IPC purposes - love them. I learnt the hard way as the easier answer using message queues does not scale and underperforms sockets by a huge margin.

Regards

JJ