| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 820.1 | Have the docs....
| DUCAT2::64544::LICAUSE | Al Licause (338-5661) | Wed Mar 20 1991 13:46 | 9 |
| RE:.0
I have the DECMCC_DECNET4_AM_USE_V11_FINAL and it doesn't give me any more
help.
Al
I"m sure I'm missing something simple.
|
| 820.2 | is there an alarm? | JETSAM::WOODCOCK | | Wed Mar 20 1991 14:03 | 16 |
| Hi Al,
Have you written an alarm for the event? MCC icons don't actually react
to events themselves from what I've seen. They react to alarms. For example
an alarm with the following expression can be used for adj node downs (event
4.18):
expression=(occurs(node4 <name> circuit <cir-name> adjacent node -
* adjacency down))
where <name> is the name of the node which created the event. Check the
manuals because there are a few options which might apply (ie, severity,
domain, etc)
brad...
|
| 820.3 | Yes.....but a PC? | DUCAT2::64544::LICAUSE | Al Licause (338-5661) | Wed Mar 20 1991 21:32 | 12 |
| RE:.2
Actually I have created an alarm and have seen it fire several times,
but still no reaction from the iconic map. It did fire off many mail
messages, but could not get same to react when broadcasting.
I'll keep trying different combinations......could it be that the PC
is not a good vehicle on which to test remote node occurences?
Al
|
| 820.4 | more info | QUANTZ::HAO | | Thu Mar 21 1991 09:22 | 15 |
| re: .2
That's correct. In V1.1 of Iconic Map PM, we only support icon color
changes for alarms, not events.
re: .3
Have you enabled notification in the Iconic Map PM. It's the
File/EnableNotification menu item. This can be customized under
the Customize/Map menu item to be automatically started for all
your map windows. The default is not to start notification
automatically.
Christine
|
| 820.5 | | DUCAT2::64544::LICAUSE | Al Licause (338-5661) | Thu Mar 21 1991 11:23 | 58 |
| RE:.3
Yes....notification is enabled. Just to be sure, I did go into the
customize screen and noticed that it was set to default to enabled.
I also disabled and re-enabled several times while an event was occuring
with an alarm. Included is the alarm:
CREATE MCC 0 ALARMS RULE REMOTE_NODE_MEOWW_STATE -
EXPRESSION = (NODE4 FOUR62 REMOTE NODE MEOWW STATE = UNREACHABLE ,-
AT EVERY 00:01:00) ,-
PERCEIVED SEVERITY = CRITICAL ,-
PROCEDURE = MCC_COMMON:MCC_ALARMS_BROADCAST_ALARM.COM ,-
EXCEPTION HANDLER = MCC_COMMON:MCC_ALARMS_BROADCAST_EXCEPTION.COM ,-
CATEGORY = "Node unreachable" ,-
DESCRIPTION = "If a node becomes unreachable, the alarm notification -
command procedure will be run.", -
PARAMETER = "USER=LICAUSE"
I've also included the MCC display to show that the rule was firing.
I still see no indication of color change on the map
MCC 0 ALARMS RULE REMOTE_NODE_MEOWW_STATE
AT 21-MAR-1991 11:16:12 All Attributes
NAME = REMOTE_NODE_MEOWW_STATE
Result of Last Evaluation = False
State = Enabled
Substate = Running
Time of Last Evaluation = 21-MAR-1991 11:16:09.63
Creation Timestamp = 21-MAR-1991 10:58:09.36
Evaluation Error = 0
Evaluation False = 10
Evaluation True = 9
Category = "Node unreachable"
Description = "If a node becomes unreachable, the
alarm notification command
procedure will be run."
Exception Handler = SYS$COMMON:[MCC]MCC_ALARMS_BROADCAST_E
XCEPTION.COM;1
Expression = (NODE4 FOUR62 REMOTE NODE MEOWW STATE
= UNREACHABLE ,
AT EVERY 00:01:00)
Parameter = "USER=LICAUSE"
Perceived Severity = critical
Procedure = SYS$COMMON:[MCC]MCC_ALARMS_BROADCAST_A
LARM.COM;1
While this was going on, I was receiving broadcast events on another screen.
The polling time was specifically set low for testing.
What am I missing or where have I been stupid?
Al
|
| 820.6 | show known logging is what we send out not receive | NAC::SCHLENER | | Thu Mar 21 1991 11:52 | 15 |
| I think that your evl problem is that you haven't set up logging events
on the PC side. Show known logging only tells you what YOUR node will
SEND! (It doesn't tell you what nodes are sending you what events).
So basically, you have your events set up in reverse. You need to tell
the PC to send all events to your node.
I'm not sure that a PC will allow you to tell it to send events to a
particular node. Being in the PC world, I think the only commands that
the PC NML will allow are SHOWs and ZEROs.(Will check that out).
But if you want to use any node to send you events, you can use
the MCC commands of PASS or CREATE with NODE4 being the node that is to
send your node the event.
Cindy
|
| 820.7 | try... | TOOK::CALLANDER | | Thu Mar 21 1991 11:54 | 16 |
|
The rule is definitley running on the system.
Notification is enabled, and the default is set to enabled.
Try closing the domain and opening it again (start a new map window
with the same domain in it).
Remember the map represents the view of the domain as of when you opened it.
It is possible that the domain has been modified and your display hasn't been
updated.
Go the the FCL PM and do a NOTIFY DOMAIN <name> command and see if you
get the notification message. When you get the message check the
entity information that is displayed and verify that it is spelt
correctly and that it matches the registration information.
|
| 820.8 | My two cents, or quarter, or dollar fifty.... | TOOK::CAREY | | Thu Mar 21 1991 14:44 | 139 |
|
Following are some musings about what I thought about after reading
this. From the DECnet perspective I think that the most important
problem is what you are really interested in:
- Are you interested in events that occur on the PC?
- Or are your interested in events that occur on the routing node
(FOUR62) that concern the PC?
Look over the rest of this (regrettably long) to get an idea what I
mean. With a little luck, you will notice something that is slightly
different than you were looking at it, and this will fall together.
-Jim Carey
* * * * * * * *
First, some background information. This note is getting too confusing
for me to be sure I understand just what is going on.
RE: .0
Network object MCC_DNA4_EVL is declared, Status = 52854793
Waiting for the event message from EVL.....
The connection with EVL is established.
** Unable to connect to NMCC **
Ready to read the next event message...
Ready to read the next event message...
Ready to read the next event message...
The information collected by MCC_DNA4_EVL.LOG looks just fine. This is
reporting that the Event Monitor is starting up okay, that you don't
have NMCC installed on your system (okay), and that EVL is delivering
events to MCC_DNA4_EVL.
MCC_DNA4_EVL consumes all events that are delivered to it, and you are
sinking pretty well everything that shows up at EVL to the logging
monitor. That's fine, too. The report:
Ready to read the next event message...
indicates that an event was delivered to our process, and delivered to
the MCC Event Manageer for [possible] consumption. If noone had a
GETEVENT request outstanding against that event, the event report
is just discarded at at that time.
This is good, as it proves that event reports are getting fed into the
DECmcc system by your setup.
The question to this point is whether your 325 is sinking its event
reports to your node for delivery to the event logging monitor. In .6,
Cindy isn't too sure that the PC can be configured to deliver events to
a remote sink monitor. I plead ignorance about DECnet DOS capabilities
and management. However, if you can't manage that by using MCC
commands from FOUR62, you can try the NCP commands on the DOS machine:
successfully sending the events to the logging sink monitor on remote
sink FOUR62 is the same whether you use DECmcc or NCP.
Take a look at the event logging characteristics of your PC, and see
how that is configured. To receive events on FOUR62 that occur on the
PC, you must explicitly instruct the PC to send the events to the
LOGGING SINK MONITOR on REMOTE SINK FOUR62.
FYI - From NCP on DECnet VMS, the logging sink event list seems to
describe both the events it will send out, and the events is stands
ready to receive from other sources (such as your PC). So, in practice
it looks like the list you set up there will allow two things:
- All events happening on FOUR62 will be delivered for potential
use by DECmcc.
- All events received from external nodes will be delivered as
well.
The opposite also seems to be true: excluding an event from that list
prevents it from being passed to the MONITOR from both the local node,
and any external sources.
Back to the problem:
Here is where it might get a little confusing. The entity specified in
the GETEVENT command is the node upon which the event occurs. In this
case, "pcnodename".
MCC> GETEVENT NODE4 pcnodename ANY EVENTS
That is, the only events that will cause DECmcc to complete this
GETEVENT directive are events which OCCUR on the pc, and are delivered
to the logging sink monitor on FOUR62.
I notice that you made FOUR62 into a routing node, and I presume that
the REPLY/ENA=NET command was issued at FOUR62 to display events at
your console on FOUR62. If that is true, then my guess here is that
the event that you receive on the console is a "Node Reachability
Changed" event (4.14).
This event is detected by the routing node (FOUR62) which notices that
it can no longer reach a Remote Node. Unfortunately, there are about a
million reasons to lose reachability, and we can't infer a problem on
the actual remote node. All DECnet knows for sure is that it used to
be able to reach the PC, and now it can't. The Event Report that is
generated refers to the routing node that detects it (NODE4 FOUR62),
and the Remote Node which is no longer reachable (REMOTE NODE
pcnodename). That means that a GETEVENT request to detect this
happening is something like this:
MCC> GETEVENT NODE4 FOUR62 REMOTE NODE pcnodename ANY EVENT
or
MCC> GETEVENT NODE4 FOUR62 REMOTE NODE pcnodename -
Node Reachability Change
In .2 Brad correctly describes an alarm expression that would fire if
the routing node FOUR62 generated an Adjacency Down event from
detecting this same loss of contact. He uses a wildcard to detect any
loss of adjacency, but specifies the routing node correctly as the
node4 where the event report is generated. In DECnet phase 4 at least,
the routing nodes notice these topology changes, so they generate the
events.
In .5, the Alarm rule you display there looks like a request to poll
the routing node about the reachability of MEOWW. While I think it is
a good rule, it doesn't have anything to do with the events that are
occurring on your net. A note about reachability: In our network, in
a large extended area, it can take five minutes or more for a node to
conclusively become unreachable to all routers. The routing algorithms
require the routers to have quite a conversation before they decide
such an important issue. Turning a PC off and then on might not have
it off the net for long enough to be missed. Adjacency changes from a
router on the same LAN provide a much quicker response.
Finally, in all of these notes, I hope you are expecting the Node4
FOUR62 to change color. If it isn't in the domain you're watching,
(for example, if you're watching the pc only), then that is a reason
that you haven't seen an alert on the map. In V1.1 only the Global
Entity for rule can change color. Almost everything we have discussed
is centered around the routing node FOUR62.
|
| 820.9 | true, but.. | JETSAM::WOODCOCK | | Thu Mar 21 1991 15:27 | 7 |
| >> In V1.1 only the Global Entity for rule can change color.
This is true but you can be creative and write a .com to be fired which
is quicker than the eye and highlights the proper entity. Appropriately
named TARGET_ENTITY.COM ;-).
brad...
|
| 820.10 | Did I/you miss the IN domain qualifier? | WAKEME::ANIL | | Thu Mar 21 1991 17:31 | 20 |
| Re: 820.5
>CREATE MCC 0 ALARMS RULE REMOTE_NODE_MEOWW_STATE -
> EXPRESSION = (NODE4 FOUR62 REMOTE NODE MEOWW STATE = UNREACHABLE ,-
> AT EVERY 00:01:00) ,-
> PERCEIVED SEVERITY = CRITICAL ,-
> PROCEDURE = MCC_COMMON:MCC_ALARMS_BROADCAST_ALARM.COM ,-
> EXCEPTION HANDLER = MCC_COMMON:MCC_ALARMS_BROADCAST_EXCEPTION.COM ,-
> CATEGORY = "Node unreachable" ,-
> DESCRIPTION = "If a node becomes unreachable, the alarm notification -
> command procedure will be run.", -
> PARAMETER = "USER=LICAUSE"
>
>
I did not see the IN domain qualifier. Did I/you miss it? If the rule is created
without a domain context it fires in "no name" domain (Read map can not change
color!). Create the above rule in appropriate domain context and try again.
Let us know if this does not work.
|
| 820.11 | It was the IN DOMAIN that was missing | DUCAT2::64544::LICAUSE | Al Licause (338-5661) | Fri Mar 22 1991 08:49 | 19 |
| Thanks to all for some excellent feedback.
I had a good conversation with Jill Callander yesterday and she recognized
the fact that I had not included the IN DOMAIN qualifier.
Once I placed this at the end of the rule, I was able to see a color change
in the sink node, in this case FOUR62.
I would be interested in seeing an example, however, as mentioned in .9
that would allow me to get the real icon to change colors.
RE:.8 I did check on the PC and there does not appear to be any facility
for setting up a remote logging sink.
Again thanks for the info.....I've got a bit more studying to do before
I understand thoroughly all the possible combinations and permutations
of the alarms.....
Al
|