$REPLY/URGENT messaging

[Ranger1]

Over this past weekend we had an issue with a DCL procedure which ran amok.  Within the procedure

is this line:  $repl/bell/urgent/user "blah blah blah".

Due to an unforseen issue this repl message was broadcast 60,000+ times!

The message is coming from the sys$batch of a 4 node OpenVMS cluster.

Two nodes have a one system disk and the other two nodes have their own system disk.

The repl messaging finished on the broadcasting nodes quite some time ago but the

messaging continues on the remaining two nodes of the cluster.

Which is causing the user community some consternation/confusion.

A temporary workaround was to add $set broadcast=nourgent to sylogin.com

What I would like to do is find the buffer (network?) where the remaining messages are coming from.

Is this possible and, if so, where would I look?

Thanks in advance.

[John Gillings · Accepted solution]

I don't think there's a supported way to clear pending OPCOM messages.

Presumably the noise has died down by now, but if you have a repeat, I'd guess you can clear the buffer by stopping and restarting OPCOM. The process should be killable with STOP/ID. You can then restart it by executing SYS$STARTUP:VMS$CONFIG-050_OPCOM from SYSTEM

[Ranger1]

thanks John.  The messages have cleared so no need to kill OPCOM.  (Duh.  Why didn't I think of that?!!!)

What is odd, though, is that none of the messaging is going to operator.log  I would have thought any

$repl/to= would go there but these 60,000 spurious messages are not. 

Regardless, the messages have finally given up the ghost.

[Volker Halle]

This REPLY command issues a BRAODCAST using the $BRKTHRU system service. OPCOM is NOT involved in this operation.

A cluster-wide broadcast is being handled by the CLUSTER_SERVER process on the other nodes in the cluster.

So stopping OPCOM would not have achieved anthing.

Volker.