Operating System - OpenVMS
1827791 Members
2892 Online
109969 Solutions
New Discussion

Redirecting Operator Messages

 
SOLVED
Go to solution
Ronnie Doggart
Frequent Advisor

Redirecting Operator Messages

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
13 REPLIES 13
Ian Miller.
Honored Contributor
Solution

Re: Redirecting Operator Messages

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.
____________________
Purely Personal Opinion
Ian Miller.
Honored Contributor

Re: Redirecting Operator Messages

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.
____________________
Purely Personal Opinion
Uwe Zessin
Honored Contributor

Re: Redirecting Operator Messages

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

Re: Redirecting Operator Messages

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
Jan van den Ende
Honored Contributor

Re: Redirecting Operator Messages

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
Don't rust yours pelled jacker to fine doll missed aches.
Robert Atkinson
Respected Contributor

Re: Redirecting Operator Messages

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.
Mobeen_1
Esteemed Contributor

Re: Redirecting Operator Messages

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
Dale A. Marcy
Trusted Contributor

Re: Redirecting Operator Messages

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?
Mobeen_1
Esteemed Contributor

Re: Redirecting Operator Messages

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
Jan van den Ende
Honored Contributor

Re: Redirecting Operator Messages

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
Don't rust yours pelled jacker to fine doll missed aches.
Dale A. Marcy
Trusted Contributor

Re: Redirecting Operator Messages

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.
Mobeen_1
Esteemed Contributor

Re: Redirecting Operator Messages

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

Re: Redirecting Operator Messages

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 ;-)
.