Conference azur::mcc

3295.0. "problems with trap sink & ucx snmp queries" by NSCRUE::KEANE (U.S. NIS Service Engineering and Delivery) Thu Jul 02 1992 18:31

    
    MCC BMS T1.2.7 with elm, tsam, and tcpip fda
    VMS V5.5
    UCX FT 2.0
    
    I've run into a couple of problems with using the UCX 2.0 field test
    and would like to know if anyone else has seen the same things. I put
    one of the problems in the UCX notes file but haven't heard anything
    back.
    
    1) I had the ucx020 kit dated from June 29th installed. The kit was
    copied from smurf::ucx$kit_v2. If I attempt to do an snmp query from
    either mcc or msu for interface information, it fails. On mcc fcl I get
    an error saying attribute not available (this is from memory, as I have
    reverted to an older version of ucx). On msu is actually causes the
    query window to disappear. I'm now on ucx ft version 3020. On that
    version I can't get any snmp query to work.
    
    2) Again, using the June 29th UCX kit, I was setting up some occurs
    rules to look for linkup and linkdown from a router. Enabling an alarm
    rule or a notification request would cause the sink process to start as
    expected. The first trap from the router would be seen and then the
    sink process would die. I would have to disable and re-enable the rules
    to get the sink process started again, and then it would fail the same
    way. The sink process works as advertised running UCX ft3020.
    
    I could not find any error logs that talked about why the process was
    terminated. The ...sink.err files are empty. Image accounting didn't
    help much either. 
    
    Any info appreciated.
    
    Scott

regarding the mcc tcpip_am sink  ...

There are 3 situations when the mcc tcpip_am sink may unexpectantly die AFTER
it receives a trap:



	- io errors 

	   The sink uses the (UCX) socket interface calls select (while waiting
	   for traps) and readfrom (to read the trap data once a trap
	   has been received). Errors with either one of these calls
	   will cause the sink to die.

	- mcc call errors 

	   The sink uses the mcc calls mcc_aes_set or mcc_event_put to pass
	   the trap along. Errors in one of these calls also causes the
	    sink to die.


	- termination alert
	    The sink receives a request to terminate. This happens as a
	    result of an occurs alarm being disabled or a getevent request
	    being cancalled. In any event, the sink is told to die so it does.


In addition, in early version of the v1.2.7 field test kit, the tcpip_am sink 
would die if a trap pdu was recieved that wasn't properly constructed/formatted.
This was changed in a subsequent version so that the sink just ignores 
traps it considers invalid.

Given the information you provided in your base note, it sounds like the
event sink is failing on either the UCX select  or the readfrom call.
Unfortunately, I would need to use the debugger to see exactly what is going on
in the sink. Is this possible? 


Jim

 Jim,

   I'm back on ucx ft 3020 and have to stay there temporarily because I have two
mcc customer demos in the next few days and need to show the trap sink. I will
get back with you mext week when the smoke clears if that's OK.

 Thanks,
 Scott