Conference azur::mcc

3700.0. "REtarget procedure for OSI Router events" by FOUR62::LICAUSE (Al Licause (338-5661)) Tue Sep 08 1992 00:07

In attempting to retarget a node reachability event from a WANrouter 500,
it was discovered and confirmed by MCC engineering that DECmcc V1.2 does
not currently parse enough information to determine a new target from a
simple notification event.

I have written, with the help of MCC engineering and others, a simple rule
which allows targeting of such an event.

Ultimate goal:  When a Phase IV node becomes reachable/unreachable, and
the router is an OSI router, the end node icon will change color, indicating
the node effected.

When such a event occurs, information is contained in the additional
parameters section of the event report.  The two peices of info that
are important are 1) the Phase IV DECnet physical addres (AA-00-04...)
and 2) the state of the node (Up/Down).

Note that two methods for determining the node name. One which simply
uses NCP and the other uses a facility supplied with DECnet VAX extensions
to make a call to DNS.  A third could involve a call to MCC.

Also note that if you have PC's on your network running DECnet, the router
will report them in a similar manner.  However, if you are not running
NML on the PC's, you may not have them registered as Phase IV nodes
with DECmcc (NODE4).  Therefor, you will have to modify this procedure
to determine when you have detected such a node and in which category
you have registered same.

Please feel free to comment or modify this procedure and please post
both as replies.  Support...your on your own!

Below I have include the alarm characteristics followed by the procedure.

Al
==============================================================================

Domain DDCVAX_NS:.dwo Rule NODE_RECHABILITY_CHANGE 
AT  3-SEP-1992 16:16:50 All Attributes

Name = NODE_RECHABILITY_CHANGE
State = Disabled
Expression = (OCCURS (Node DDCVAX_NS:.dwodr1 
              Routing Circuit csmacd-0 Reachability Change))
Description = "This rule fires when an OSI router detects a node up/down"
Category = "Remote node State Change"
Alarm Fired Procedure = USER1:[MCC_USER.COMFILES]MCC_ADJACENC_RULE.COM;2
                            Batch Queue = "SYS$BATCH"
                 Alarm Fired Parameters = "DDCVAX::DECMCC"
                               Severity = Indeterminate
                         Probable Cause = Unknown
