[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

852.0. "Cluster support for MIR?" by BELMNT::PIETRONIGRO () Fri Mar 29 1991 09:52

    I have a customer who is interested in distributing the MIR in a cluster. 
    He is presently running DECmcc SMS V1.0 (Director V1.0) and will soon
    be upgrading to DECmcc BMS V1.1 (DECmcc SMS V2.0) when it is released. 
    His specific question is, 'Can the MCC Database be shared LIVE in a
    cluster?'  The customer has extensive experience with DECnet and VMS
    and is interested in the technical 'gory' details.  Any information and/or 
    details will be greatly appreciated.
    
    Thanks in advance,
    Joanne
T.RTitleUserPersonal
Name
DateLines
852.1pointersTOOK::CALLANDERFri Mar 29 1991 10:0634
There are a number of notes on the gory details of the MIR routines and
thier implementations. There is also another on (622) which has more
conceptual information. See keyword=MIR to find these. You might find
some of what you are looking for there.  (the 622 response by Colin Strutt
is the best place to start since it explains what the "MIR" is).

Now more directly in response to your question; I am not certain what you
are looking for. When your customer says he wants to "distribute" his MIR
what is he looking for. Does he want the dictionary on one system, and
his rule store on another? Does he want to put all of the MIR files on
the boot node and have everyone share them?...

The cluster I work on is set up such that we do the following:

	- share a single namespace, used by all nodes
	  (this means registration and domain definition are "global")
	- share a single alarms repository
	   (every one has the same view of the rules)
	- multiple dictionarys and parse tables
	  (so we can each have our own set of enrolled modules customized
           to our needs -- for this we also have seperate dispatch tables)

We picked this set up because it met our needs. We all wanted to use the
same registry, it cut down on overhead. We are a developement environment
so our primary use of rules is in testing our software, and since we use
the same test scripts a single alarms MIR is also useful. But since we
are always working on different problems we each want to customize our
run time environment (modules available) to run the software of our
choice (both type of module and version).

I don't know if this helps, but it gives you an idea of what type of information
we would need to know to understand what your customer means by distributed.
The MIR is only conceptually a single repository. In implmentation it is
many pieces. Read the other notes and clarify your question for more information.
852.2Corrected Version Numbers .BON1::MALAISEAll you need is laugh!Fri Mar 29 1991 11:5716
>    I have a customer who is interested in distributing the MIR in a cluster. 
>    He is presently running DECmcc SMS V1.0 (Director V1.0) and will soon
>    be upgrading to DECmcc BMS V1.1 (DECmcc SMS V2.0) when it is released. 
    
    Joanne just to avoid confusion , I assume that you wanted to say that
    your customer is running DECmcc SMS 2.0 (that includes DECmcc BMS 1.0)
    and will soon upgrade to DECmcc SMS 2.1 (that include  DECmcc BMS 1.1).
    Regards- MaRc .
    
>    His specific question is, 'Can the MCC Database be shared LIVE in a
>    cluster?'  The customer has extensive experience with DECnet and VMS
>    and is interested in the technical 'gory' details.  Any information and/or 
>    details will be greatly appreciated.
    
    Thanks in advance,
    Joanne
852.3RMS ISAM canNAC::ENGLANDMon Apr 01 1991 11:456
    I don't know if MCC's MIR can, but RMS ISAM files supported sharing
    in a cluster environment.  RMS did record locking, etc. in such a way
    that multiple processes on different nodes of the cluster were using
    the cluster lock manager to synchronize.  Of course, this doesn't
    mean that MCC does, because a single MIR call may involve many 
    RMS record operations.