Help with "WATCHER"

[Jack Trachtman]

I just downloaded and installed WATCHER from the Process SW web site. Since they don't provide support, I'm hoping someone here can answer a question about it.

The program is an Idle Terminal Monitor which deletes idle processes. I want to use it not to delete processes but instead to run my script when an idle process is found.

I can do this now by disabling all of the "kill" functions and naming my DCL script WATCHER_LOGOUT.COM in the WATCHER directory.

So far so good - but WATCHER still displays a msg on the users terminal that it is about the log them out. My script will not log them out.

I tried SEARCHing through all of the files for the msg text, but found nothing.

Any ideas as to how to suppress the %WATCHER-I-LOGOUT msg? TIA

[Craig A Berry]

Does

SET WATCH_DEFAULT/NOWARNING

in the configuration file do you any good?

You can also experiment with SET NOACTION and see if it will still execute a script even when not doing any logouts our disconnects.

[John Gillings · Accepted solution]

Jack,

The messages are defined in WATCHER_MSG.MSG. They're written to the user's terminal by routine BREAKTHROUGH in module FORCE.B32. It doesn't look like there's any logic to block the message, apart from SET NOACTION (but that appears to block everything else too!)

If you have a BLISS compiler, just comment out the calls to BREAKTHROUGH (there are only two) and recompile.

[John Gillings]

Jack,

Just a thought, since you're not deleting the process, make sure you test carefully! It's entirely possible that WATCHER has an implicit assumption that the process will be deleted. Once a process is identified as "idle" and is supposed to have been killed, what happens if it remains idle into the future? Will your WATCHER_LOGOUT process be called repeatedly?

Also beware of this type of program. I haven't checked the logic, but I've seen this type of utility bring a system to its knees by "chasing" a swapped out process through the process list when the system is over BALSETCNT. Checking the process inswaps it, which forces the next process to be outswapped, repeat for every process on the system :-( Can you spell "thrashing"? Adding logic to eliminate this undesirable behaviour by avoiding touching an outswapped process in a manner than will swap it in means that an outswapped process will never be considered idle. What is wrong with this picture?

(of course it could be argued that anyone who is over BALSETCNT deserves whatever they get?)

[Jack Trachtman]

A little background - we want to see if WATCHER can help us with the old problem of finding users who unknowingly lock a data record and then leave their terminal, so others can't update that record.

Craig:

- /NOWARNING suppresses the Warning msg, but not the LOGOUT msg

- SET NOACTION does just that: no msgs go out, but my script doesn't get called either


John:

Thanks for the comments

- I don't know from Bliss, but I'll download the compiler from the Freeware compilation and give it a try

- I've discovered that if an idle process is not actually killed, WATCHER will start tracking it again & try to kill it again after it ages out. I can live with this.

- re "chasing" a swapped out process: WATCHER has an option called NO INSWAP, so it leaves alone (i.e. does not track) any outswapped processes

[The Brit]

Just a thought, have you tried turning off messaging in your/their script? i.e.

$ set message/NoID/NoFacility/NoText/NoSeverity

does it have any effect??

Dave.

[Hein van den Heuvel]

>> A little background - we want to see if WATCHER can help us with the old problem of finding users who unknowingly lock a data record and then leave their terminal, so others can't update that record.


Ah, that could be a reasonable reason to run an idle process checker. Mostly I just see those as a nuisance and resource hogs.

It does beg two questions:

1) Should you not review and fix an application which holds record locks over arbitrary long periods?

2) Consider going after the culprit itself!
Write a program with $GETLKI to look for rms record locks (exec mode, 8-byte name, parent lock name starts with RMS$) and remembers those. Look again after a while and see if the same pid still holds that lock.
Three strikes and your out (or at least on a suspect list).
You'll probably need some exception list.

I have a tool on the OpenVMS freeware that does 80% of the hard work for such tool:
http://h71000.www7.hp.com/freeware/freeware60/rms_tools/src/blocking.c
Feel free to use that as a starting point.
And for mere money I'll be happy to adapt it for the requested purpose.

Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

[Jack Trachtman]

Mr Brit - WATCHER is an .exe that uses system calls to force the msg to a terminal, so unfortunately I can't suppress the msgs as you suggested


Hein - in short, "Third Party Product" - can't get to the code!

Thanks for the responses