Conference azur::mcc

    More on the same subject ...
    
    To isolate the problem further, I started all the event sink first,
    before any other DECmcc activity, putting a sleep 1 minute before
    the next DECmcc startup commands.
    
    The result was the same:
    %MCC-E-MMABORT, target management module thread has aborted ( 2 times )
    
    **********************************************************************
    I conclude from this that it is the way the data collector sinks are
    started (in background) which introduces the problem.
    **********************************************************************
    WHICH KIND OF PROBLEM COULD THIS BE ?
    
    To get rid of the problem I have to do mcc_kill and restart everyting
    from a DECterm ...
    
    
    When the whole startup procedure is terminated, and the iconic map is
    running, and its collector notifications in the state "Being created,
    Being enabled..." I do the following.  Note that notifications on a
    fcl_pm session can already have been started for the collection am
    before the collection_am sink was enabled !
    
    When everything is stabilised I do the following:
    
    
    1). Start the evc sinks ...
    	==> That procedure hangs.
    	--> Script: The script has produced no output.
    
    2). Disable collector notifications on the iconic map ...
    	Enable collector notifications on the iconic map ...
    	==> Same : notifications "Being created,Being enabled..."
    	--> Script: The script has produced no output.
    
    3). kill collection_am
    OK	==> Collector notifications on iconic map "Enabled"
    	==> (also new instance of mcc_collector_am started)
    	If then I try to enable collector sink DECnet and UDPIP:
    	==>%MCC-E-MMABORT, target management module thread has aborted
    	   (2 times)
    	If then I try to enable collector sink DECnet and UDPIP second time:
    	==> Procedure hangs again.
    	--> Script: The script has produced no output.
    
    4). mcc_kill (+ kill all mcc sinks)
    	==> mcc_notification_fm still there.
    	mcc_kill 2nd time
    	==> all mcc processed disappeared.
    	startup sink, then iconic map
    OK	==> Collector notifications on iconic map "Enabled"
    OK	--> Script: The script gives normal results.
    
    	From now on enabling/disabling sinks and notifications (fcl and
    	icmp) in any order gives the normal expected results !
    
    
    	Regards,
    	Dominique.
    

Dominique,

I discovered that you couldn't start the data collector during ULTRIX Boot 
when mcc 1.2 was current.  At the time, engineering said it had something to 
do with the fact that the system is in a sort-of single user mode at the time 
and it doesn't create the collection_am process correctly at that time.  I 
asked for it to be QAR'd it in the hope that it would be fixed for V1.3 (well 
you have to hope!).

As you have discovered, it is still outstanding and I wonder if it will ever 
get addressed now?  It is really serious for my customer as ALL the 
notifications from subordinate mcc systems to their main mcc system from 
which they run the maps to other X-terminals come in via the data collector. 
So if the system crashes and reboots and the x-terms reconnect, you don't get 
any events until somebody remembers to re-enable the data collector.  I have 
also tried to get it to start from crontab but I think this fails for the 
same reasons as at startup.

If anybody can suggest a fix/workaround, I for one would be greatful.  Also, 
if engineering are collecting the 'final list of bugs to be fixed for mcc' 
then please could you add this to the list.

thanks,
chris

chris,

we don't have this particular problem however this would generally fall under
mcc maintenance which we have a few hooks in place. One thing done is that the
MAP users NEVER issue "mana/enter/inter=decw". Note that this is VMS but the
same technique can be done on Ultrix. Instead of the above command I define a
symbol MCC_MAP. MCC_MAP actually runs a procedure which will do things like
SHOW SYS then prompt the user with a question like "Is the Data Collector 
Process Running (MCC_EVC_SINK)". If they say NO then it would start it and go 
on to the next question which looks to make sure the ALARMS are enabled in 
batch, and so on. 

This way whenever the user brings up a map the integrity of all the system
processes required for normal use are at least checked to be running. It also
automates the commands required to start processes so no syntax mistakes are
made.

If you are running alarms off the collector events I'd say you might 
try something different to ensure the process comes up right after
system start instead of waiting for a user to bring up a map.

just an idea,
brad...