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 |
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.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
2377.1 | how about GETEVENT and Data Collector | SUBWAY::REILLY | Mike Reilly - New York Bank District | Thu Feb 20 1992 16:24 | 9 |
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.2 | Alarms firing MCC_SEND_EVENT | ICS::WOODCOCK | Thu Feb 20 1992 19:03 | 8 | |
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.3 | send event will work | TOOK::CALLANDER | MCC = My Constant Companion | Wed Mar 11 1992 19:40 | 7 |
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.4 | Seems straightforward enough... | TOOK::MCPHERSON | Save a tree: kill an ISO working group. | Thu Mar 12 1992 12:09 | 110 |
2377.5 | One step closer..... | WOTVAX::PURNELLR | Life, it's not what I thought it was ! | Mon Mar 30 1992 07:21 | 37 |
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 |