Conference azur::mcc

	Unfortunately, the functionality you are looking for is not available
	for V1.3. However, we are working on an entity reachability application
	(for DNA4 and SNMP entities) which will greatly improve on the current
	functionality provided by the IP Poller.

	Rahul.

    I just modified the IP Poller Config COM File at a Customer Site
    to be no longer interactive, but accept P1 to P4 as a Input
    (You find the name of the original COM file in the Menu Files)
    
    
    I named the modified COM file i.e. MCC_ip_POLL_newStart.com
    and just add this line to the SYSSTARTUP:
    
    submit sys$startup:MCC_ip_POLL_newStart.com  .mydomain 60 2 10
    
    => poll every 60 sec, 2 retries, 10sec timeout
    
    
    
    It seems to work at the Customer Site,but I did not check extensively...
    I use it to poll all FDDI Components for Availability
    
    As soon as I restore this Customer System, i can add a Reply with this
    COM file.
    
    
    					Guenter

	The command file is not visible to the user and so we try not
	to advertise it. However, for an experienced user, what you are doing
	may be perfectly okay. 

	Rahul.

RE. .1 
/	Unfortunately, the functionality you are looking for is not available
/	for V1.3. 


Does this mean that the "mcc IP reachability poller" was designed to work only
interactively in V1.3 and should NOT been used to replace a DECmcc
implementation based on "Ping" alarm rules?

I'm currently using alarm rules (snmp * Ipreachability <> Up) which are enabled
at system startup and running by a detached DECmcc process.
Each time a user is starting up a DECmcc Iconic map, he will get a notification
for each unreachable TCP/IP entity.

The "mcc IP reachability poller" doesn't give you the same functionality. 
Each time a user is starting up a DECmcc Iconic map, he will NOT get a 
notification for each unreachable TCP/IP entity, even it the appropriate
notifications are enabled.

This missing functionality or bug? prevents us from implementing the 
IP poller at customer sites. 
Imagine, the whole IP network is down and the person just starting the IMPM
doesn't get notified.



RE. .1
/	However, we are working on an entity reachability application
/	(for DNA4 and SNMP entities) which will greatly improve on the current
/	functionality provided by the IP Poller.

What is the goal of such an entity reachability application?
Should such an application replace the current strategy of using 
"reachability" alarm rules based on active polling or will it be just extended
to support additional classes like DNA4?   


				Roland

>>The "mcc IP reachability poller" doesn't give you the same functionality. 
>>Each time a user is starting up a DECmcc Iconic map, he will NOT get a 
>>notification for each unreachable TCP/IP entity, even it the appropriate
>>notifications are enabled.

	Correct. The user will have to open each domain, launch the IP Poller
	application and enable polling in the current domain. Polling is enabled
	on sub-domains too, so if the domains are laid out in a hierarchical
	structure, then enabling polling in the top-most domain should suffice.


>>This missing functionality or bug? prevents us from implementing the 

	This is missing functionality. Some folks in this note have created
	workarounds by hacking up the command files which come with the
	poller to accomplish automatic reachability testing on all domains.
	You might want to contact them for details. Deploying the IP Poller
	will greatly reduce your consumption of system resources associated
	with creation of multiple alarm threads, and would also dramatically
	improve response time.

>>What is the goal of such an entity reachability application?
>>Should such an application replace the current strategy of using 
>>"reachability" alarm rules based on active polling or will it be just extended
>>to support additional classes like DNA4?   

	Besides providing a motif-based user interface and support for DNA4
	entities, the application will allow automatic startup through scripts.
	Persistence of state between multiple invocations is another feature
	it provides. We expect this application to completely replace the
	currently scheme of doing reachability testing through alarm rules
	for DNA4 and SNMP entities.

	Rahul.

			Hi Rahul,


>>	This is missing functionality. Some folks in this note have created
>>	workarounds by hacking up the command files which come with the
>>	poller to accomplish automatic reachability testing on all domains.


I also hacked the command scripts. 

The following happens automatically at system startup:

- create the mcc_ip_poller process 
- start detMCC with the following alarm rules to get notification via mail: 
	occurs (snmp * IP Reachability Down)
	occurs (snmp * IP Reachability Up)
- create the mcc_specific:mcc_ip_poller_action.dat file 


The following happens automatically at each invocation of  the IMPM:

- create the following notify requests:
   notify domain Topdomain entity list=(snmp *), events=(IP Reachability Down) 
   notify domain Topdomain entity list=(snmp *), events=(IP Reachability Up) 
- create the mcc_specific:mcc_ip_poller_action.dat file


 
>>	the application will allow automatic startup through scripts.
>>	Persistence of state between multiple invocations is another feature
	it provides. 

I have noticed that each time a DECmcc user is invoking the IMPM and there are
unreachable TCP/IP hosts, the occurs rule "IP Reachability Down" is firing,
i.e. the customer would be noticed each time a DECmcc user is starting up his
Iconic Map.
Hopefully, the above mentioned case will be considered in the next release. 


				Roland

>>I have noticed that each time a DECmcc user is invoking the IMPM and there are
>>unreachable TCP/IP hosts, the occurs rule "IP Reachability Down" is firing,
>>i.e. the customer would be noticed each time a DECmcc user is starting up his
>>Iconic Map.
>>Hopefully, the above mentioned case will be considered in the next release. 
	
	Yes, it has been taken into consideration.

	rb.