[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

5487.0. "Collection_AM randomly stopping." by PLUNDR::LOWEG (WANTED!! A modern day Robin Hood.) Mon Aug 16 1993 08:20

    
    
    The Collection_AM seems to stop itself at random. No events are
    getting through until re enable the collector.
    
    Can anybody give me some pointers at what to start looking at.
    
    
    Gary Lowe NUK CSC comms.
T.RTitleUserPersonal
Name		DateLines
5487.1PLUNDR::LOWEGWANTED!! A modern day Robin Hood.Mon Aug 23 1993 06:1511
    
    I take it nobody has experienced this or the details I provided are
    not enough.
    
    However, help is still needed even if more questions are asked for
    me to find out.
    
    Sorry about not including the system details etc in note .0, the 
    customer is using MCC V1.3 on an Ultrix V4.3 system.
    
    Gary Lowe NUK CSC comms.
5487.2More interesting stuffPLUNDR::LOWEGWANTED!! A modern day Robin Hood.Fri Oct 29 1993 07:2446
    
    The full details of the scenario causing this problem are..
    
    The customer has a corporate network sinking events to strategically
    planned geographical mcc systems which in turn are forwarded onto
    to their central mcc system.
    
    What the customer is finding is that the sequence of transferring the
    alarms from the regional systems to the central mcc system stops and
    the only way to sort it out is by manually "enable mcc 0 collection_am
    sink decnet" on the central mcc system. Once this is done everything
    sparks into life again..
    
    On the regional mcc system the customer is using Digital written
    software DDC to read the incoming events and filter them on to the
    relevant collector using "mcc_evc_send". When we look at the error
    log associated with the software we find the following error messages
    in this file at the time of the problem :-
    
    CONNECT FAILED     connection timed out.
    		   or  protocol not available.
    		   or  no space left on device.
    
    Even when we generate an event using mcc_evc_send without the DDC
    software we also get these error messages.
    
    If we generate an alarm to fire a notification bypassing the
    collection_am we successfully receive the notification on the main mcc
    system. Proving the only common denominator as the collection_am.
                                                                          
    We have confirmed, the availability of the system, the collection
    process is running and the main mcc system has no disk full or system
    busy problems. 
    
    I am in the process of contacting the DDC developers to see if they can
    shed any light on the error messages that appear in the error log.
    Plus, I have already drafted a cld, which is ready to send pending the
    response from the DDC developers.
    
    In the meantime is there anybody out there that can shed any light into
    what may be causing this problem as I am absolutely baffled. Could the
    "no space left on the device" be something to do with socket ??
    
    
    Thanks in advance   Gary lowe MCS Nets&Comms
5487.3what about....PLUNDR::LOWEGWANTED!! A modern day Robin Hood.Wed Nov 17 1993 06:5713
    
    
    More on this problem..
    
    If the customer changes his collection_am sink to udp, more errors are
    logged, but the process seems to soldier on.
    
    Might it be somthing to do with the sink transport being decnet a CONS
    as opposed a CLNS. ie Does decnet break in some way under certain
    conditions, like flooding the link with messages ???
    
    
    Gary Lowe UK MCS Nets&Comms.