topic Re: $REPLY/URGENT messaging in Operating System - OpenVMS

$REPLY/URGENT messaging

Ranger1 — Mon, 06 Aug 2012 14:19:31 GMT

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.

Re: $REPLY/URGENT messaging

John Gillings — Mon, 06 Aug 2012 21:26:19 GMT

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

Re: $REPLY/URGENT messaging

Ranger1 — Tue, 07 Aug 2012 14:00:19 GMT

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.

Re: $REPLY/URGENT messaging

Volker Halle — Wed, 08 Aug 2012 07:25:25 GMT

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.