T.R | Title | User | Personal Name | Date | Lines |
---|
4369.1 | we did it using the collector | GOSTE::CALLANDER | | Mon Jan 11 1993 11:30 | 12 |
| you can do what we have done at shows (some one else might also
have another suggestion). What we do is to set up an action
procedure on each rule that we want to send to the central site.
This procedure simply sends the rule information through the
data collector to the central site. Since the alarms FM tells
you want entity the rule is for as well as the severity, it is
easy to pass the command such that it will turn the right icon
the right color. The only hitch is that you need a datacollector
in the right domain. We did it by having a collector for each
map/domain/manager.
|
4369.2 | what about map files?? | CTHQ::WOODCOCK | | Mon Jan 11 1993 11:46 | 25 |
|
> you can do what we have done at shows (some one else might also
> have another suggestion). What we do is to set up an action
> procedure on each rule that we want to send to the central site.
> This procedure simply sends the rule information through the
> data collector to the central site. Since the alarms FM tells
> you want entity the rule is for as well as the severity, it is
> easy to pass the command such that it will turn the right icon
> the right color. The only hitch is that you need a datacollector
> in the right domain. We did it by having a collector for each
> map/domain/manager.
As Jill indicates the above can be used to keep all the remote mcc's updated.
However there is one more aspect to consider, Domains and Map File Mngmt.
Domain Mngmt can be resolved easily by simply using a common namespace with
the right security applied for who can change what. The Map File Mngmt I do
not believe is covered though (someone pls correct me if wrong). I would
suggest that the Central Mngr have control of the map files and DOWNLOAD
these files to the remotes when changes are done. Is there anything in the
horizon for managing map files for a distributed mcc environment??? This
would be a good time for the Vnext mgr to start looking at this.
best regards,
brad...
|
4369.3 | DFS | STKMCC::LUND | Niklas Lund | Mon Jan 11 1993 13:57 | 7 |
| Hi !
We have succesfully used VAX Distributed File Service (DFS) for distribution of
mapfiles. This can be set up to give each site r/w access to local mapfiles and
read access for remote files.
/Niklas
|
4369.4 | what about file name syncing ? | HERON::PATEL_A | LoLo-AQIC-I82Q-B4IP, - LMF | Tue Jan 12 1993 07:49 | 12 |
| > not believe is covered though (someone pls correct me if wrong). I would
> suggest that the Central Mngr have control of the map files and DOWNLOAD
> these files to the remotes when changes are done. Is there anything in the
> horizon for managing map files for a distributed mcc environment??? This
> would be a good time for the Vnext mgr to start looking at this.
not too "ohfay" with this, but how would each mcc system synchronize on
the file id's - ie when you store the map the first time it's given
that wonderful name, right ? So how would another mcc system recognize
it.
Amrit
|
4369.5 | re .-1 | ANOSWS::COMFORT | Cold iron shackle, ball & chain | Tue Jan 12 1993 11:35 | 13 |
|
I believe that the map name is contructed using the mcc_uid from the
dns entry when the domain is created + the domain name. As long as
every one adheres to the same namespace and/or are not using the local
database for entity storage, then all systems will reference the same
map names. We are doing this between the US and UK. Each side is
responsible for updateing their own maps and any updated maps are
transferred between system every night.
The DFS idea is very interesting. Hmmm, I wonder what the performance
would be like across the pond on a 256 k pipe. }:^{|>
Dave
|
4369.6 | hve two users had the map open simultaneously? | KAJUN::NELSON | | Thu Jan 14 1993 10:13 | 6 |
| Hmmm... Have you actually had two users open the same map
simultaneously? The troubles we have had in the past with DFS included
DFS opening all files for exclusive access.
...kjn
|
4369.7 | Does mcc open files for write, or just read on startup | HERON::PATEL_A | LoLo-AQIC-I82Q-B4IP, - LMF | Thu Jan 14 1993 10:24 | 5 |
| Hi, we intend t otest this out... Does'nt DFS open files for exclusive
write (ie shared read). For MCC the files are read at map startup and
only written if a save takes place... (or is that a bad assumption)
Amrit
|
4369.8 | re .7 Yup | BARREL::LEMMON | | Fri Jan 29 1993 13:07 | 4 |
| Map files are read in at open domain time, written out when
the user saves the map.
/Jim
|
4369.9 | NFS almost works - how about a fix? | ANDRIS::putnins | | Wed Feb 03 1993 14:27 | 19 |
| Since not all customers have exclusively VMS systems running DECmcc
;-), it would be nice to be able to use NFS to share map files.
Well, it almost works. The only problem preventing this is a
dependency in Iconic Map module on the map filename's case. The VMS
Iconic Map module doesn't care whether the filename is all upper case,
lower case, or mixed - everything is converted to upper case. On
Ultrix, the IMPM expects a lower case file name, EXCEPT for the alpha
characters that constitute the UID portion of the map filename. This
makes it impossible to open a map file on an ULTRIX system that is
either NFS mounted from a VMS system, or even copied with DECnet from
the VMS system (e.g. dcp -c vmsnod::mcc*.mcc_map_* . ).
It would be REALLY nice if someone were to fix this!
On the other hand, if you have only VMS systems running DECmcc, NFS
ought to work...
- Andy
|