Operating System - OpenVMS

Re: $REPLY/URGENT messaging

Go to solution
Occasional Contributor

$REPLY/URGENT messaging

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
Honored Contributor

Re: $REPLY/URGENT messaging

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



A crucible of informative mistakes
Occasional Contributor

Re: $REPLY/URGENT messaging

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
Honored Contributor

Re: $REPLY/URGENT messaging

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.