| Title: | DECmcc user notes file. Does not replace IPMT. |
| Notice: | Use IPMT for problems. Newsletter location in note 6187 |
| Moderator: | TAEC::BEROUD |
| Created: | Mon Aug 21 1989 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 6497 |
| Total number of notes: | 27359 |
Hi,
This has been covered many times before, and I apologise for
covering it again, but I'm failing on this miserably :-
Customer site is connected to multiple DECnet Phase IV areas, and have
two hundred DECnet nodes in their area (area 9). I want to use
DECnet adjacency up/down events through the MCC_DNA4_EVL into OCCURS
rules for 10 of these nodes, the other systems are PC's and I don't
want to overload the operator with alarms. I would also plan on using
targetting to get the node4 that is unreachable to change colour, not
the node checking (the router). The 10 nodes I need to get alarms for
are spread across two domains.
I have followed the examples in the manual and can get various bits of
this all working but not the whole. Can someone whose succeeded in this
post some example occurs rules and targetting that will cover 10 nodes
across all domains. If it's any help the ten node4 entities are the
only node4 entities on those two domains so could some wildcarding be
done on the targetting ?
Thanks for any help and examples,
Euan
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 5573.1 | try this | UFHIS::WSIEGMUND | Seaboard riding on Seahorse | Wed Sep 08 1993 04:40 | 79 |
Euan,
this is the procedure I use to demo
targetting in class. It needs some editing
on nodenames and passwords (@defqual.com).
You also may want to modify the BLOCK command
into PASS for test purposes.
May be it helps
Wolfgang
$ set ver
$! mcc_dna4_adjacency.com 7-apr-1993
$! DECmcc routing host event setup and retargeting
$! run @SYS$STARTUP:MCC_STARTUP_DNA4_EVL.COM first
$!
$!
$! Keep SYS$LOGIN error log files down to a minimum.
$PURGE MCC_DNA4_EVL.LOG/keep=10
$!
$!
$ manage/enterprise
define routing_host ufv094
define mcc_host ufv705
define mcc_host_addr 1.705
define domain_name .DOMAIN.unterfoehring
!use default qualifier by user mccman, by pass mccmcc
@defqual.com
!**************************************************************
!
! Make sure routing_host knows mcc_host
!
create node4 routing_host remote node mcc_host address mcc_host_addr
!
! routing_host needs enough broadcast nonrouters
!
SET NODE4 routing_host MAX BROADCAST NONROUTERS 1023
!
! Make sure no old Remote Sinks are lying around.
!
DELETE node4 routing_host outbound stream mcc_host remote sink MONITOR
!
! Set up to sink adjacency events of class 4
!
CREATE node4 routing_host outbound stream mcc_host remote sink MONITOR -
class = 4, event type = {15,18} ! Adjacency up, down
!
! Set up to sink other events of class 4 for test purposes only
!
block node4 routing_host outbound stream mcc_host remote sink MONITOR -
class = 4, event type = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,16,17,19}
!
! Set up other events of class 0 for test purposes only (zero counters)
!
BLOCK node4 routing_host outbound stream mcc_host remote sink MONITOR -
class = 0, event type = {0,1,2,3,4,5,6,7,8,9}
!
!
use default qualifier
!
! Assign Targets for Adjacency DOWN/UP Events
! Eventsource routing_host circuit *
!
assign target domain domain_name -
event source node4 * circuit * adjacent node * , -
event name "adjacency down", -
managed object "node4 #1 circuit #2 adjacent node #3", -
target entity "node4 #3", -
target severity critical
!
assign target domain domain_name -
event source node4 * circuit * adjacent node * , -
event name "adjacency up", -
managed object "node4 #1 circuit #2 adjacent node #3", -
target entity "node4 #3", -
target severity warning
exit
$set nover
| |||||
| 5573.2 | Done (sort of hacked in !) | FILTON::BARKER_E | Ummm... | Fri Sep 17 1993 09:04 | 10 |
Thanks for the reply. I ended up using the event sink setup as in your
procedure (and the MCC_DNA4_EVL command procedure), and then used
Notify requests to only pick up the specific nodes I was interested in.
This works fine but does mean the list of notify requests from the
Notifications window is quite long (15 entries at the moment). Doesn't
seem to affect performance so it's staying !
Thanks again,
Euan
| |||||
| 5573.3 | not a hack | TOOK::CALLANDER | Fri Sep 17 1993 14:49 | 7 | |
it should not be a major performance hit, if any, using the mutliple
notify commands. The design of the notification services shares
threads as much as possible so that the overhead of a new notify
command is extremely limited, especially if it is on the same
domain or for events on the same set of entities.
| |||||