Conference azur::mcc

  Patrick,

  Can you provide more information please :

   What is generating events ?
   Do you use the Alarms FM, Notif FM ?
   What are the entity managed : AM/FM used mostly
   Do you use extensively the FCL PM, doing a lot of mana/ent, then exit ?

 Regards.

 Pierre.

    
    Thanks for your quick answer Pierre.
    
    In fact, we use the Alarms Fm, Notify FM and we principaly manage the
    following products :
    
    	- Routers (DEMSA...) with DECNET Phase IV AM
    	- DECNIS with DECNET OSI AM (via DNA/CMIP)
    	- DecHub90 & DecHub900 with TCP/IP AM (via SNMP)
     	- DecBridge with TCP/IP (via SNMP)
    
    But, we also use the Performance Analyzer, the IP poller, the FDDI AM
    and the Translan AM.
    
    It is difficult to determine exactly if we use extensively the FCL PM.
    However, we can consider that the FCL PM is actually used by multiple
    users (4) during the day because we are developping our network
    management (rules creation for example...).
    
    
    Best Regards.
    
    Patrick 
    

Patrick,

My initial thought when reading your note was that your system is receiving high
event bursts and that the size of the event manager is not large enough to
handle all events. 

However, if this problem is happening only once a week, this seems a bit
unlikely. The only other thing I can think of is that the Event Pool is filling
up for some other reason. 

There is a know bug (at least on Ultrix, I haven't check if this bug exists on
VMS) with the Event Manager. Each time you exit from a PM, like the FCL PM, the
event structure associated in this PM are cleaned up only if there was
outstanding events for that PM. If there was no outstanding events, this
structure is not cleaned. This bug will be fixed in the next version of DECmcc
on OSF/1. 

If your operators are frequently using the FCL PM, like doing a few commands and
exiting from the FCL PM, then starting the FCL PM again and so on, you are
likely to use up some of the Event pool size which might explain the error you
are getting. 

I am not sure that your problem corresponds to the one we know of, but here are
a couple of things you might do : 

1- Increase the size of the Event Pool. On Ultrix, this is controlled by        
   environmental variables (logical names, I would think on VMS). Here are the  
   ones that we use for TeMIP : 
 
   # Event manager pool size
   setenv MCC_EVENT_POOL_SIZE 2097152

   # Event manager queue size
   setenv MCC_EVENT_EDQ_SIZE_LIMIT 2500

   The default pool size is 1/2 Mb and the above logical extends it to 2 Mb.    
   Please note that *all* processes should run with the *same* set of           
   environmental variables. 

   If you are experiencing bursts of alarms, this should allow to buffer up more
   alarms. If your pool is filling up for other reasons, it won't solve the     
   problem, but it will make it happen less frequently. 

2- Ask your users to keep dedicated MCC sessions. If your users are regularly   
   entering then exiting from the FCL PM, it might be worth asking them to      
   dedicate one window to the FCL PM and in that window, to keep the FCL PM     
   running all the time. 

I cannot guarantee that it will solve your problem, but it is worth a try. 

Best regards,

Marc.

  
  Patrick,

  To add to Marc's reply, we have a workaround for the FCL PM problem on
  ULTRIX.

  What happens is that each management module on ULTRIX is waiting on a
  specific event to exit properly during an mcc_kill command (On ULTRIX
  each management module is running under a different process). When exiting
  the FCL PM, the event structure is not cleaned leaving a few bytes behind
  each time.

  The workaround on ULTRIX is sending an mcc_kill request from a non MCC user
  account (so killing nothing), which will clean the no more used structures.

  If you still have problems, I can send you part of the code of the mcc_kill
  utility, so that you can try sending this event from time to time, to
  see if it helps. This code is ULTRIX only, but should be very easy to port
  to VMS (at least the event creation and event put part).

  Regards.

  Pierre.

We're having this problem on VMS 5.5-2, i.e. it begins to happen after several
days of operation.  We are putting together a management system for a customer,
and this started to show up for the first time during our handoff testing.  I
wouldn't say we have a lot of separate operator FCL sessions.  We do have a
boatload of notify requests outstanding, though (we have a permanent session to
pick up all events and send them to an event printer, in addition to 2 or 3
operators at any one time with 10 or so requests each).

Have you seen this on VMS?  Would you expect that it is a similar situation? 
Is there a workaround for the VMS environment?  

    I am also seeing this problem after applying MCCECO03013 to try and
    eliminate a memory leak.
    
    -Craig

re: -.5 and -.6

Sorry but we (TeMIP team) are not running MCC on VMS. Only on Ultrix and 
OSF/1 -).

I would suggest if not already done that you fill a CLD with all the details of
the problem you are experiencing. CLDs are being followed and I am confident 
your problem will be looked into. 

You might try the suggestions Pierre and I listed in earlier replies to this
note, but although we know they work on Ultrix, I don't know about VMS. If it
works, please post it in this note. It might interest other people. 

Best regards,

Marc.