| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3922.1 | A MIR can be shared by multiple FMs | NANOVX::ROBERTS | Keith Roberts - Network Management Applications | Tue Oct 20 1992 08:39 | 15 |
| Euan,
I believe what the SRM is trying to say is a MIR is private to an individual
Management Module ... Just like DECnet information is private to the DECnet
Access Module. You should use the DECmcc Call Interface to access (set,
show, etc...) the data maintained by the MM.
But - there is nothing enforcing this (in terms of the MIR). Multiple
MM's can access a single MIR just as a single MM can.
If you haven't already - take a look at the Example FM (provided by the DECmcc
Toolkit installation). This code demonstrates access to the DECmcc MIR, and
provides a simplified API.
/keith
|
| 3922.2 | | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Tue Oct 20 1992 08:54 | 9 |
| "Private" means the data therein is application-specific, and not
necessarily understood by the rest of the MCC system. For example,
the ALARMS FM stores alarm rules in a private repository, but the
contents of that repository don't really mean anything to another
application.
It has nothing to do with MM boundaries. More that one MM could
certainly be involved in application-specific MIR access.
|
| 3922.3 | There's the MIR and there's the MIR routines | TOOK::GUERTIN | It fall down, go boom | Tue Oct 20 1992 13:00 | 42 |
| It important to note that there are two aspects to the term MIR:
The MIR as an architectural concept:
There are four types of MIR repositories
1) Class MIR -- The MCC Data Dictionary
2) Instance MIR -- DNS (or the "Local MIR" option)
3) Attribute (AKA Historical) MIR -- Historical Data
4) Private (AKA Miscellaneous) MIR-- MM specific information
The MIR Routines:
There are a set of MCC Kernel common routines which allows the
developer to use private MIRs to store MM specific information. I
assume this is what you are talking about. Since the data stored is
basically an "octet string", no one knows what data the MM stored,
how it was stored, when it was stored, or why. Although most
developers store information in ILV format for passing thru the
call interface. To make matters more interesting, there are two
types of repositories, Instance repositories for storing private
entity instance information, and Attribute repositories for storing
private entity attribute information.
The MCC DNS routines:
Used to access the Instance MIR.
The MCC Dictionary routines:
Used to access the Class MIR.
The Historical Data routines:
Not documented because the Information Manager is used to read the
data out of the historical attribute repository (just specify a
past time and a domain), the Historian is used to write historical
records into the historical attribute repository (just specify the
RECORD command).
If the FMs are truly separate, in that they can live separately, then
information should be passed through the call interface, and NOT
through the Private MIRs. If the FMs are more like "left half of
brain", "right half of brain", and they would never be separated,
then I could see the desire to share data through a private MIR.
-Matt.
|
| 3922.4 | keep the N-squared problems down | KAJUN::NELSON | | Tue Oct 20 1992 14:40 | 31 |
| One thing we do need to keep in mind is the original thoughts behind the
specification that a private MIR is MM-specific.
1) As stated in previous replies, the MM can keep data private to it in
a specific format known only to the MM.
2) Different MM's are specifically forbidden to communicate through any
mechanism other than the mcc_call interface. This means that MMs cannot
exchange information through the database or any other mechanism, but
must use each other's service interfaces.
3) Multiple instances of the same MM may synchronize on resources and
exchange information outside the mcc_call interface.
4) Different MMs may certainly share the same MIR. For example, if the
MM MIR were an SQL database, you might have different relations in the
same database. It would be more difficult for MMs to share a MIR that
is maintained by the mcc_mir_* routines, as they may not use information
put there, by MMs other than themselves, as a basis for action.
There are good reasons for restricting communication between different
MMs. This is the way that we keep dynamic, configuration-independent,
... No MM has private communication paths to other MMs and therefore
the dependencies are kept to a minimum. Imagine that a generic FM like
the Alarms FM had private communication to a number of AMs through a
database. This would mean that everytime we released a new version of
the Alarms FM or any of the `privileged' AMs or released a new AM, we
would have to release new versions of all the others. This is an
N-squared problem that gets out of hand very quickly.
...kjn
|