Re: how to turn off OPCOM messages on a console terminal
- From: norm.raphael@xxxxxxxxx
- Date: Thu, 22 Jun 2006 14:58:35 -0400
hoffman@xdelta () wrote on 06/22/2006 01:49:02 PM:
In article <OF2D1DC406.EB9ED9AF-ON85257195.005725CE-85257195.not
0058BA49@xxxxxxxxx>, norm.raphael@xxxxxxxxx writes:
|> Can I get "REPLY/TO" messages to go to the operator.log file only, but
|> hang.
The REQUEST/REPLY (or the lower-level equivalent that an application
program can use, a call via $sndopr) will continue to be broadcast
because there is an enabled operator terminal somewhere in the cluster.
If there is no operator terminal, the REQUEST/REPLY (or the $sndopr call
analog) will terminate.
If you have a specific operator target via REQUEST/REPLY/TO or via
the target operator bitmask within $sndopr, you can ensure that no
matching operators enabled, while also ensuring the operator log has
the operator class enabled for logging. This via SYLOGICALS.* OPC$*
logical names.
If you just want to log a message, then REQUEST (or an equivalent
$sndopr call) will work fine, and will display the message at the
target operator(s).
If you are seeing a hang within OPCOM (other than the expected
synchornization involving REQUEST/REPLY, obviously), then there
is something else going on.
If the application hangs, then there is probably something wrong
within the application -- a resource leak or other run-time error.
I can think of a potential brute-force work-around (or two) for
this sort of thing, but I'd tend to look to the application
maintainer(s) first.
If you are seeing new request ids, then there may well be a leak
within the $sndopr code involved in the application. The expected
and normal behaviour is to repeat the operator broadcasts at a
periodic interval until the request is serviced. If you are seeing
new request identifiers issued, this may well be the source of the
eventual application stall.1
Again, the best approach is to engage whomever is maintaining the
application -- or to ensure there are either no operators, or that
the operators service the request before the application tips over.
Obviously.
This has always vexed me. This app AFAIK does not listen for or
expect a response to the message; it's more like an "I'm still here"
sanity check. (I always thought it was part of some vestigial or
debugging code that got left in the final product - ISTM that REQUEST
or a call to $SNDOPR without expecting a reply would have been correct.)
It does get automagically cancelled after 5 minutes, when a new-numbered
request is issued. The docs say a terminal must be enabled somewhere on
the system to process this message. No operator action (service of the
request?) is needed. I no terminal is enabled for OPERxx - assigned
at startup of the app - eventually it will tip over, as you say.
There does not appear to be a leak, but the "maintainer" has no
intention of touching the code, which has been frozen for some time,
as the workaround is documented. If I can use logicals to get
messages to, say, OPER10 to log to operator.log without having a
physical terminal set "REPLY/ENABLE=(OPER10)" that would do it.
Alternately, if there is a way to create a "virtual terminal" and
enable it to get-and-ignore these messages and I could start it at
boot and just leave it, that would be okay, too.
cancels
|> Here's an excerpt:
|> [start]
|> %%%%%%%%%%% OPCOM 11-JUN-2006 09:18:22.46 %%%%%%%%%%% (from node
|> NODE1 at
|> 11-JUN-2006 09:18:22.46)
|> Request 3798, from user USERx on NODE1
|> CSTI006O APPLID, Reply with an APPLID command.
|>
|> ***************
|>
|> %%%%%%%%%%% OPCOM 11-JUN-2006 09:23:47.91 %%%%%%%%%%% (from node
|> NODEA at
|> 11-JUN-2006 09:23:47.92)
|> Request 3798 was canceled
|> [end]
|>
|> The app puts out this every 5 minutes and apparently the new one
|> the prior one, but if no terminal
|> is REPLY/ENABLED the application eventually fills some buffer (or
|> something) and hangs.
|>
.
- Follow-Ups:
- Prev by Date: Re: how to turn off OPCOM messages on a console terminal
- Next by Date: TELNET PERFORMANCE OVER WAN
- Previous by thread: Re: how to turn off OPCOM messages on a console terminal
- Next by thread: Re: how to turn off OPCOM messages on a console terminal
- Index(es):
Relevant Pages
|
