Reducing duplication of messages in OPERATOR.LOG files

[Jeremy Begg]

I have taken over administration of a three-node VMScluster with shared HSG80 storage.  Two of the system roots are on one disk and all three nodes run OPCOM.  Consequently there are three OPERATOR.LOG files and all OPCOM messages are being written to all three files.

I know this is not a new problem, is there a way to tell OPCOM on each node to log only the messages which originate on that node?

I am aware of the OPC$ALLOW_INBOUND and OPC$ALLOW_OUTBOUND logicals but they don't really do what I need.  I want to have OPCOM on each node continue to receive and broadcast OPCOM messages from other nodes, but I don't want messages received from other nodes to be written to the local OPERATOR.LOG file.

I could define OPC$LOGFILE_NAME to point to a file in SYS$COMMON but I suspect the result would either be three such files open at any one time, or I'd see three copies of each message written to that file.

Any suggestions?

BTW the machines are running OpenVMS V7.2-2.  An upgrade to V8.4 is in the works (later this year).

Thanks,

Jeremy Begg

[Hoff]

OPCOM wasn't the best design available back when it was implemented - TOPS arguably had better operator communications support - and OPCOM hasn't changed significantly in the intervening years.

Two (of many) options:

- Roll the archives daily, collect the day's files, and zip them.   Given many sites use those files only reactively, zipping saves a whole lot of space.  This is a typical nightly maintenance job, and is commonplace on Unix and easily implemented on VMS,

- Route the OPCOMs out via a syslog client, and then process the messages on a Unix syslog or syslog-ng server, or some other platform with modern distributed management tools, and then use a nightly job to delete older files off VMS.  This can be combined with zip to save some space, prior to log file deletion.

[John Gillings]

Jeremy,

   It's a "feature"! And it's a good thing.

Redundancy means you're less likely to miss a message. Having all the messages in each file also means they're in chronological sequence, so you get a better picture of what actually happened (rather than having to correlate independent events from multiple files ##).

The amount of disk space used can't be an issue.

To deal with the duplication, simply ignore two of the files, since you know everything is in the other two. Pick one node to be the "primary". If that node is unavailable, or you find something alarming, then check the other two. Make sure you roll over all the files at the same time, and choose an interval which gives you manageable and navigable chunks.

If you're paranoid about missing something interesting, you can easily filter the differences between files with something like this:

$ PIPE DIFF  SYS$SYSDEVICE:[SYS0.SYSMGR]OPERATOR.OLD;742 SYS$SYSDEVICE:[SYS1.SYSMGR]OPERATOR.OLD;656 /PARA | -
  SEARCH/MATCH=NOR SYS$PIPE "%%%%%%%%%%%  OPCOM","--------------", "Logfile time stamp","      |"

## - RTR, on the other hand, DOES have node specific log files, so when something happens, it's difficult to work out the sequence. I have a script which merges multiple log files into a single stream