topic Re: Redirecting Operator Messages in Operating System - OpenVMS

Redirecting Operator Messages

Ronnie Doggart — Tue, 09 Mar 2004 08:32:07 GMT

Hi,

We have a cluster of two DS15's connected to a KVM port switch and a single integrated screen, keyboard and mouse. Can we connect printers to the DS15's serial ports and redirect opcom messages to the printers to give us a hardcopy log of the messages

Ronnie

Re: Redirecting Operator Messages

Ian Miller. — Tue, 09 Mar 2004 09:06:52 GMT

assuming serial port is called TTA0: then

optional - disallow logins
$ SET TERM/PERM/NOTYPEAHEAD TTA0:

You may need to set serial port speed etc
$ SET TERM/PERM/SPEED=9600

Enable TTA0 as an operator terminal
$ DEFINE/USER SYS$COMMAND TTA0:
$ REPLY/ENABLE

All opcom messages will be output to TTA0.

Re: Redirecting Operator Messages

Ian Miller. — Tue, 09 Mar 2004 09:08:39 GMT

Above assumes you are running VMS on your DS15.

You may also wish to look at the OPC$ logicals defined in SYLOGICALS to disable operator messages to the console.

Re: Redirecting Operator Messages

Uwe Zessin — Tue, 09 Mar 2004 10:07:20 GMT

Well, on a system that has a graphic adapter OPA0: is usually disabled. Watch out: very often the operator log file is disabled, too!

Re: Redirecting Operator Messages

Martin P.J. Zinser — Tue, 09 Mar 2004 12:23:52 GMT

Hi Ronnie,

since this is a cluster, pretty much all the "normal" messages will be duplicated, so you might want to check if you need to print both copies of the operator log. Also you might want to re-check if the print our requirement still is valid. We used to do hard copies of our operator logs for legal reasons too, but are not required to do so anymore.

Greetings, Martin

Re: Redirecting Operator Messages

Jan van den Ende — Wed, 10 Mar 2004 06:26:03 GMT

Ronnie,

like Martin says, DO evaluate the need for the hardcopy output.
The nature of our organisation also specifies the need for logging A LOT (as in 10's of megabytes plain ascii a day).
But then, on hard-copy you never find it again, certainly after some time (we need to be able to produce specific info, or guarantee the lack of it, for up to 3 years!). It is far more usefull to store them electronically (recent on-line, thereafter near-line) and have some search mechanism.
Now only the data that is actually needed for some specific purpose gets printed.
Environmental sidestep: saves many trees as well! ;-)

hth

Jan

Re: Redirecting Operator Messages

Robert Atkinson — Tue, 16 Mar 2004 04:16:58 GMT

Ronnie,
we had a similar requirement to yours, in wanting to capture Console messages.

Our final solution involved RoboCentral from Heroix. As well as capturing everything from the Console ports (including crash info, etc) it is able to match strings of text and generate actions.

We use it to have batch jobs automatically reply to OPCOM requests based on the text!

You can also use it to remotely manage boxes (via TELNET) so that you don't have to be sat in a computer room, but could technically be on the other side of the world.

I'd certainly recommend it as a very good solution.

Robert.

Re: Redirecting Operator Messages

Mobeen_1 — Tue, 16 Mar 2004 04:26:53 GMT

Ronnie,
If your printer is connected on the serial port (tta0), do the following

$ define/user sys$command tta0:
$ reply/enable

In line 1 above you are defining a logical that directs the output to tta0:, while in line 2 above you are issuing a reply/enable command which does enables the opcoms

When u are done and you no longer need to print the OPCOMS onto your printer connected to your serial port, just issue the following commands

$ deassign/user sys$command
$reply/disable

regards
Mobeen

Re: Redirecting Operator Messages

Dale A. Marcy — Tue, 16 Mar 2004 13:53:58 GMT

Mobeen,

Since the /user only defines the logical for the next executable command, I would have expected the following sequence when you were finished:

$ define/user sys$command tta0:
$ reply/disable

Am I missing something?

Re: Redirecting Operator Messages

Mobeen_1 — Wed, 17 Mar 2004 00:11:41 GMT

Dale,
Since the /user logical definition is defined at the user level not /system. I think logging out the session should also do the trick :-)

rgds
Mobeen

Re: Redirecting Operator Messages

Jan van den Ende — Wed, 17 Mar 2004 03:32:04 GMT

Dale, Mobeen:

NO need to do anything with the SYS$COMMAND definition:
the moment your REPLY command is finished, the /USER definition is gone!
And if you want the do another change of the REPLY setting, you again redefine sys$command /user, again ONLY for the duration of the execution of the Reply command.
The EFFECTS of the REPLY enabling/disabling/whatever are in OPCOM, and THAT stays until changed again.

Jan

Re: Redirecting Operator Messages

Dale A. Marcy — Wed, 17 Mar 2004 15:27:56 GMT

Jan,

You said what I was attempting to say, but in a much clearer fashion. The commands I gave were to turn off the output of opcom messages to the printer.

Re: Redirecting Operator Messages

Mobeen_1 — Wed, 17 Mar 2004 22:16:44 GMT

Jan,
Thanks. I was just trying to say that once you enable the OPCOMs (by reply/enable) and incase you are not logging out the user session and no longer want to print the OPCOMS, then you can just issue a reply/disable.

rgds
Mobeen

Re: Redirecting Operator Messages

Uwe Zessin — Thu, 18 Mar 2004 13:41:59 GMT

Mobeen,
I beleive you have confused people (unintentional) by putting the
'DEASSIGN/USER_MODE' in front of the 'REPLY/DISABLE', because:

- the logical name created by 'DEFINE/USER_MODE' before executing 'REPLY/ENABLE' will automatically deleted during image rundown of REPLY, so the later DEASSIGN is not necessary. It does not matter if you log out after the 'REPLY/ENABLE' command, because the logical name is gone already.

- you have put a 'DEASSIGN/USER_MODE' in front of the 'REPLY/DISABLE' command, but it should have been a 'DEFINE/USER_MODE' again.

Well, I hope that clears it up a little and does not raise any new confusion ;-)