Conference azur::mcc

  Chris,

  I speak only for myself and this is not an official response from the
  MCC team (I am not part of it :-) ).

  First, I would suggest BT to file a CLD against MCC for this behavior,
  since MCC on ULTRIX is in maintenance mode, the only way to have bugs
  corrected is to enter CLDs.

  Second, you mention that BT is running MCC V1.3 on ULTRIX 4.3-A using R4000
  machines. Be aware that neither Ultrix 4.3A and R4000 machines are supported
  by MCC V1.3. Have a look at the MCC V1.3 SSA, and will probably not see
  mention of ULTRIX 4.3A support, nor 5260 family machines.

  Third, tell BT to start the notif fm after doing a
  'setenv MCC_NOTIFICATION_FM_LOG 0x88' which will produce (hopefully) a lot 
  of useful (or garbage :-( ) information.

  Regards.

  Pierre.

    Hi Pierre,
    
    Thanks for the quick response.  Notifications is normally enabled
    directly from the iconic map PM.  If I set the environment variable,
    does it write to a file or will it try to write to the terminal?  If
    so, I guess I will have to enable notifications via an FCL window which
    may change the behaviour.
    
    Also, I believe that mcc 1.3 does support R4000 and ULTRIX 4.3A.  I had
    mail from Joe O'Connor in NSM engineering sometime back saying testing
    was complete.  I think the spd and ssa have just not been updated :-)
    
    The only real support issue in our configuration (as far as I know) is
    that we are running DECnet/OSI V5.1 rather than V5.1A but that is
    because mcc won't play with the new dnsclerk in 5.1A.
    
    chris

What you seem to completely skip was the mention of UDM and that fact that the 
UDM users are the one that see this problem.  Have you isolated this problem
since the CLD was entered or have you determined that UDM has nothing to do with this problem?

What happens if UDM is not run?  Does the problem persist?

------------------------------------------------------------------------------------
From the CLD:

    The customer has 2 users setup to receive notification alarms root and
    udmman. What appears to be happening is that over a period of time the
    udmman account stops receiving notification. However, what is extremely
    strange is that subsequent users who log into the udmman account receive
    notification messages. So what i suspect is happening is that the udmman
    users are running out of a resource or their internal notification stack
    size is not large enough and not being flushed out.

Re .2:

>    
>    Thanks for the quick response.  Notifications is normally enabled
>    directly from the iconic map PM.  If I set the environment variable,
>    does it write to a file or will it try to write to the terminal?  If
>    so, I guess I will have to enable notifications via an FCL window which
>    may change the behaviour.
>    
	The log goes to the stty of the user who has started the NOTIF FM.
	If you want to redirect the output, do a 'ps' command to determine
	the enrollement ID of the notif fm, kill it, and restart it via
	'/usr/mcc/mmexe/mcc_notification_fm <enroll_id> N > <filename> &'

>    Also, I believe that mcc 1.3 does support R4000 and ULTRIX 4.3A.  I had
>    mail from Joe O'Connor in NSM engineering sometime back saying testing
>    was complete.  I think the spd and ssa have just not been updated :-)
>    
	Ok so, if you have a 'not published official' statement...

>    The only real support issue in our configuration (as far as I know) is
>    that we are running DECnet/OSI V5.1 rather than V5.1A but that is
>    because mcc won't play with the new dnsclerk in 5.1A.
>    
	We know this problem :-(

	Regards.

	Pierre.

There is a problem in DECnet/OSI V5.1 that causes a loss of mbufs when
protocols are started and stopped frequently. It shows up drastically
with alarm rules polling bridges, but other modules might suffer from
this as well.

Do a netstat -m and watch the mbufs value. 

The DECnet/OSI V5.1 patch that solves the problem is dli_bind.o, but 
while you're at it you should install net_common.o and if_ln.o as well.

*Robert

    Thanks to all the noters for the responses so far.  The problem is
    still happening and we are beginning to narrow down whether it is to
    do with notification or the collection_am.
    
    re: .3, We cannot remove UDM from the equation because it is used to
    manage the terminal servers.  However, note that there are no
    notification requests that expand to getevents to the remote_station or
    unix_system access modules.  ALL notifications come through the
    collection_am.  Obviously remote_stations are the targets for some of
    the collector events.  The 'udmman' account is just the non-privileged
    user account that the bulk of users come through.  The root users still
    have a very similar set of notifications enabled - it is that the
    udmman users are the only ones that receives events targetted to udm
    type entities; root users do as well and sometimes notification stops
    for root as well.
    
    re: .4, Pierre, we haven't tried tracing yet but thanks for all the
    information telling us how to use it.
    
    re: .5 I believe in the past we have seem this mbuf problem; once we
    found that all incoming connects were rejected and outgoing 'dlogins'
    failed with "no buffer space available".  But we haven't seen anything
    like this since.  What are we looking for when watching mbufs; a
    continuously increasing value?
    
    The UK CSC advised me NOT to apply the 5.1 kernel patches because the
    system at BT is running 4.3A and they believed that the 5.1 patches
    were developed for 4.3 and hence would break a 4.3A kernel.  They
    further thought that the 4.3A kernel would have all those changes
    anyway.  We are obviously happy to receive more advice here but again,
    because it is very much a live system, we are not in a position to
    experiment with patches that might be applicable but might not be!  We
    are running the 5.1 patched DNS executables.
    

>    like this since.  What are we looking for when watching mbufs; a
>    continuously increasing value?

Yes, that's what I meant. Depending on the number of mbufs available on 
the system it may well take a few days before they are all used up.

*Robert