Redirecting Operator Messages

[Ronnie Doggart]

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

[Ian Miller. · Accepted solution]

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.

[Ian Miller.]

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.

[Uwe Zessin]

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]

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]

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

[Robert Atkinson]

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]

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]

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]

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]

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

[Dale A. Marcy]

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]

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]

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