[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

2377.0. "Implementing a multi-director solution" by WOTVAX::PURNELLR ( Life, it's not what I thought it was !) Thu Feb 20 1992 08:30

    
    I am currently working on a project here in the U.K. with a customer 
    supporting a large DECnet network consisting of 13 LAN's connected with 
    WAN links. The need is to manage the network from a central group, we 
    are looking at distributed directors (expecting to see director <--> 
    director relationship in later versions V2.0 ?). 
    
    This is likely to leave us with 13 DECmcc systems covering a total of 
    3200 devices ,up to the DECserver (20% of devices WAN manageable, 
    excluding SNMP devices). Each DECmcc director will host anything from 
    120 - 700 entities with one central director scaled to have the ability 
    to cover all WAN responsibilities (640 entities).
    
    Alarming will be distributed combining polling & events this may 
    involve 1000-2000 alarms across the network with existing alarming 
    functions. WAN devices we can centralise and hopefully hold event 
    driven. 
    
    The main issue here is for the short term (pre V2.0) how can the 
    reporting/notification of alarms be consolidated to a single 
    presentation ?
    
    Rather than have each director fire its own MAP & Notification window 
    into the respective support group, does V1.2 have the functionality to 
    RELIABLE report alarms to a SINGLE director, hence allowing a single 
    presentation of alarms via MAP & Notification window. 
    
    With V1.2 could a remote director upon detecting an alarm, fire a 
    procedure over a wan link to update a notification on a central 
    director which then relays that information via Iconic Map or 
    Notification window to a support group ?
    
    The customer understands for control of LAN devices, a connection to 
    the remote director is required. We simply want a single presentation 
    of Notifications/Alarms not a display from each individual director.
    
    Should these notifications proliferate through to a central display, 
    how can they be governed ? 
    
    We have a multiple operator environment, does one operator deleting the 
    notification from their display, delete it for all others ? 
    
    Is there a method of centrally controlling the notifications ?
    
    Is any form of trouble ticketing available in the short-term, or are we 
    talking V2.0 ?
    
    These are questions we need to answer for the ITT, the customer has 
    trialed V1.1 BMS plus access modules, they are now trialing T1.2.4 BMS 
    for functionality test. To date they are happy, and they wish to put in 
    place a very sizeable operations structure, using DECmcc but also 
    nurturing a multi-vendor director environment. 
    
    I am looking for some technical answers to the above, but also 
    practical ones as we a looking for a deliverable & supportable 
    solution. Also to find out if anyone (customer or internal) is 
    supporting a comparable environment with DECmcc BMS.
    
    &*(
    
    Rex
    
    
    
    
T.RTitleUserPersonal
Name
DateLines
2377.1how about GETEVENT and Data CollectorSUBWAY::REILLYMike Reilly - New York Bank DistrictThu Feb 20 1992 16:249
    I am interested in this problem as well, a possible solution would
    be to read the notification events from the new notificatuion log
    file and then use the DATA COLLECTOR AM to send the events to a
    central MCC director. Would this work? You could also write a
    callable MCC routine that makes a GETEVENT call to get all the events
    from the system and then make the DC calls.
    
    _ Mike
    
2377.2Alarms firing MCC_SEND_EVENTICS::WOODCOCKThu Feb 20 1992 19:038
Although reliability has yet to be tested the Data Collector should be an
option. If you have 'local' mcc's firing alarms you should be able to
add into the alarms_procedure a simple call to the Data Collector to send
an event to the 'central' mcc.

just a thought,
brad...    

2377.3send event will workTOOK::CALLANDERMCC = My Constant CompanionWed Mar 11 1992 19:407
    that will will (DC AM) see the new sample program Jean
    put in (thanks Doug). You can set this up real easy
    from an alarm rule, or send the data from the log
    file. If you get it working it would be great it you
    posted how you did it.
    
    
2377.4Seems straightforward enough...TOOK::MCPHERSONSave a tree: kill an ISO working group.Thu Mar 12 1992 12:09110
2377.5One step closer.....WOTVAX::PURNELLR Life, it's not what I thought it was !Mon Mar 30 1992 07:2137
    
    DOUG et all....
    
    Thanks for your replies. As ever the funds available to the customer
    has shrunk the state of this particular bid.......but this is how it
    now shapes.
    
    We are looking to use DECmcc/Ultrix and the UDMT product, plus some
    'enhancements' from the OSEC in Manchester (UK).
    
    We will have initially 3 directors, 1 central to receive the hub of
    notifications which will be passed using the 2 remote directors. To do
    this remote alarms are passing information via the data collector am on
    the central director.
    
    Several UDMT's remote agents running on Personnel DECstations will sit
    on each LAN polling local ethernet devices for availability. We are
    hoping for modifications to the 'standard' UDMT remote agent here so a
    poll of a terminal server not only tells you the device is powered but
    software operational as well.
    
    The OSEC are looking into offering SNANCP info from a SNAG, DTE info
    from an X25 G/W and maybe info from an ICL G/W to the users with
    modified UDMT or DECmcc modules.
    
    We are also investigating passing info from DCMx to DECmcc and DECmcc
    to CHOx to facilitate further needs.
    
    If succesful the customer is going to grow this configuration
    throughout all of his UK network. 
    
    Regards,
    
    Rex