------------------------------------------------------------------------------
$! MCC_ADJACENCY_RULE.COM
$!
$! This procedure will be executed each time the MCC alarm rule 
$! NODE_REACHABILITY_CHANGE fires.  The rule will fire when the "OSI router"
$! detects a node reachability change.
$! If DNS is in use, it will obtain the node name from DNS otherwise only
$! the decimal form of the node address will be reported.
$!
$!  Author	Al Licause	9/3/92
$!
$ ncp			:== $ncp
$ netmig   		:== "$SYS$UPDATE:DECNET_MIGRATE"
$ send_event 		:== $user1:[mcc_user]mcc_evc_send.exe  
$ sink_node 		:== DDCVAX
$ collector_name 	:== vax_col
$ afi			:== "49::"
$ dns_srv		:== "DDCVAX_NS:"
$ entity		:== "NODE4"
$!
$! Parameter P8 contains all "additional" information in log file from event
$! Examine it and determine the remote nodes address
$!
$ search/output=sys$scratch:mcc_alarm_arguments.txt 'P8 ARGUMENTS
$ open/read args sys$scratch:mcc_alarm_arguments.txt
$ read args string
$ close args
$ delete/noconfirm sys$scratch:mcc_alarm_arguments.txt.*
$!
$! Parse the address and node status
$!
$ state = f$edit(f$extr(f$loc("New ID Reachability = ", string)+22,4,string),"TRIM")
$ phys_addr = f$extr(f$loc("Adjacent Node = ", string)+16,17,string)
$ address = f$extr(f$loc("Adjacent Node = ", string)+28,5,string)
$ hibyte = f$extr(3,2,address)
$ lobyte = f$extr(0,2,address)
$ hex_decnet = hibyte + lobyte
$! 
$! If DNS in use then query DNS for node name information, else calculate
$! the decimal equivalent and use it for retargeting.
$!
$ if f$trn("MCC_DNS_SELECTION").eqs."DNS" then goto use_dns
$ node_addr = f$string(%x'hex_decnet/1024) + "." + f$string(%x'hex_decnet - (%x'hex_decnet/1024)*1024)
$ ncp show node 'node_addr' to sys$scratch:target.txt
$ search/out=target_node.txt sys$scratch:target.txt 'node_addr'
$ delete/noconf sys$scratch:target.txt;*
$ open/read file sys$scratch:target_node.txt
$ read file string
$ close file
$ delete/noconf sys$scratch:target_node.txt;*
$ node = f$extr(f$loc("(",string)+1,f$loc(")",string)-f$loc("(",string)-1,string)
$ addr = "(" + node_addr + ")"
$ goto notify_collector
$!
$! If using DNS then use DECnet physical address to determine the OSI address
$! and pass it to DNS to retrieve the node name.
$!
$ use_dns:
$ tmp1 = f$int(%x'hex_decnet)
$ tmp2 = f$fao("!XW",(f$fao("!ZW",tmp1)/1024))
$ area = f$extr(0,2,tmp2) + "-" + f$extr(2,2,tmp2)
$ osi_addr = dns_srv + afi + area + ":" + phys_addr + ":00"
$ define sys$output sys$scratch:dns_info.txt
$ netmig DNS_SHO 'osi_addr' B
$ deassign sys$output
$ search/output=sys$scratch:node_info.txt/win=2 sys$scratch:dns_info.txt ->
$ delete/noconfirm sys$scratch:dns_info.txt;*
$ open/read file sys$scratch:node_info.txt
$ read file name
$ read file num
$ close file
$ delete/noconfirm sys$scratch:node_info.txt;*
$!
$! Now extract the node name and address from DNS returned info
$!
$ node = f$edit(f$extr(f$loc("(",name)+1,f$loc(")",name)-f$loc("(",name)-1,name),"UPCASE")
$ addr = f$extr(f$loc("(",num),f$loc(")",num)-f$loc("(",num)+1,num)
$!
$! Indicate the new condition to MCC using the collector mechanism
$!
$ notify_collector:
$!
$! Check for presence of "PC" in name string....if found then it is a REFERENCE
$! entity and not a NODE4.
$!
$ if f$extr(3,2,node).eqs."PC" then entity = "REFERENCE"
$ severity :== "critical"
$ if state.eqs."Up" then severity :== "clear"
$!
$ 		send_event 'sink_node  		-
		"''collector_name'"		-
		"''entity' ''node'"	 	-
		"Node ''node' ''addr' ''state'"	-
		""				-
		"''severity'"
$!
$ purge/keep=5 USER1:[MCC_USER]MCC_ADJACENCY_RULE.LOG 

The solution in .0 has a small problem because correlation for
data collector events is done on the event title, which is
coded in .0 as including the word "up" or "down" depending
on what the event indicated.  The result is that if a node goes
DOWN (turning icon RED) and then comes back UP, the two events won't
correlate to one another and the icon will stay RED (if the IMPM
is using HIGHEST notification propagation policy).

See the "advanced customization" and "correlation of notifications"
sections in the "Alarms and Notification Use" manual for more 
information on correlation of notifications.

There are three ways around this:

	1) Omit the state information ("up" or "down") from the event
	   title.  Send this information in the event text.  The 
	   severity (Critical or Clear) implies the "up" or "down" 
	   anyway.  To do this, change the following portion of the 
	   command file to:

$!
$! Check for presence of "PC" in name string....if found then it is a REFERENCE
$! entity and not a NODE4.
$!
$ if f$extr(3,2,node).eqs."PC" then entity = "REFERENCE"
$ severity :== "critical"
$ if state.eqs."Up" then severity :== "clear"
$!
$ 		send_event 'sink_node	  		-
		"''collector_name'"			-
		"''entity' ''node'"	 		-
		"Node ''node' ''addr' state change"	-
		"New state is ''state'"			-
		"''severity'"


	   (optionally, you can send as much of the original
	    event's text in the "event text" (5th) argument
	    as DCL will let you fit on the command line, up to 256 chars)

	2) Use LATEST notification propagation policy.  This is 
	   a policy choice that you may not be willing to make, as
	   it costs you a certain amount of functionality.

	   To do this, use the Map->Customize dialogue box and
	   choose LATEST.  Save your settings, exit, and restart IMPM.

	3) Allow correlation of data collector events to occur
	   in the default manner (by notify request) instead of
	   by event text.  Again, this costs you some functionality,
	   as the IMPM/Notif PM will no longer be able to track
	   multiple independent data collector reported conditions on 
	   a single entity unless you set up one notify request per
	   desired data collector instance and all independent 
	   conditions are reported via independent data collectors. 
  
	   To do this, change the following line in your 
	   mcc_notification_resource.dat to:

mcc_ns.replyTextMatchEnts:

	   (that is, do not do matching on replyText for any entity
	    classes)

Another potential problem with the above approach is that
you will want to use it for several domains.  Putting the
same data collector into each domain will result in events for
entities that don't live in that domain being sent to the
incorrect domain.  Also, if the domains are in the same domain
tree, you may get the same event several times.

One solution is to alter the command procedure to determine
which domain the rule is defined in (sent as one of the parameters
to the action procedure) and use that to determine which data collector
to send the event to.  Then, put a distinct data collector (whose
name is based on the domain's name) into each of the domains that
you define the rule in.